javakpi_技术⼈⾃⼰的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的乱作为。
java技术专家所以我们的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年。
本⽂为云栖社区原创内容，未经允许不得转载。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。