研发管理KPI

pTDbn25

一、生产缺陷数目

首先说最敏感的缺陷数目，在各种团队中，常规的业务研发都要成为某个模块（系统、服务）的负责人，而在你的迭代需求中，最终最明显的衡量指标之一毫无疑问就是上线后的缺陷。不管任何原因，上线后出现不可预期的缺陷，研发都难咎其责，不管测试是否考核，研发都需要为自己的产物质量买单。

所以我们需要在需求分析及设计评审后对不同的需求给出可容纳bug边界值（需要评审人员整体投票，研发负责人认可）

当然缺陷务必考虑缺陷的等级以及缺陷的影响面积。

二、延期率/延期时间

针对研发管理，我们排除掉测试环节，那么这里讲的延期是只研发完成交付测试的时间点违背计划发生延期。

毋庸置疑，能够按时完成开发任务是第一要素。在相当的团队中敏捷流程已经深入人心，不考虑scrum那种理想主义的小瀑布模式，虽然有办法对延期的需求进行尽可能的无伤顺延，但是一个需求的延期仍然会打破整个团队的迭代计划，影响测试伙伴。更别提对市场和客户的影响。所以我们会按一定周期统计一个研发伙伴因个人原因造成开发进度延期的数目。

当然，需求的大小和复杂度不同，在不同的环境下要保证工时的预估合理。这是前提，暂且按下不表。

延期时间可以做周期叠加统一计算考核。

三、测试阶段bug数目

在交付测试成功后，测试阶段的bug数目直接反馈研发质量。虽然通过了交付，但是bug数目可以有效的评估出研发质量和自测质量。所以同样我们需要在需求分析及设计评审后对不同的需求给出可容纳bug边界值（需要评审人员整体投票，研发负责人认可）。不同的需求的复杂度和不同的设计的实现难度都是不同的，所以这里必须对不同的需求不同处理。

四、生产缺陷的响应频次和修复周期

同第一点不同的时，这次我们考察的是生产缺陷发生时，负责人的紧急响应程度（可涉及非工作时间，取决于不同行业，例如微博因为XX时间挂掉了，研发和运维什么有多少次能第一时间到岗解决问题）。还有当你响应后，修复的问题所需要的时间。

五、研发设计评审

针对需求，合理的研发设计必然是第一要务，一个优秀的架构师首先要具有优秀的设计能力。所以能有完整充分的设计文档及相关图等数据，能清晰的向不同岗位的伙伴解释清楚方案、风险、问题等内容，是一个非常重要的评分项。

这里主要考察设计的成果物完成度。不去考核设计的具体技术方案本身。不同级别的工程师设计能力当然是不同的，横向比较的话难道还乘以一个工资或者级别系数吗？

六、沟通认可360评分

团队工作沟通当然是不可避免的，一个好的沟通素质也许很难量化，但是我们可以定期通过360度打分，同岗位和不同岗位的伙伴进行沟通评分收集求平均后，能有效的评判到一个伙伴的沟通能力。不能团结队友，本身就是失败，不是吗？

七、向下管理和向上管理

想下管理的KPI暂时不讨论。比较适合专题。向上管理我们针对一般研发人员首先可以评判其周报、月报的详尽合理程度及准时性。

( F, N' ?9 I# R8 s& b

kekek

团队工作沟通当然是不可避免的

高大不威猛

小白看一下