实践案例分析：让数据说话，高效盘点研发效能，助力企业2024发展

本文主要是介绍实践案例分析：让数据说话，高效盘点研发效能，助力企业2024发展 | 活动回顾，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前不久，思码逸 DevData Talks 落地深圳南山区，举办了一场以「中小到千人规模团队研发效能提升实践」为主题的闭门沙龙，共探研发增效之道。活动邀请到了几位来自不同研发规模的团队的研发效能负责人齐聚一堂，分别是平安银行组织级研发流程体系负责人张文涛、软件研发科技公司研发效能负责人吴衡林、思码逸咨询总监兼研发过程提效专家关钦杰，稿定设计通用产品研发总监潘锦，他们深入探讨了研发团队管理中的常见困惑，从不同的视角分享研效提升的实践经验。

我们将回顾思码逸咨询总监兼研发过程提效专家关钦杰分享的《让数据说话，高效盘点企业研发效能》。由于演讲内容较长，我们将分为两篇文章来回顾该演讲。

演讲内容分为三个章节：

如何实现高效盘点：聚焦核心问题，运用复盘者思维，构建数据抓手
企业级客户应用案例：价值管理、需求预估、识别浪费、辅助决策
研发效能数据平台 DevTable：盘点数据自动汇总、效能报表即时生成

本文将包含第一章节及第二章节的部分内容，如果大家对于一些细节数据，以及演讲人与现场观众的问答交流内容，可在文末扫码观看回顾视频，并免费下载演讲人的 PPT。

思码逸咨询总监兼研发过程提效专家关钦杰

年前，我们同时帮几十家客户进行年终的效能盘点，但我们的盘点方式并非人工。因为我们有一套自动化看板，可以帮助客户快速将数据处理成年终盘点看板。我们今天就讲一讲如何进行效能的年终盘点。

如何实现高效盘点

首先，我们来探讨如何实现高效的盘点。我强调了几个关键词：聚焦核心问题、运用复盘思维和构建数据抓手。首先，分享一些我认为很多人都深有体会的观点，这些观点摘自《得到管理训练营》。大家都在年前忙于年终盘点，我们到底希望在盘点上获得什么样的结果呢？以及如何为2024年工作做规划？助力企业发展。我认为以下三点很能引起大家的共鸣：

第一，怎样展现全面的工作成果，让自己不被埋没?
第二，怎样激活团队面貌，展现自己的管理能力?
第三，怎样管理上级的感受，为明年的工作做铺垫?

当我们盘点时，我们时常面临时间紧迫和资源有限的挑战，难以进行全面细致的盘点。在这种情况下，我们需要关注核心资产，即人、事和钱。这三要素构成了年终盘点的基础。在后续讲到的案例和应用中，我们将聚焦于这三个方面。

从人的维度来看，我们需要通过数据来评估关键人力是否被合理利用。此外，还有一个重点是确保所有员工的付出都能得到应有的回报，不仅仅是那些善于自我展示的人，也包括那些不善于展示的人。

在事的维度上，我们需要清楚地认识当前的核心问题是什么，以及我们的工作是否投入到有价值的事务上。此外，我们还需要关注如何提升下限，确保工作质量得到持续提高。

提升下限这个词可能让许多人感到困惑，为什么我们要专注于提升团队的短板呢？其实，无论团队的上限有多高，真正决定团队能力的是团队的短板。因此，找到并提升这个短板才是提高团队整体水平的关键。

关于钱的问题，其实就是如何进行成本管理、量化投入产出比、盘点人力资源利用率以及合理利用资源。这些方面的优化对于提升团队整体效率至关重要。我们需要关注有多少人正在合理且充分地完成自己的工作。此外，对于一些大型甲方客户，我们也需在此节点上准确结算人力成本。

我们需要聚焦以上三个维度，全面提升团队的整体水平。

在盘点时，运用复盘者思维对于数据的复盘和整理非常有帮助。这是来自一本叫做《复盘高手》的书。书中提出了四个复盘理念（如上图所示），对于我们进行数据盘点非常有价值。

