针对这个痛点，阿里高级技术专家张建飞提出了自己的解决思路，希望能与大家一起探讨、交流。
为什么需要技术 KPI？
在业务技术团队，有一个不好的趋势就是团队越来越业务，越来越没有技术味道。
每个人都在谈业务，技术大会上在谈业务，周会上在聊业务......
唯独少被谈及的是技术本身。此处并不是说业务不重要，而是说理解业务和把控业务需求是技术人员的 base，而不是全部。
将就的代价
这种技术味道的缺失对技术团队来说是非常可惜的，也不利于技术人员的成长和发展。
因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。
相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统的增加会极大的阻碍业务的发展，形成一个个的黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。
这种将就将导致系统腐化，技术债越垒越高，像肿瘤一样消耗你所有的能量。
所以，在不影响业务的情况下（特别是相对稳定的业务），Tech Story 应该和 User Story 有同等的重要性，要把重构优化提到和业务需求相等的优先级去处理。
我们不仅要对业务需求负责，我们更要对应用的质量，系统的可维护性负责。
因为我们技术人员是应用的父母（有些是亲生父母，有些是养父母），你不照顾它们，不治理它们，它们就会生病，你忍心看到这样的局面吗？
技术管理者者（TL）的失职
造成这种局面，我们的技术管理者，我们的 TL 要负有主要责任。如果一个 TL 从来不关注系统架构和设计，对技术没有热情也不学习，甚至其本身技术就很烂。那么在这个 TL 领导下的技术团队，又怎么会有技术味道，团队成员又怎么能进步和成长？
TL需要真正深入到系统里面，深入到代码，给团队带来实实在在的技术改变。
技术 KPI 的量化
提升技术氛围，打造工程师文化不能仅停留在口头上，可搭配一定的强制手段，比如和技术人员的利益绑定。这种绑定就需要我们能对技术贡献进行一个相对公平的分解和量化。
技术 KPI
基于此，我们将技术人员的 KPI 分解为业务贡献、技术贡献和团队贡献三个大的部分。
其详细内容如下：
业务贡献：包括需求把控，业务项目和业务创新。
技术贡献：包括设计重构、技术影响力、Code Review、创新提效和代码质量。
团队贡献：包括人员培养和团队氛围。
那么技术贡献中的这几个维度要怎么理解呢，用我们工作中的一些案例来描述一下吧。
应用质量：
你负责或者共同负责的应用质量分（可以从代码重复率，圈复杂度，分层合理性等维度考察）。
你做了哪些提升应用质量分的工作。
设计重构：
我在客户通项目中，对 CRM 销售域进行了领域建模和设计，并且抽象合理。
我发现 Infrastructure 中 package 分类不合理，进行了重新设计并重构完成。
我发现现在系统中错误码比较混乱，我梳理制定了新的错误码规范，并完成了代码重构。
技术影响力：
在团队内分享干货，进行技术培训。
团队分享策略模式，得到同学好评 。
解决技术问题，正确的技术决策能力。
Code Review：
我在 Review 某某代码的时候发现，可能存在线程不安全的隐患。
我在 Review 某某代码的时候发现，存在设计不合理的现象，此处使用责任链可以很优雅的解决问题，并具备一定的扩展性。
创新提效：
我发现本地测试启动 Pandora Boot 比较浪费时间，所以写了一个 TestContainer 大大提升了自测效率。
我发现有一些 boilerplate 代码不需要写，所以对乐观锁、分页进行了 annotation 支持，简化了代码。
在某个项目或者技术点上面，我产出了一篇专利：基于领域模型的业务配置化。
代码质量：
提测后的 Bug 数，线上故障数（系统可以提取，不用自己填写）
我完善了某某模块的单元测试，并多次在自动化回归中发现问题。
KPI 答疑
对于上面的 KPI 大部分的技术同学是表示认可的，当然质疑的声音也很多，我这里挑一些典型的回答一下。
Q：技术 KPI 的提出，会不会导致技术同学只关注技术不关注业务了？
A：关于绩效，肯定是综合看业务贡献，技术贡献和团队贡献。但是作为一个重要参考和风向标，技术 KPI 是有积极意义的。
Q： 你这个设计重构怎么量化？
A：这个很难用系统标准化，更多的还是要依赖 TL 的专业能力进行评分，但即使是这样，也比以前什么都没有完全黑盒要强。至少在传达一个信息，我们鼓励好的设计，鼓励不断地重构优化。
Q：我们现在的业务需求已经在堆积，一线同学根本没有时间去做重构优化。
A：这个问题开篇其实已经说过了，你是要不断地裹挟在业务需求和烂代码里面呢，还是花时间 improve，然后更快地支持业务。这个权衡应该不难做，关键是要看决心和能力。
对于很多业务，也很少是推迟几天上线就会影响业务格局的业务场景，所以作为技术团队，我们就应该在 User Story 之外，加上我们的 Technical Story，把完成业务需求和系统重构都当成我们的核心任务。
