案例解析：用「度量」提升企业研发效能｜ONES Talk

6月17日，在「精益软件工程大会」上，ONES 研发效能改进咨询顾问董晓红作了题为《研发效能度量场景解读》的演讲。通过两个效能提升场景案例，共同探讨如何通过「度量」帮助企业解决具体的问题，提升研发效能。

以下是董晓红当天分享的主要内容。

研发效能是什么？

在咨询时，客户经常会询问：「如何提升研发效能」？但是，大家对研发效能的理解千差万别：有人认为效能是一组量化的指标，有人认为效能是人力资源的饱和度，也有人认为效能是工程实践等等。

管理大师彼得德鲁克曾说过：「效率是以正确的方式做事，而效能是做正确的事。」我们理解的研发效能，是动态地、可持续地做正确的事。所谓做正确的事，就是我们个人或团队找到目标、方向，能给客户带来价值，从而帮助我们组织实现商业价值。同时，按照标准流程完成工作，做得又多、又快、又好、又省，这是我们理解的「研发效能」。

当我们谈研发度量时，我们习惯于谈它「不是什么」——它不仅是一组数据，它更是我们数据背后产生的信息；它不是先有指标，它是先确定解决的问题以及要达成的目标，从而来设计一组指标；它也不是整个软件研发的一个固定活动，它是精益思想中不断反馈、持续改进的思想和理念。

企业效能提升案例分享

接下来，和大家分享同一家公司的两种场景案例，希望通过客户来了解我们是如何通过「度量」来解决具体的问题，以及解决问题的同时我们有哪些好的实践。本次选择的案例是互联网企业，公司规模2000人，9个事业部，技术人员900+。

场景一

这个场景案例的痛点是稳定性。公司架构是「小前台+大中台」，故障造成的资损巨大，保监会约谈整改，合作方投诉，丢失了很多渠道。对于研发侧，他们没有数据、疲于救火，无法说清楚当前系统的稳定性质量，经常替第三方背锅。这是当时公司的痛点。

基于这个痛点，我们制定了以下几个目标：

• 各事业部设立稳定性基线数据——也就是「我们在哪儿」？

• 各业务部门根据自己的业务设定稳定性目标——也就是「我们要去哪儿」？

• 定期针对稳定性故障复盘，逐步提升稳定性；

• 定期通晒各业务部门的稳定性报告，树立稳定性标杆，复制推广优秀案例；

• 完善监控机制，提升监控检测故障率。
  

接下来，我们看看该案例的稳定性度量数据观测。

观测数据一：通过对故障相关数据的度量获取了它的资损，包含直接资损和潜在资损。我们制定目标后，次年资损下降了50%，资损时间提升到30分钟内。当然，稳定性的提升，它是一个系统性的工程，我们还要做很多事情：事前，我们对故障等级进行定义（例如，一等级要求5分钟内响应，四等级要求半天内响应）；事中，我们还要做故障的应急协同，大家如何去配合、如何解决故障；事后，复盘改进整个系统的方案，提升日后操作的稳定性。

观测数据二：通过对故障原因分析度量，形成改进措施，次年业务稳定性提升58%。我们通过对故障的原因以及改善措施的类型进行分析，看到我们通过哪些改善能有效地避免故障，同时预防与改进。

观测数据三：通过对故障发现形式的分析，针对用户侧发现的故障，反补监控逻辑，次年故障发现率提升20%。

观测数据四：通过对九大事业部的定期稳定性报告，让质量可视化。让 CTO、CEO 看到全局的质量，同时让优秀部门的经验在组织内进行复制推广。

场景二

另一个场景是需求价值度量的案例，我们先来看看它的痛点：

• 公司层的痛点：投入了大量的资源，却不知道如何解决需求井喷以及是否能实现价值最大化；

• 技术侧的痛点：无法衡量技术产出，说不清做了多少产品；

• 产品侧的痛点：需求来源多，每个业务都说是紧急需求，无法系统性设计产品；

• 技术人员的痛点：低头写代码，不了解实际需求带来的价值，导致交付版本达不到预期，无法获得工作带来的成就感。

基于这些痛点，我们设计了需求价值度量的目标及步骤。目标是量化需求实际价值，为需求排列优先级，精准投入资源，实现价值最大化；提升研发侧对需求业务目标的认同，并且追踪预计与实际的价值偏差，完善产品设计。

另外，需求价值度的实现步骤分为三大步：

第一步，根据当前业务目标及过往需求梳理需求价值分类，建议从「业务带来的价值」以及「企业自身价值」两方面进行分类；

第二步，在项目协同管理工具配置和追溯流程，如下图：

第三步，定期复盘价值符合度，对偏差问题进行分析，观测效果。

按照上面的步骤，首先，分析需求价值的符合度。我们调查到某个事业部里，某一季度有46%的需求没有达到预期；其次，我们又把整个事业部分了四个跨职能的小团队，让团队之间横向比较，互相效仿、学习。

最后，就是整体的需求价值符合度了。比如，战略合作达到了100%，提高收益也是100%。而提升转化率、规避风险等指标，并没有达到需求的预期价值。

据客户反馈，这种分析方法带来的好处是调动了开发的积极性。他们更愿意通过技术手段去帮助业务实现目标，因为他「知其然，知其所以然」，可以更好地理解这个业务。

「‍度量」的思考与启发

除此以外，我还想为大家分享一下我们对研发度量的思考。

第一方面，效能提升落地，标准工具先行。首先，梳理流程规范，确保组织上下形成一系列的共识语。例如，对目标的认识、统一的术语、业务及数据流的串联、度量单位/度量源的统一等；其次，通过工具固化流程规范，进行度量指标埋点；最后，通过度量展现层，为各个视角、各个领域专家展示他们关心的数据。

第二方面，度量需量身定制。针对研发效能度量，企业需要结合所属阶段的业务目标、管理诚实度、待解决问题等，量身定制度量指标。

第三方面，古德哈特定律告诉我们：「一项指标一旦变化，就不是一个好的度量了。」所以度量要权衡，研发度量指标设计也要有牵引作用，不要一味追求数字上的提高，要看是否真的解决问题。并且，度量应该避免直接与绩效挂钩。如果绩效衡量标准成为了既定的目标，人们往往会对它进行优化，不管任何后果，这样度量就失去了意义。

扫码获取完整版演讲视频和 PPT