如何评价一个团队技术工作的好坏

一个团队技术工作的好坏，可以从如下三个维度来去评价：线上系统的质量与稳定性、需求交付的效率、对业务的赋能。

线上系统的质量与稳定性

线上系统的质量和稳定性主要可以从两个维度去考量

线上故障的情况，故障是否足够的少，影响是否足够的小。常见的故障类型如下
- 资金损失
- 数据错误
- 重大逻辑错误
- 性能问题
系统运行的流畅度及用户满意度。技术层面影响用户满意度的因素如下
- 别让我等：系统的响应时间是否足够快
- 别让我烦：偶现bug或者预期外的错误是否足够少，是否会有流程上的卡点当然还有另一个体验问题别让我想更多的是在交互设计层面，作为技术同学也应关心，但不再流畅性这个范畴下讨论。

对于需求交付的效率，需要考量以下三点

我们面临的是一个VUCA的时代, 很多事情都是摸着时代过河，如何在大的不确定性的背景下寻找短期的确定性是每个技术团队都需要思考的问题。

技术作为工具，最终要有人为此买单，而买单的这个人对于To C的产品是你的用户，对于To B的产品是你的客户。我们可以统一称之为业务。有的公司技术可能离业务很近，有的公司技术可能离业务很远，但无论如何要最终服务于业务。业务发展的好坏最终决定了技术能否持续下去。

作为一个技术团队，需要考虑如何才能赋能业务，对业务产生更直接的影响。

总结一下我认为一个牛逼的技术团队是一个能做到以下三点的技术团队

解决了是什么的问题，我们就需要思考怎么做了，总体来讲我觉得需要两点第一解决人的问题，关键岗位需要有一批牛逼的人；第二在技术本身下功夫。

我理解中的优秀的人的画像是这样的

如果团队有一批这样的人，那么这个团队有较大的可能是一个牛逼的团队，如果没有的话那么就得去招聘或者内部培养。内部培养的话就需要在技术本身上下功夫。

当团队的技术领先于业务（技术架构足够先进，质量和效率都很好）时候，这批优秀的人看起来作用似乎不大，甚至任何一个人过来都能保证交付。但当团队的技术大幅落后于业务的时候，最快的扭转办法可能是找到一批优秀的人，安排在关键的岗位上。

做好技术的前提首先是理解业务。只有充分的理解了业务，才能保证设计的系统有足够高的扩展性和适应、找到最关键的点从而提升交付效率、有较强的业务影响力。

要做到理解业务，可以从以下几点入手

无论是ToC的用户，还是ToB的客户，我们需要理解他们使用我们的产品的动机是什么，想要解决什么未满足的需求，他们核心在乎的点是什么。

有几个方法能帮助我们去理解用户

我最近在做一款出海的APP，服务的对象主要是一些小语种的用户。发现遇到的最大的挑战就是如何理解用户，语言不通导致不知道用户到底在干什么，理解用户的途径只剩下了跟用户代表去交流。

当前的业务数据数据是什么样的，北极星指标是什么，数值是多少，北极星指标又是如何拆解的。从数据维度也能帮助我们更好的理解用户和商业模式。

理解了业务，能帮助我们更好的完成系统的设计，也能帮助我们更高效的找到影响业务效率的点，解决业务问题提升技术影响力，还可以在内部的沟通协作上与上下游拉齐沟通的基准线，降低沟通成本。

基于对业务的理解及业务架构的了解，我们可以构建一套稳定运转且可扩展的系统。但难点在于有的团队历史包袱很重，选择逐步重构还是一次性重构需要看公司所处的阶段及团队人员的配置。我更倾向于逐步拆解，这样可控性更强。

另外随着团队的人越来越多，每个人的技术背景不一样，对技术的理解也不一样。为了保证系统的一致性需要做一些前置做好规范性的工作。

从我的认知里，技术侧可以从以下两个方向去提升业务的影响力

如何带领一个团队做好技术工作，是最近我一直思考的问题，也是我2024年的主要挑战，欢迎大家一起讨论。