作为一个技术团队的负责人，公司往往对其有“提升技术团队技术能力”的期望。不同人对技术能力的评价标准是不一样的。我们经常看到一些技术团队的负责人觉得自己团队的技术挺好的，但公司高层和其他部门对技术团队的技术能力评价一般。作为技术团队负责人，有必要了解，其“服务的客户”（一般是公司的业务部门）是如何来评价技术团队的技术能力的。并有针对性地提升“客户”优先看重的技术能力。

 

对于公司非技术的高层和业务部门等对技术不了解的同事，他们一般会从4个方面来评价技术团队的技术能力：

1.     要求的功能是否能实现

业务方不关心具体的实现细节，但如果其他公司的产品中实现了一些功能，我们的产品中做不出来，业务方就会认为技术团队能力不行。

2.     系统是否稳定，性能是否ok

如果系统 bug 比较多，系统时不时宕机，或是响应速度不如竞争对手的产品，业务方一定觉得技术团队技术不行。

3.     研发速度是否快

同样的产品，如果你的团队能比竞争对手更快上线，业务方就会认为团队的技术能力强，反之业务方就会认为团队的技术能力弱。

4.     能否基于技术经验，提出更好的业务和产品建议

很多业务方并不了解前沿的技术，对前沿技术能给业务带来的好处缺乏思考和判断。如果技术团队能通过采用一些新技术，让业务方获得竞争优势，将获得业务方很大的认可。

 

业务方在评价技术团队能力高低时，其实是比较片面的。譬如说，技术团队为了满足某种特性，采用了和竞争对手不一样的技术架构，这种技术架构有很多好处，但的确会使某个具体的功能实现困难。这种情况下，业务方就片面地认为技术不如对手。又譬如说: 研发速度很多时候的确反映了技术能力，但前提是比较双方在人员数量，内部支持力度，等因素大体一致下。而业务方在看研发速度时，往往会忽略这些因素。这是为什么很多技术人员对团队技术能力的判断会和业务方不同的原因。

 

但是“客户”永远是正确的，除非你不在乎这个“客户”的流失。这就要求技术负责人也要学会从“客户”角度来看待团队的技术能力，而不是仅仅从技术掌握难度的角度来看待团队的技术能力。很多时候公司希望提高团队的技术能力，其实并不是要提高技术人员认知上的技术能力。随便举两个例子：

1.     很多技术，技术本身很难比较好坏和高低，只有适合和不适合。一些情况下，公司觉得技术能力不高，其实是因为技术架构方案并不符合业务特点。譬如，业务更看重性能和易用性，但技术架构上做了过多安全性设计，导致性能和易用性受到了影响。

2.     在一些情况下，公司其实是对研发速度不满意，你只要加快招聘，人多了，上线速度快了，公司就认为团队的技术能力提升了。

 

总之，当需要提升技术团队的技术能力时，技术负责人需要学会从“客户”角度来评价团队的技术能力，找到真正的问题，有针对性地提升“客户”优先看重的技术能力。从另一个角度讲，真正技术能力好的团队，是能用“最合适的技术”解决业务问题的团队。