技术人本身的KPI

为何须要技术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，把完成业务需求和系统重构都当成咱们的核心任务。

做者简介：张建飞，阿里巴巴高级技术专家，2007年云南大学计算机应用工程硕士，12年软件设计和应用架构经验。热衷于复杂业务分析和代码复杂度治理，在外企工做6年，阿里工做5年。

 

本文做者：张建飞

原文连接

本文为云栖社区原创内容，未经容许不得转载。