摘要：技术的量化提升技术氛围，打造工程师文化不能仅停留在口头上，可搭配一定的强制手段，比如和技术人员的利益绑定。但是作为一个重要参考和风向标，技术是有积极意义的。
为什么需要技术KPI？
在业务技术团队，有一个不好的趋势就是团队越来越业务，越来越没有技术味道。每个人都在谈业务，技术大会上在谈业务，周会上在聊业务，周报里写的是业务项目......
唯独少被谈及的是技术本身。此处并不是说业务不重要，而是说理解业务和把控业务需求是技术人员的base，而不是全部。
将就的代价这种技术味道的缺失对技术团队来说是非常可惜的，也不利于技术人员的成长和发展。因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统的增加会极大的阻碍业务的发展，形成一个个的黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。
这种将就将导致系统腐化，技术债越垒越高，像肿瘤一样消耗你所有的能量。
我不是药神，只能尝试开出一方——那就是在不影响业务的情况下（特别是相对稳定的业务，请拒绝业务方的时间倒排），Tech Story应该和User Story有同等的重要性，要把重构优化提到和业务需求相等的优先级去处理。我们不仅要对业务需求负责，我们更要对应用的质量，系统的可维护性负责。
因为我们技术人员是应用的父母（有些是亲生父母，有些是养父母），你不照顾它们，不治理它们，它们就会生病，你忍心看到这样的局面吗？
技术管理者者（TL）的失职造成这种局面，我们的技术管理者，我们的TL要负有主要责任。如果一个TL从来不关注系统架构和设计，从来不写code，对技术没有热情也不学习，甚至其本身技术就很烂，那么在这个TL领导下的技术团队，又怎么会有技术味道，团队成员又怎么能进步和成长？
现在很多的TL每天都混迹在各种会议上，很忙，做着各种沟通协调的事情，可是我们真的需要这么多的会议、这么多的沟通吗？
如果沟通的结果只是做业务和PD对团队的传话筒，没有业务创新，没有用技术和数据系统化的解决业务问题，没有在技术方向和架构上给团队指引，没能切实的帮助系统优化、团队提效，请问这样的沟通给业务带来了什么价值，给团队带来了什么价值？还是沉下心来，多看看书，哪怕非技术的书也好。多写写代码，哪怕跟业务无关的代码也好。
所以，我们要回归技术本身。我们不需要这么多“高高在上”、“指点江山”的技术Manager，而是需要能真正深入到系统里面，深入到代码细节，给团队带来实实在在改变的技术Leader。
技术KPI的量化提升技术氛围，打造工程师文化不能仅停留在口头上，可搭配一定的强制手段，比如和技术人员的利益绑定。这种绑定就需要我们能对技术贡献进行一个相对公平的分解和量化。
技术KPI基于此，我将技术人员的KPI分解为业务贡献、技术贡献和团队贡献三个大的部分，其详细内容如下。
• 业务贡献：包括需求把控，业务项目和业务创新。
• 技术贡献：包括设计重构、技术影响力、Code Review、创新提效和代码质量。
• 团队贡献：包括招聘、新人培养和团队氛围。
那么技术贡献中的这几个维度要怎么理解呢，解释的话我就不多说了，用我们工作中的一些案例来描述一下吧。
应用质量：
• 你负责或者共同负责的应用质量分（可以从代码重复率，圈复杂度，分层合理性等维度考察）。
• 你做了哪些提升应用质量分的工作。
设计重构：
• 我在客户通项目中，对CRM销售域进行了领域建模和设计，并且抽象合理。
• 我发现Infrastructure中package分类不合理，进行了重新设计并重构完成。
• 我发现现在系统中错误码比较混乱，我梳理制定了新的错误码规范，并完成了代码重构。
技术影响力：
• 在团队内分享10篇干货，点赞数1000。
• 团队分享策略模式，得到同学好评 。
• 我接受邀请，在行业会议上分享了SOFA架构。
Code Review：
• 我在review某某代码的时候发现，可能存在线程不安全的隐患。
• 我在review某某代码的时候发现，存在设计不合理的现象，此处使用责任链可以很优雅的解决问题，并具备一定的扩展性。
创新提效：
• 我发现本地测试启动PandoraBoot比较浪费时间，所以写了一个TestContainer大大提升了自测效率。
• 我发现有一些boilerplate代码不需要写，所以对乐观锁、分页进行了annotation支持，简化了代码。
• 在某个项目或者技术点上面，我产出了一篇专利：基于领域模型的业务配置化。
代码质量：
• 提测后的Bug数，线上故障数（系统可以提取，不用自己填写）
• 我完善了某某模块的单元测试，并多次在自动化回归中发现问题。
KPI答疑对于上面的KPI大部分的技术同学是表示认可的，当然质疑的声音也很多，我这里挑一些典型的回答一下。
Q：技术KPI的提出，会不会导致技术同学只关注技术不做业务项目了？
A：关于绩效，肯定是综合看业务贡献，技术贡献和团队贡献。但是作为一个重要参考和风向标，技术KPI是有积极意义的。
Q： 你这个设计重构怎么量化？
A： 这个很难用系统标准化，更多的还是要依赖TL的专业能力进行评分，但即使是这样，也比以前什么都没有完全黑盒要强。至少在传达一个信息，我们鼓励好的设计，鼓励不断地重构优化。
Q：我们现在的业务需求已经在堆积，一线同学根本没有时间去做重构优化。
A：这个问题开篇其实已经说过了，你是要不断地裹挟在业务需求和烂代码里面呢，还是花时间improve，然后更快地支持业务。这个权衡应该不难做，关键是要看决心和能力。对于很多业务，我没有看到推迟几天上线就会影响业务格局的业务场景，所以作为技术团队，我们就应该在User Story之外，加上我们的Technical Story，把完成业务需求和系统重构都当成我们的核心任务。
本文作者：张建飞
阅读原文
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/11913.html
摘要：但流程不是死的，尤其在互联网公司，只要有助于我们的目标达成，那么流程只是一阵东风。工作中并不是所有事情都可以依赖流程去保证万无一失。所以不要怪罪流程，这并不是流程的问题，而是人的问题。所以请不要再怪罪流程啦，以人为本，才是长久之计。 本文由作者周巧芬授权网易云社区发布。 笔者所在的团队这段时间正在两个版本的交接期，前一个版本马上要上线了，但后一个版本的需求早在三周前就已经启动，却迟迟没...
摘要：创业公司往往会发放限制性股票和期权。特别是像在深圳这样房价越来越高的地方，许多同事也面临着需要买房成家的问题，可能会需要提前支取他的股票期权收益。同时，给在工作了一段时间的员工提供了五十万元的无息住房贷款，帮助一些同事在深圳安个家。 作者简介：张海龙，CODING 创始人。复旦大学软件工程学士，CMU计算机硕士，曾在 Oracle 任职高级软件工程师。2010年回国创业，2014年创办...
摘要：年月日，第届技术管理工作坊将在深圳华侨城洲际酒店举行。壹佰案例在开始前采访了沈剑老师，先行剧透架构师转型做管理的感悟。 showImg(https://segmentfault.com/img/bVxMfU);2016年6月25-26日，第27届MPD技术管理工作坊将在深圳华侨城洲际酒店举行。本次工作坊，我们邀请了58到家技术总监沈剑老师，分享《技术团队的接手、搭建与发展实践 》， 讲...
摘要：大家好，我叫，江湖人称吃土小叉，目前担任公司的前端负责人半年多了，一路上摸爬滚打，历经团队人员变动，近日颇有感触，于是结合自己近半年的前端负责人实践经验，权当作一个学习记录，整理归纳一下小作坊团队前端负责人的修炼要点大部分只是记录了关键词， 大家好，我叫XX，江湖人称吃土小2叉，目前担任公司的前端负责人半年多了，一路上摸爬滚打，历经团队人员变动，近日颇有感触，于是结合自己近半年的前端负...
阅读 1786·2021-11-22 09:34
阅读 1114·2021-10-09 09:44
阅读 2949·2021-09-29 09:35
阅读 3593·2021-09-14 18:01
阅读 1441·2021-08-16 10:49
阅读 1071·2019-08-29 14:11
阅读 779·2019-08-29 12:47
阅读 3052·2019-08-26 13:47
