思码逸张超：从数据到管理，如何利用数据优化研发效能？

4月15日，思码逸高级咨询专家张超在 QECon 质效城市论坛【成都站】分享了主题为《从数据到管理：如何利用数据优化研发效能》的演讲。

• 数据在研效管理中的作用

• 研效数据分析的难点

• 从数据结果到管理洞见

• 利用数据优化研效的总结与思考

以下内容根据张超老师分享内容整理：

当有了一站式的研发管理平台之后，当有了一定的工程能力支撑之后，如何利用研发过程中沉淀下来的数据，持续地为研发效能的提升做贡献？最近 ChatGPT 在各行各业都非常火，我和 ChatGPT 聊了聊研发效能，ChatGPT 也阐述了软件研发度量的价值。

通过与 ChatGPT 的对话，我们可以总结出落地效能度量价值要解决的问题：

• 数据驱动决策：如何通过数据看状态、识差距、定目标？

• 改进团队管理：如何改善团队效能，帮助个人解决效能问题？

• 优化交付过程：如何识别产品交付过程中的问题、瓶颈点？

研发效能评价

在第一部分中，我们讨论的是软件研发的评价。评价是改进的基础。在了解现状、清晰地看到现状并对其进行评估后，我们才知道如何进行改进。

多维度分析，避免用部分指标评价复杂整体

以下分析图中，蓝色和黄色的柱子分别是我们的投入和产出；红色的虚线则是我们的投入产出比，相当于我们的月人均代码当量产出；最重要的信息是一条深红色的趋势线，表示出投入产出比呈现上升趋势。

根据深红色的线，我们可以发现我们这个月人均的代码当量产出呈现上升趋势。从这个趋势来看，我们研发团队的状态很不错，我们可以保持目前的步调继续往前走。但是，我们还需要看另一个维度的分析，也就是研发人员的产出分布情况。

我们使用了思码逸企业版帕累托分析视图，发现在团队中20%左右的人员产出了 80%代码。这说明团队存在人力依赖风险，贡献集中在少数人身上。因此，我们现在的研发状态并不健康，我们需要调整我们的资源利用率。

综上所述，软件研发是高度复杂的活动，需要考虑多个因素的相互作用，不能用单一的指标或部分指标来评价。就好比当一个男孩或女孩决定选择伴侣时只看某一个方面，比如对方人好或有钱，往往是不科学的，也容易带来不符合期望的后果。同理，对于研发效能表现的评价也不能只用单一指标。我们需要看多个维度，比如多快好省的四个维度，看不同维度上它存在什么样的问题，以便综合评估对效能的影响，并确定改进措施。

对照数据标尺，评估现状定义目标

另外一个案例是关于累计代码当量的增长趋势，也就是下图里的递增曲线。这条曲线是代码当量增长的趋势变化。（点击链接查看代码当量信息?https://www.merico.cn/eloc）

单独看这条曲线，我们判断不出效率产能增速是快是慢。这时，我们需要通过对比历史数据、同行数据，建立一个数据标尺，从而发现我们目前效能的状态如何，并指导下一步的管理行动。

区分特性，避免一刀切标准

接下来的这个例子里，我们对某家客户的四个团队进行了效能度量分析。左边的图是一个团队的人均生产率象限图，从中我们发现四个团队的生产率分布非常不同，有很大差距。但如果武断地说第一个团队和最后一个团队的生产率不行，这样的结论也是不准确的。

我们对这些数据进行了标准差显著性检验，发现这个检验也能得到一个结论，即团队之间的数据差异非常明显，不能把它们放在一起进行对比。因此，我们将第一个团队和第四个团队进行对比，将中间的两个团队进行对比，才能得到有效的管理输入。

基于这些评价思路，我们可以客观评价团队现状，给出有效的管理方向。接下来，我们将这些评价交给我们的一线团队管理者，看看他们如何利用数据来改进团队管理。

研发效能改进

关注趋势变化，识别关键少数

回到前面效率+贡献均衡度交叉分析的例子。拿着两张图表，如何解读并发现改进空间呢？一个有效的方法是从时间维度去看，在趋势里找到关键点，进而下钻分析根因。

数据显示，团队在某些月份出现了不正常现象，例如贡献均衡度和生产率均下降。这表明团队成员普遍处于不饱和的工作状态。我们需要进一步复盘，是否存在业务供给问题、工具支持卡点或资源分配卡点等问题？

在其它几个月份，贡献均衡度较低，但生产率较高。这种现象表明存在少出高产出人员，团队存在人力依赖风险。我们需要考虑调整任务拆分，平衡的分配给其他人员，并分配给其他团队成员，以确保团队成员能够以均衡和健康的状态工作。

这里补充一句：关键点不仅是合理区间以外的异常单点，还包括（但不限于）连续上升/下降的趋势、数据点的上下分层、连续多个点临近均值一侧等，它们意味着研发团队中可能发生了值得注意的变化，可能是出现了风险需要尽快应对，也可能是新实践发挥了作用。研发团队成员共同参与探讨，来挖掘这些重要信息。

度量与业务连接

有些研发管理者希望不仅把效能度量用于评价和改进研发环节，更希望用数据说明研发团队带来的业务价值，或者通过数据给到业务关键反馈，改善价值流交付结果。那么就需要以价值为导向，用连通业务的指标衡量研发效能。回答的问题包括：

价值流显示化，跟踪价值生产力与交付趋势

左侧的图可以看到其中有三种不同的事务类型：缺陷、事故和需求。针对这三种不同的事务类型，可以根据版本趋势来观察交付数量，进而评估研发交付价值的流动速率。

通过数据我们发现团队的事务交付数量呈下降趋势，尤其是需求的交付数量也在下降。这并不是一个良好的状态，我们需要采取一些管理手段来解决。

有些管理者会说，不同需求的颗粒度大小不同，用完成数/交付数来统计不靠谱。那我们可以使用代码当量来校正需求的大小，观察每个需求的当量大小。可以通过箱线图来观察不同类别的需求颗粒度分布情况，以抓住需求颗粒度大小的两端，集中我们的管理精力来分析两端的拆分是否合理。通过这种分析，我们可以逐步改善需求拆分，使拆分更加合理。

与业务目标对齐，通过指标给业务提供及时的价值交付反馈

除了流动速率，以下价值流动指标也值得关注：

• 流动分布：交付的流动项类型比例，用于判断交付与业务诉求是否匹配，需要随时间及业务需要及时调整和管理

• 流动时间：统计前置时间、流动时间和各环节的周期时间，发现交付过程瓶颈，合理管理业务方预期

• 流效率：活跃工作状态占价值流总消耗时间的比例，发现过程中的等待浪费，改善团队协作

• 流动负载：并行流动项数量，并行处理过多的流动项会导致效率降低。流动负载时流动速率、流动时间的先导性指示器

• 千当量线上缺陷率：优先度量终端用户可感知的质量指标，从而识别关键质量问题，有的放矢地进行质量内建

• 交付价值与成本：在共识基础上量化交付项的价值，找到那些工时投入多、交付价值低的项目，深入分析合理分配成本

度量是长期过程，持续监控与改进（参考 MARI 方法）

效能度量是一个长期的过程，需要不断对流程进行闭环改进，才能实现效能持续提升。

大家可以了解下?MARI?方法（www.openmari.com），度量-分析-复盘-改进-度量，层层递进形成闭环，效能提升才能够往良性方向进一步发展。