谢 朱峰 提供灵感来源 。 感谢霍老爷为所有场景写代码，写得不好请找他。
吐槽了HR
我们继续讨论技术人员的KPI应该怎么设。
阿里技术有一篇文章《如何量化考核技术人的KPI》，作者是张建飞，他认为技术人员的KPI可以分解为“三个贡献”：业务贡献、技术贡献和团队贡献：
1、业务贡献：包括需求把控，业务项目和业务创新。
2、技术贡献：包括设计重构、技术影响力、Code Review、创新提效和代码质量。
3、团队贡献：包括招聘、新人培养和团队氛围。
重点拆解了第二个“技术贡献”，作者用工作中的一些案例来描述：
1、应用质量：
负责或者共同负责的应用质量分（可以从代码重复率，圈复杂度，分层合理性等维度考察），技术人员做了哪些提升应用质量分的工作。
2、设计重构：
技术人员在客户通项目中，对CRM销售域进行了领域建模和设计，并且抽象合理；
发现Infrastructure中package分类不合理，进行了重新设计并重构完成
发现现在系统中错误码比较混乱，梳理制定了新的错误码规范，并完成了代码重构。
3、技术影响力：
在团队内分享10篇干货，点赞数1000。
团队分享策略模式，得到同学好评 。
接受邀请，在行业会议上分享了SOFA架构。
4、Code Review：
在review某某代码的时候发现，可能存在线程不安全的隐患。
在review某某代码的时候发现，存在设计不合理的现象，此处使用责任链可以很优雅的解决问题，并具备一定的扩展性。
5、创新提效：
发现本地测试启动Pandora Boot比较浪费时间，所以写了一个Test Container大大提升了自测效率。
发现有一些boilerplate代码不需要写，所以对乐观锁、分页进行了annotation支持，简化了代码。
在某个项目或者技术点上面，产出了一篇专利：基于领域模型的业务配置化。
6、代码质量：
提测后的Bug数，线上故障数（系统可以提取，不用自己填写）
完善了某某模块的单元测试，并多次在自动化回归中发现问题。
接下来给大家分享一组拉勾的图，作者是比格（大数据工程师）制作的技术KPI、
比格认为，虽然技术人员更希望自由的环境，但是对创业团队来说，如果大家都不按规范，那这个公司的技术团队就是一盘散沙。
技术人员到底应该用什么KPI？
基于前面阿里技术文章的评论，作者Ming认为：
KPI是活动的，在不同的阶段KPI应该是有侧重点的。
1、创业阶段，KPI应尽可能的往业务倾斜，当生存都是问题的时候谈技术理想根本就是乌托邦。
2、当收入逐渐稳定下来后，则应尽量往技术倾斜，这个时候谈健壮性才有条件。当整体都已经走上正轨了，系统健壮性也足够强的时候，则是持续保持一个6/4（业务/技术）的比例会比较恰当，当然这个也要根据每家企业的现实状况来灵活调控。
这也就对TL自身的业务、技术、市场提出一个多维度的考核标准，纯粹的技术或者纯粹的业务都是不可取的，毕竟大家待的都是商业机构，商业利润才是***位的，其他的都要围绕这个，技术优化也是为商业利润服务的。
所以，窃以为撇开技术谈业务或者撇开业务谈技术都是一种乌托邦式的思考。
