技术人员的KPI应该怎么设定？
谢珠峰提供了灵感的来源。感谢霍大师为所有场景编写代码。写不好请找他。
吐槽HR
我们继续讨论如何设置技术人员的KPI。
阿里科技有一篇文章《如何量化评估技术人员的KPI》，作者是张剑飞。他认为，技术人员的KPI可以分解为“三个贡献”:业务贡献、技术贡献和团队贡献:
1.业务贡献:包括需求控制、业务项目和业务创新。
2.技术贡献:包括设计重构、技术影响、代码评审、创新和效率提升、代码质量。
3.团队贡献:包括招聘，新人才培养，团队氛围。
第二个“技术贡献”被拆解，作者用工作中的一些案例来描述:
1，应用质量:
负责或* * *共同负责应用质量评分(可从代码重复率、圈子复杂度、分层合理性等维度考察。)，以及技术人员为提高应用质量分数做了哪些工作。
2.设计重建:
在客户沟通项目中，技术人员对CRM销售领域进行了建模和设计，抽象合理；
发现基础设施中包的分类不合理，对其进行了重新设计和重构。
发现当前系统中的错误码比较混乱，制定了新的错误码规范并完成了代码重构。
3.技术影响:
团队分享策略模式受到了学生的好评。
接受邀请，在行业大会上分享了SOFA架构。
4、代码审查:
在审查代码时，我发现可能存在线程不安全的隐患。
在审核代码的时候，发现有不合理的设计。在这里使用责任链可以优雅地解决问题，并具有一定的扩展性。
5、创新和效率:
发现在本地测试中启动Pandora Boot很浪费时间，所以编写测试容器大大提高了自测的效率。
发现有些样板代码是不需要写的，乐观锁和分页就是为了简化代码的注解。
在某个项目或技术点上，产生了一个专利:基于领域模型的业务配置。
6、代码质量:
测试后的bug和在线故障的数量(系统可以提取出来，不用填写)。
某个模块的单元测试已经完善，多次自动回归发现问题。
接下来给大家分享一组钩子的图解。作者是Bigger(大数据工程师)做的技术KPI。
Bigger认为，虽然技术人员更喜欢自由的环境，但是对于创业团队来说，如果大家都不遵守规范，那么这个公司的技术团队就是一团乱麻。
技术人员应该用什么KPI？
基于对阿里技术文章的评论，作者明认为:
KPI是主动的，不同阶段要有所侧重。
1.创业阶段，KPI要尽可能向业务倾斜。当生存都成问题的时候，谈技术理想简直就是乌托邦。
2.当收入逐渐稳定后，要尽量向技术倾斜。只有这样才能谈稳健。当整体步入正轨，系统足够健壮的时候，保持6/4(业务/技术)的比例会比较合适。当然这个要根据每个企业的实际情况灵活调控。
这也对TL自身的业务、技术、市场提出了多维度的考核标准。纯技术或者纯商业都不可取。毕竟大家都在等商业机构，商业盈利是第一位的。其他一切都要以此为中心，技术优化也是为商业利润服务的。
所以，没有技术谈生意，或者没有技术谈生意，都是乌托邦式的思维。