#第5期：效能指标，该由谁来定义？#

回顾上期《「自动化」聊起来简单，做起来难》我们聊了聊如何打造「自动化」的事，这也是真正实现研发效能提升的必要条件。从单点自动化提升效率，到全工具链自动化，再到研发体系平台化，是自动化实践的三个步骤。

在这个过程中，如何为研发体系建立一套既业务目标明确又能正向引导研发团队的效能指标体系，是平台化是否能成功的关键。本期我们聊聊"效能度量指标"的问题。

受访者A：某外企云厂商 敏捷教练  李经理

受访者B：某互联网银行 研发效能经理  苏经理

Q:有些研发朋友反馈，效能指标太多了，有些指标不知道有何意义。想知道指标应该从哪里来？定义指标的逻辑是什么？

A：我是这么认为，随着企业业务的发展，要求企业体系内的能效越来越高，判断能效的方法越来越复杂。在研发体系中，软件工程的发展，使研发效率提升有了科学的方法论，落地方法论的过程中，“如何把控过程的正确性”是定义效能指标的根本逻辑。

研发效能指标的定义应该基于公司的业务目标，以及研发部门的具体任务和职责。不同的目标，对应不同的结果，有的为了提高交付质量，有的为了降低项目研发成本，其对应的关键结果指标的数据都大不相同，这些数据也只是综合性的结果。而原始数据的定义，要对不同团队的结构和工作职能，划分不同层级的评估指标，确保项目、团队、个人都对结果有迹可循。

定义研发效能指标是一个动态的过程，我们需要根据业务实际情况进行定期评估和调整，通过定期的绩效评估和反馈，来确定是否需要调整指标的权重和目标。

B：理想情况下，效能指标需要由效能增长团队和业务团队一起建立。但大多数实际情况是效能增长团队建立后，去寻求业务团队评估，然后被指责定义不科学，不符合业务目标，而产生抗拒。所以，我们内部的实践方法是：

首先，由我们效能增长团队来定指标，让指标数据先跑起来一段时间，做好数据积累。

然后，我们根据积累的数据，对业务进行效能评估，看业务团队是否达成相关目标，或者哪些阻碍了目标的达成。为了保障数据的准确性，我们需要对数据进行维度拆分，以便更好地分析数据规律。

最后，对于效能的评估结果，我们会及时与业务团队的每个人去沟通，让他们在此指标系统下有清晰的认知和需求反馈，让业务团队知道指标是来帮助他们而不是来考核他们，促使其主动加入指标系统的定义，确保指标对业务有实际用处，以帮助进行效能改进。

Q:研发体系建立起来的同时伴生了很多效能指标，当这些指标应用起来，就会成为团队追求的KPI数字，从而只关心数字的好看，效能并没有实质改善，是不是存在效能指标不合理的情况？如何看待这种情况？

A：其实指标不合理的情况是普遍存在的。所以我们持续优化效能指标，不断地度量、改进、再度量、再改进。整个指标体系其实是对研发团队运行情况的一个直观反映，就像车上的仪表盘，给驾驶员一个直观的数据，确定车子速度是快是慢，还有多少油、多少电、哪有故障等等，帮助驾驶员进行判断车子的状况。

很多时候，团队面临KPI的压力，不得不过度追求一些指标，但从实际效果看是对业务目标没有帮助的，这完全走偏了。我们还拿车子做比喻，如果我们目标是车子速度，达成这个目标的方式有很多：可以换引擎、换轮胎、改造车身、改悬挂系统，甚至我们可以换驾驶员。但团队或个人追求的指标有可能变成：油耗的快慢、气门的效率、散热器的温度，而这些数据可以篡改或造假的。就像很多年前，我们把代码行数、工时等当成研发团队的重要指标一样，里面有很多水分。但现在我们用有效代码、千行代码缺陷量、需求交付数等更科学的指标，来替代不科学的指标。

B：我也是这么认为，不合理的指标是很难避免的。研发团队是很难被量化的部门，复杂度极高，而不合理的指标是在建立量化体系过程中产生的，验证不合理性后，也需要被快速淘汰。比尔·盖茨也说过：用代码行数来衡量编程的进度，就如同用重量来衡量飞机的制造进度。这就是在说不合理的指标与业务目标的失焦问题。

在追求KPI好看的问题上，其实这些指标往往是过程指标，我的建议是给业务团队自主权，让他们决定是否使用，而不是一味的考核，目的还是让业务团队参与到指标建设中来，定义过程指标的目的是在发现问题、解决问题方面发挥的作用，也能减少追数据的现象发生。如果一个指标，不能引导团队去做质量改进，就没必要去度量。

本期我们和两位嘉宾聊了聊“定义效能指标”和“不合理的效能指标”两件事，其中最深刻的一句：“如果一个指标，不能引导团队去做质量改进，就没必要去度量。” 被当成KPI的指标，如果不能起到业务目标的作用，那就是不合理的指标。

建立效能指标体系的三个步骤形成闭环：

1. 由效能团队定义第一批指标，用来积累初步的数据。

2. 通过业务目标达成情况，分析数据评估效能。

3. 通过评估效能结果，与业务团队沟通，确认效能指标是否有问题，改进优化，让业务团队参与到效能指标体系建立过程。