关于效能度量的一些见解

在当今企业普遍追求降本增效的大背景下，研发管理效能的度量显得尤为重要。这种趋势不仅影响了研发团队的资源配置，更对研发管理的策略和方式产生了深远影响。

降本增效意味着企业在保持或提升产品质量的同时，需要更加精细地控制成本。对于研发部门而言，这要求研发过程更加高效、资源利用更加合理。在这种环境下，研发管理的效能度量不再仅仅是关注技术创新的数量和速度，更多的是关注研发成果的市场转化能力、成本控制能力以及团队的协作效率。这就要求研发管理部门建立起一套更加全面、科学的效能度量体系，以准确反映研发活动的实际效果。

但在真正落地和实施度量的过程中，会遇到非常多的问题：

那么我们应该如何做才能尽可能的消除效能度量带来的负面影响，让度量对业务产生正向效果呢？

以下为鄙人拙见：

一、认清自己，明确现状

在度量之前，首先需要做的，就是更加彻底地了解自身：我们研发团队的现状是什么？瓶颈在哪里？怎么才能知道瓶颈在哪里呢？业务方对研发团队满意度如何？

我介绍一个方法：精益价值流分析（VSM），它是丰田精益制造的产物，是发现浪费，寻找浪费的起点。在软件研发场景中，可简化图示如下：

图中包含这几个要素：

在绘制价值流图时，端到端考虑价值在团队内外部所有环节的流动，每个环节的团队成员坦诚布公、敞开心扉，勇于面对现实，绘制所处的真实的世界全貌，用自己的双眼看它，而不是臆想或者从几个柱状图上得出结论。

在获取每一个环节的 L/T、VA、W/T 之后，可以绘制如下长城图：

图中，凸起部分表示等待时间，凹下部分表示工作时间。针对此案例我们可以得出结论，整个流程（L/T）需用时23.6天，VA 仅用时188秒，整个过程中，产生了大量的等待和浪费，其中，在第二个工作环节，需等待7.6天，是整个价值流的瓶颈所在。

那么在 ONES 系统中，该如何获知这几个要素呢？通过一个经详细设计的「工作项工作流」来承载，还是以需求举例，如下图：

• 前置时间：需求从创建到最终完成的时间。可以自定义新的「间隔时间」的工作项属性，也可以直接用系统属性「生存时长」。
• 增值时间：讲一个工序，拆分为两个状态。如开发环节，拆分为「开发中」和「开发完成待测试」两个状态。「开发中-停留时间」可大致替代增值时间。
• 流动时间：上图中，状态类型为进行中（橙色）的状态的停留时间之和，可以用「间隔时间」的工作项属性，来计算状态从「设计中」到「部署完成待验证」的间隔时间。
• %C/A：一次性走完所有流程（每个状态的停留次数都为1）的工作项数量/总数量。也可利用「状态-停留次数」属性，来计算每环节的%C/A。

以上数据均可在「ONES Performance」产品中进行分析和呈现。

平均前置时间

总开发时长

可能又有人问了，我们的团队人员，变更状态总是不及时，导致获取到的源数据不准确，怎么办呢？

当然，这个问题只要有人在参与，就一定无法避免。不过，我们可以尽可能地通过自动化的手段，让工程数据（比如代码分支）的提交，跟项目管理数据，工作项的状态联动起来。

在ONES中，我们可以通过工作流的触发器功能，将代码分支、合并请求等工程数据，联动研发任务的状态变化。

然后再通过工作项工作流的后置动作或者配置自动化规则，将任务状态的变化，可以多级联动到产研需求和业务需求的状态。

上图来自《ONES-中国企业软件研发管理白皮书》

以上，我们通过一些手段，数据化展示出了我们真正的瓶颈和浪费在哪里。接下来，我们要针对瓶颈和浪费进行优化。

为什么要这样做呢？想象一下：有一个啤酒包装生产线，灌装工序每次可以完成4瓶，但是封装工序，每次只能完成2瓶。此时我们将灌装工序，扩张到每次可以完成6瓶，但是封装工序速度不变，会发生什么？再想象一下，研发团队做出来的需求，有一半左右市场根本不需要，此时我们提高研发效率，加快交付节奏，会发生什么？

二、设定改进目标，制定相关的指标

此时我们已经知道问题到底在哪里了，我知道你很急但你先别急，还是需要有一套方法来指导：GQM（目标 – 问题 – 指标）方法。是由美国马里兰大学的 Vietor Basili 博士及其助手提出的一种面向目标、自上而下、由目标逐步细化到度量的度量方法，具备较强的操作性和灵活性。GQM 主要用于帮助理解“为什么(why)”以及“什么(what)”需要度量。

其基本思想是：