首先，“刀刃向内”指的是在寻找问题时，先审视自己的能力范围内可以控制的部分，而不是完全依赖外部沟通或协调。我们需要清晰地定义问题并寻找解决方案，而不是仅仅关注表面现象。

其次，“0.1>0”意味着当面对一个问题，尝试所有解决办法后，可能无法颠覆性地改变它。但我们是否可以多做一点，降低出错概率，向更好的方向推进一点呢？

第三，“墙即是门”是来自佛经的一句名言。它提醒我们，遇到困难时，我们可以将其视为墙壁，也可以视为门。关键在于我们能否调整心态，找到解决问题的方法。例如，当我们遇到多变的客户需求时，可以通过反思来寻找环节中的不足，从而找到解决问题的方法。

最后，“鱼不论水”意味着在面对困难和问题时，我们应该更好地利用现有资源来解决问题，而不是一味地争取更多资源。因为资源的获取是有限的，我们需要学会利用现有资源解决问题。

这几点复盘思维对于团队管理者或技术管理者来说是非常重要的能力，可以在实际工作中加以运用和思考。

为了实现我们想要的盘点结果，聚焦重点问题，我们需要利用数据抓手。在我看来，数据是一种沟通语言，也是一种符号。当我们与研发和产品团队沟通时，可能会遇到一些问题。产品团队可能会抱怨需求补量不足，新需求难以实现。而研发团队则会抱怨需求变更频繁，导致大量返工，影响新需求的开发。这些问题出现的原因之一是我们在沟通时是否使用了统一的语言？

为了更好地与上下游沟通，我们需要关注一些关键指标。这些指标数据是我们互通的重要语言，有助于我们更好地了解团队的表现和状态。此外，数据还可以帮助我们打开“黑盒”，即了解团队内部的工作流程和问题。没有数据支持，管理效果肯定会有所不同。当我们需要向上级争取资源、增加人手或管理预期时，数据是最有力的依据。

因此，在进行盘点时，我们必须善于使用数据抓手。这不仅可以帮助我们更好地了解团队的工作状况，还可以提高沟通效率和管理效果。通过数据抓手，我们可以更准确地评估团队的能力和表现，并找到需要改进的领域。这不仅有助于提高团队的工作效率和质量，也有助于提高整体业绩。

企业级客户应用案例

案例一:事务与当量指标融合、数据辅助资源决策。

接下来，我们深入探讨一些企业级应用案例。我们要介绍的第一个案例是一家大型证券公司。这家客户拥有自主研发的项目管理系统，类似于JIRA、禅道、TAPD 等工具。同时，他们还建立了一套 BI 系统，用于追踪需求立项和结果的过程数据，如需求吞吐量、需求价值等。然而，在实际管理中，他们遇到了一些问题。

首先，他们发现很难对这些指标的健康度进行评估。例如，本月的需求吞吐量是否合理，下个月预期可交付多少需求？指标的变化是否合理？如何通过结果性数据深入到过程中找到效率低下的原因，单独看结果指标是不够的。

此外，他们在定义考核指标时也会遇到一些问题。例如，他们将需求的交付率作为考核指标。然而，一旦设定了这个考核指标，就会出现一个趋势：大家会将需求拆得更细，以提高交付率和完成率。如果大家都去“美化”这个指标，就会变成一个管理的痛点。

为了解决这些问题，这家客户希望引入一个能够更好地校准需求颗粒度和复杂度的指标。因此，他们找到了思码逸，引入了代码当量指标，与事务分析结合，重点度量分析产出和效率。此外，他们还希望看到一个更客观的、去除了代码行水分的类等比指标，以了解实际的研发工作量以及这些工作量是否花在了有价值的事情上。这些都是我们在为他们做产品导入时需要解决的难点。

基于他们现有的平台数据和思码逸DevInsight 设计的可用数据，我们共筛选出了约 30 个指标。这些指标数量较大，因为我们需要从不同维度和颗粒度来观察数据。其中包括全局指标，即公司一级和组织一级的指标，以及部门间的横向比较指标。另外还包含一些可以帮助他们了解与行业相比所处水平的指标。整体的指标框架如上图所示，红色部分是客户自研平台提供的数据指标，而黑色部分则来自思码逸DevInsight。

