为什么需要技术KPI
在业务技术团队，有一个不好的趋势，就是团队越来越业务，越来越没有技术味道。每个人都在谈业务，技术大会上在谈业务，周会上在聊业务，周报里写的是业务项目......
唯独少被谈及的是技术本身。此处并不是说业务不重要，而是说理解业务和把控业务需求是技术人员的base，而不是全部。
将就的代价
这种技术味道的缺失对技术团队来说是非常可惜的，也不利于技术人员的成长和发展。因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统的增加会极大的阻碍业务的发展，形成一个个的黑洞应用（吃人不吐骨头），而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。
这种将就将导致系统腐化堕落，技术债越垒越高，丑陋的代码疯狂滋长，像肿瘤一样消耗你所有的能量。就像Robert C. Martin说的“不管你们有多敬业，加多少班，在面对烂系统时，你任然会寸步难行，因为你大部分的精力不是在开发需求，还是在应对混乱。”
作为技术人员，我们不能忘记我们技术人的首要技术使命是治理软件复杂度。
技术Leader的失职
造成这种局面，我们的技术管理者，我们的TL要负有主要责任。说的重一点，是工作上的失职，这种失职主要体现在两个方面，一个是技术不作为，另一个是业务不思考。
技术不作为
现在很多的技术同学，一旦晋升到TL岗位，就开始脱离技术工作，俨然一副道法自然的模样。试想一下，如果一个TL从来不关注技术，从来不写code，对技术没有热情也不学习，甚至其本身技术就很烂，那么又怎么能指望在此TL领导下的团队能有技术味道呢？！
所以当阿里技术副总裁玄难提出要看P8的代码开发量（此处应该给玄难的务实点个赞）的时候，虽然很简单粗暴，但某种程度上的确可以反应出很多TL脱离技术工作的现实。也是在明确传达一个信号——即我们要回归技术本身，因为我们不需要这么多“高高在上”，“指点江山”的技术Manager，而是需要能真正深入到系统里面，深入到代码细节，给团队带来实实在在改变的技术Leader。
业务不思考
现在很多的TL每天都混迹在各种会议上，很忙，做着各种沟（扯）通（JI）协（BA）调（淡）的事情，可是我们真的需要这么多的会议、这么多的沟通吗？
不是说沟通不重要，只是我们现在的会议太多了，就我个人的经验来说，很多的会议都是低效无意义的。所以TL需要更多的独立思考，而不是人云亦云。
雷军说过：“永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰。”，这句话用在形容大部分的PD（产品经理）是再贴切不过了，所以，我宁愿PD们“无为”，总比到处乱抓，搞出很多无价值的产品要好。因为很多系统上的复杂性都是因为这些乱七八糟无意义的需求造成的。
所以给PD同学的意见是，请一定要深入理解业务，一定要深度思考，不要退化成一个PPT Designer和业务需求的传话筒，不要只停留在写PRD、画Demo，要用系统化的思维来规划产品、来解决业务问题，从而赢得技术人员的尊重。
技术人员的疲于奔命，内因上是由于上面分析的团队技术味道的缺失，外因上主要是PD的乱作为。
所以我们的TL也必须要深入思考业务，严格把控PD YY出来的“客户需求”，把这些伪需求，无价值需求挡在门外，防止它们侵占团队本来就很有限的技术资源。从而，才有更多的精力投入到系统优化和复杂度治理上去。
技术KPI的量化
玄难说：“人的本性都是自私的，趋利的”，所以提升技术氛围，打造工程师文化不能仅停留在口头上，需要一定的强制手段，比如和技术人员的利益进行绑定，这种绑定就需要我们能对技术贡献进行一个相对公平的分解和量化。做过晋升评委的同学应该都知道，今年在同学的Profile里面多了一个ATA文章的参考，这也是对技术影响力量化的一种尝试。
技术KPI
基于此，我将技术人员的KPI分解为业务贡献，技术贡献和团队贡献三个大的部分，其详细内容如下。
业务贡献：包括需求把控，业务项目和业务创新。
技术贡献：包括设计重构、技术影响力、Code Review、创新提效和代码质量。
团队贡献：包括招聘、新人培养和团队氛围。
那么技术贡献中的这几个维度要怎么理解呢，解释我就不多说了，就用我们工作中的一些案例来描述一下吧。
关于技术KPI的答疑
对于上面的KPI大部分的技术同学是表示认可的，当然质疑的声音也很多，我这里挑一些典型的回答一下。
Q: 技术KPI的提出，会不会导致技术同学只关注技术不做业务项目了？
A: 关于绩效，肯定是综合看业务贡献，技术贡献和团队贡献。但是作为一个重要参考和风向标，技术KPI是有积极意义的。
Q: 你这个设计重构怎么量化？
A: 这个很难用系统标准化，更多的还是要依赖TL的专业能力进行评分，但即使是这样，也比以前什么都没有完全黑盒要强。至少在传达一个信息，我们鼓励好的设计，鼓励不断的重构优化。
Q: 我们现在的业务需求已经在堆积，一线同学根本没有时间去做重构优化
A: 这个问题开篇其实已经说过了，你是要不断的裹挟在业务需求和烂代码里面呢，还是花时间improve，然后更快的支持业务。这个权衡应该不难做，关键是要看决心和能力。对于一些成熟的业务来说，我没有看到推迟几天上线就会影响业务格局的业务场景，所以作为技术团队，我们就应该在User Story之外，加上我们的Technical Story，把完成业务需求和系统重构都当成我们的核心任务。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
来源：oschina
链接：https://my.oschina.net/u/1464083/blog/3092926