• 自上而下定义，每个目标划归为一组可量化回答的问题，每个问题通过若干特定的指标来回答
• 通过提出问题，建立和表达隐式模型，解决研发难以定义数学模型的困难
• 自下而上分析解读，数据的收集和分析都服务于清晰明确的问题，进而达成定义的目标

在设定目标时，宗旨是消除瓶颈和浪费，在瓶颈之外进行改进，将会起到反作用。

目标又该具备什么要素呢？

• 明确的：描述清晰，易于理解。
• 时间属性：目标不定时间，相当于没有定目标
• 可实现的：不要好高骛远也不要太过谨慎，目标需要具有一定挑战性，且具备实现的可能。
• 可量化的：要有清晰的量化和衡量标准
• 相关的：目标最终要跟业务结果关联。

AI 在此场景中，也可以帮我们做一些事情，以下内容AI作答：

在软件研发场景中，使用 GQM（目标-问题-度量）方法来提升产品质量时，可以按照以下步骤来定义问题和度量指标：

目标（Goal）

提升产品质量

问题（Question）

1. 产品质量如何定义？
   • 我们需要明确产品质量的具体定义，这通常包括功能性、可靠性、易用性、效率、可维护性等方面。
2. 目前的产品质量如何？
   • 我们需要评估当前产品的质量水平，以便了解提升的空间和重点。
3. 产品存在哪些质量问题？
   • 通过用户反馈、测试报告等手段，识别产品中的质量问题，如缺陷、性能瓶颈等。
4. 如何改进产品质量？
   • 需要确定提升产品质量的策略和方法，如优化代码、改进测试流程等。

度量指标（Metric）

1. 缺陷密度
   • 度量指标：每千行代码中的缺陷数（Defects per Thousand Lines of Code, DPKL）
   • 描述：反映代码的健壮性和可靠性，数值越低表示代码质量越高。
2. 代码覆盖率
   • 度量指标：单元测试覆盖率、集成测试覆盖率等
   • 描述：反映测试的充分性和代码的可测试性，覆盖率越高表示测试越全面。
3. 客户满意度
   • 度量指标：Net Promoter Score（NPS）或其他客户满意度调查结果
   • 描述：直接反映用户对产品质量的感知和满意度，是评估产品质量的重要指标。
4. 性能指标
   • 度量指标：响应时间、吞吐量、资源利用率等
   • 描述：反映产品的性能和效率，对于提升用户体验和满意度至关重要。
5. 可维护性指标
   • 度量指标：代码复杂度（如圈复杂度）、注释率、重构频率等
   • 描述：反映代码的可读性、可理解性和可修改性，对于保持产品质量的长期稳定性至关重要。

下图也是一个 GQM 的案例，可以参考：

三、MARI 方法论，实现持续学习和改进

利用 GQM 方法，将指标设定好了，但工作才刚刚开始。MARI 方法， 是一套面向软件研发,应用于效能度量及实践落地的方法论,其目的是建立效能度量和改进的闭环。

度量 Measure

无论任何改进活动，首先需结合组织及团队实际认知需求，面向改进目标通过量化数据对过程及目标进行刻画，即建立度量。度量需要统一数据及指标的采集方法。

分析 Analyze

有了量化指标，运用统计分析方法，对数据的趋势、分布、关联等信息进行分析，得到对现状的量化理解。

回顾 Review

基于分析结果，对产生“果”（结果）的“因”（影响因子），进行回顾，挖掘对结果产生影响的根本原因，定位关键问题。

改进 Improve

针对关键问题，建立可落地的改进措施，通过调整“因”（影响因子），最终影响“果”（目标）的达成，并进入下一轮度量验证。

每一次小的循环后，效能水平都将上升一个台阶。

四、关注业务结果

银行和金融公司，走在了转型和度量的前沿，但是我们依然能看到大量的失败案例。他们思想不够前卫吗？并不是，他们可以将数十亿美元划拨到IT部门，可见其决心。

然而，失败案例还是屡见不鲜，很大一部分原因是业务与IT脱节。不论是度量还是转型，一个很容易陷进去的坑就是只聚焦于IT，却没有聚焦于价值，即那些需要向客户交付的价值。

在业务的其他部分，我们有基于结果的指标，比如收入、日活跃用户数以及净推荐值(NPS)。问题在于，组织没有一套公认的指标来度量和跟踪 IT 部门的工作，因此只好设定一些代理指标。错误的指标并没有度量价值交付的流动，而是度量 IT项目或活动的“成功”执行。有一句话我一直印象深刻：错误的度量不如没有度量！

所以在制定度量和改进的目标时，一定要明确业务目标，对齐业务目标，定期检视和调整，加强与业务团队的沟通与协作，让产研不再是公司的成本中心，而是利润中心！

本文转载自 Project Pulse，由 ONES 整理发布