面对众多的指标，如何有效地运用它们成为了一个重要的问题。在与客户的访谈和沟通中，我们发现指标的首要任务是满足不同管理者的信息需求。因为只有获取这些数据信息，管理者才能了解研发的现状，发现问题，并为他们的管理决策提供参考。

因此，在一阶段，我们为客户定义了两个关键目标：一是为中高层管理者提供数据，这些数据主要侧重于结果性指标。他们希望利用这些数据快速定位管理中的短板，集中精力进行管理，而不是逐一查看所有团队。他们关注的是问题团队在哪里以及问题出现在哪个环节。

另一个目标是满足一线管理者的需求。他们需要运用我们的数据来发现项目实施过程中的问题和风险，并调动每个团队成员的效能。

这些都是我们在讨论指标时关注的关键点。通过满足不同管理者的信息需求，我们可以更好地支持他们的决策，提高团队的效率和绩效。

如何解决中层管理者的诉求呢？

中层管理者的诉求，包括：

面向价值，判断投入与产出
同行对比&结果指标，评价整体效能
横向识别效能差异，聚焦管理精力

在指标设计的整个过程中，我们采用了回答问题的方法。通过访谈获取问题，我们探讨是否能用数智化的方式为这些问题提供客观的答案。

首先，我们要明确产生价值的需求有多少。在设计这个指标时，我们与客户进行了一些深入的讨论。例如，我们能否量化需求的价值？如何量化需求的价值？这其实是建立指标体系时的一个重大难点。我们知道，建立和维护众多指标需要成本。

客户通过与我们的讨论，明确了需求转化率这一指标的定义。产品经理在提出需求时，不仅需求可以直接下放到研发，还要给需求设定一个目标。这个目标可以是经营类需求，即上线后能产生多少收益；也可以是性能类需求，即降低返工的比率、快速响应的延时速度降低了多少。这些目标应在需求提出时就明确。

在需求实现过程中，我们通过度量需求上线后的日活、月活响应时间等来监测需求是否达到预期目标。如果达到，则认为该需求具有转化率。整个漏斗可以展示达成需求的达成率，如100%的占比、200%的占比等，形成了一个需求的价值漏斗。

有了这些数据后，我们通过每个 commit 与需求之间的关联，获取了实际开发的工作量，并分析工作量与需求转化率之间的相关性。通过这种方式，我们可以找到哪类需求工作量少但转化率高，哪类需求工作量多但转化率低。进一步分析这类需求的特征，我们可以从效率和品质方面进行优化，找到关键少数。

我们通过分析研发工作量，即代码当量，在各类项目需求上的分布，判断关键人力是否投入到高价值需求上。

思码逸 DevInsight 引入了行业300家企业的项目数据，用于计算行业基线，通过与基线的对比，可以帮助企业了解当前研发水平和产能增速，从而明确其在行业中的位置。

对于 ROI，我们通过分析不同人力投入产出比的变化，观察其趋势与历史同比相比是上升还是下降，以了解投入产出的匹配情况。引入行业中位数、历史同比数据和企业均值，判断研发效率波动是否合理，是否存在下降趋势。

另外，我们还通过代码当量来判断人均的效率，并引入行业中位数，让企业可以了解自己研发人均生产率在行业中的大致所处位置。

在部门层面，我们会提供两方面的数据：部门产出和部门效率。部门产出主要是体现各团队的产能分布，以及产能增长趋势，这里的产能还是基于代码当量来计算得出的。

在部门效率方面，我们不仅要看同比，还要横向比较。关键在于比较标准的合理性和准确性。例如，图中数据存在明显差异，前三个团队在能力范围内具有可比性，而后三个团队的可比性较小。为了理解数据分组的差异，我们需要探究原因，例如业务差异。

如何解决一线管理者的诉求？

一线管理者的诉求，我们在前面说过，包括：

面向过程，发现问题/风险
识别产出、效率和资源问题
管理研发团队成员效能

通过数据图表，我们展示了研发效率的生产率趋势，发现其快速上升且波动较大。这提示我们关注团队中是否存在工作不均、加班集中或人员等待任务的现象。通过数据变化，我们评估人力负载和质量风险。同时，引入同比数据，考虑到项目开发的阶段性特征。在需求活跃阶段，代码提交量可能较高；而在维护阶段，代码提交量会减少。因此，我们需要更长时间段的数据来准确评估生产率的变化。同时，与同比数据比较，进行验证。

这个数据图表展示了项目中每个人生产率的分布情况。通过观察象限和散点，我们可以识别出关键人力，即少数人拉高了整个团队的效率。要进一步了解这些关键人力存在的原因。例如，可能是由于技能瓶颈导致的，某些任务只能由少数人承担，其他人无法胜任，导致等待状态。另外，也可能是由于解耦工作不够好，需要将关键路径任务进一步解耦，均衡地分配给其他成员。针对关键人力，首先需要确定他们是否真的是团队的技能瓶颈。此外，还需评估这种现象给人力资源带来的风险。

项目效率

针对需求价值与指标健康度问题，思码逸提出了解决方案，即将需求与代码当量进行对比分析。理论上，需求最终落实到代码上，需求交付量与对应的代码量呈正相关关系。在分析中，我们发现有些需求与代码当量高度拟合，表明需求颗粒度的拆分偏差在可控范围内。我们可以利用历史人均当量来预测需求的吞吐量，为需求预估提供参考。这是一个相对准确的预估模型。另外还有一种情况，我们还会发现一些需求与当量之间不存在线性关系，这表明需求拆分的颗粒度大小的可比性不高。利用代码当量这一类等比单位，我们可以更好地评估需求的合理性。代码当量可以作为一个类等比单位。

在对需求进行校准后，我们将其作为个体用于计算需求的吞吐量。这是因为我们在估算需求时可能存在不准确性，特别是使用敏捷方法进行估算时。如下图所示，我们通过分析历史数据中的故事点的污点与当量之间的关系，对每个人的估算偏差进行了分析。分析结果显示，一些人在估算时存在偏乐观，即他们往往会把工作量估低；而另一些人则存在悲观的偏差，即他们往往会高估工作量。进一步探究发现，偏外包的人力更倾向于做出悲观的估算，而偏内勤的人力则更倾向于做出乐观的估算。这些数据分布可能与我们的主观判断不完全一致，但数据为我们提供了有价值的信息。我们了解到，在估算时存在乐观或悲观的偏差，因此我们可以利用这些偏差形成加权系数，对估算者进行非侵入式的校准。

下图是客户在每次迭代回顾会议上会看的一张图。它通过分析每一次代码提交来追踪任务的性质。通过这样的分析，我们可以了解到任务是为了交付新需求、处理需求变更还是进行返工或偿还技术债务。通过分析这些任务的工作量分布，我们可以评估在一个迭代周期内，工作量是否主要集中在产生价值的新需求上，还是更多地用于变更和返工。此外，这些数据还可以作为与产品团队沟通的依据，帮助他们更清晰地定义和管理需求。

在质量方面，思码逸 DevInsight 还提供了一个重要的功能，即扫描代码并识别函数的圈复杂度。函数的圈复杂度越高，出错的概率越大。因此，对于具有高复杂度的函数，一旦出错，其影响可能会很大。该工具的这一功能有助于发现潜在的质量问题，从而确保软件的质量和稳定性。

下图是一张帕累托图，它很好地验证了阿巴定理。简单来说，这个图展示了团队中贡献了80%产能的人员比例。从图中可以看出，33.5%的开发人员贡献了80%的产能。如果用比喻来形容，假设团队有10个人，其中只有2.5个人在真正工作。作为技术管理者，我们需要思考是否能接受这种情况，以及从图中能否发现问题。从图中可以观察到少数人力贡献了大部分工作量，我们需要探究这些人力是否存在技能瓶颈。如果是这样，我们需要进行整体技能培训，或者开展业务讲解和沟通会。此外，我们还应该考虑将任务进一步解耦并均衡分配给其他成员。这个工具提示我们在效能管理上存在的问题。