0、引言

“效率”作为得物技术部的关键词之一，大家在研发效能、会议效率、协作效率、办公效率等方面一直进行着持续地探索。在实际落地的过程中，为了更好地评估应用效果，往往需要将定性描述转换为可量化的数据指标。这些数据指标可以帮助我们了解研发过程中的变化和趋势。但是你真的能“读懂”这一堆冷冰冰的数字吗？

在看到这些数据指标时，我们往往很容易陷入一个误区：只关注具体的数字，而忽视了数据采集和分析解读的过程。这意味着即使我们对这些指标进行了定期监控，我们仍然不能真正了解研发过程中的状况和障碍。

因此，如何正确地解读这些数据指标变得尤为重要。为了有效解读数据，我们需要了解数据来源和分析过程，以及数据指标与业务实际情况之间的关系。只有这样，我们才能更好地理解我们所面临的问题和挑战，并且采取适当的措施来加以解决。

1、研发数据从哪里来

第一阶段：人肉统计 

当我们从0到1定义一个新流程、新数据指标时，通常是处于探索验证的阶段，这个时候通常不会耗费过多人力来搭建线上化的系统，导致数据采集的过程十分痛苦，文档、表格、甚至群聊等五花八门的数据来源，不少同学应该有亲身体会。

第二阶段：分散、未经处理的系统数据

技术部全链路的研发过程数据往往分散在多个内部系统中，当你需要分析某个数据的时候，可能会涉及到不同系统之间的交互，而各个系统由于数据维度、统计口径的不同，必须先梳理清楚数据背后对应的逻辑，其次再进行数据清洗、关联业务线/部门等统计维度，最终形成可用的数据源。除此之外，一旦涉及到某个系统的改造/数据加工，想要获取到可用的数据更是难上加难。

第三阶段：流程不规范，导致数据不可用

这是系统建设中最常见的问题，由于系统沉淀的数据强依赖用户操作，如果在流程中没有规范化的操作方法及卡点管控，就有可能造成数据不可用。最典型的例子就是项目管理软件中需求/任务的状态流转，会出现任务长时间处于未开始状态、长时间滞留在进行中、任务完成但是消耗的工时为0等各种异常场景。

第四阶段：成熟阶段

工具一体化，流程规范化，数据标准化。效能度量和项目管理人士心驰神往的阶段，这个阶段要流程有流程、要系统有系统、要数据有数据，无需耗费大量精力来获取数据和处理数据。

2、数据指标之略问一二

大数据时代，万物皆可数据化。在研发过程中，沉淀下来的数据可以定义出种类繁多的数据指标，基于这些数据，我们往往会耗费大量人力打造出一个数据指标大盘，甚至美其名曰“驾驶舱”。虽然我们的理想绝不仅限于拥有数据大盘，但现实很骨感，残酷到“你以为的起点竟变成了你的终点”，没错，数据大盘可能是大部分团队的终点，它具有取数、看数以及基础的可视化图表，值得注意的是，面对五花八门的指标，我们稍不注意就会迷失了方向。

2.1 你知道X指标的定义是什么吗？

看到这个问题，很多人认为没有难度，不需要太多思考就可以列出具体的公式和取数逻辑，但是真正想问你的不仅仅局限于此，更深入一步的问题是：你知道X指标为什么这样定义吗？想要通过它来衡量什么？

在软件研发领域，提到研发数据就不得不提研发效能度量，后者在各路大神的研究及科普下已经逐步走向成熟，与此同时也沉淀出很多业内通用的研发效能指标。但如果你仅仅是生搬硬套指标定义，而不去深入理解指标背后隐藏的业务目标，你会发现最终的结果往往不尽人意。所以我们要知其然，还要知其所以然，当你在使用或定义一个数据指标时，必须要清楚地知道度量X指标的真正目标，想要发现或改进什么问题，避免变成纯纯的数字游戏。

2.2 你知道最核心的指标是哪个吗？

在几十个数据指标中，你能分辨出哪个指标最重要吗？看到这里，你可能在仔细对比各个指标的重要性，但是，

这是个带有误导性的问题，在我看来，没有最核心的指标，只是不同的领域会有相对核心的指标。想想新广告法开始限制“最”、“第一”这种词语的使用，是不是感觉也挺合理？这些形容词是需要基于真实场景的，同时又会因为所处阶段不同，导致你关注的指标也会发生变化，就像OKR一样，不同的时期你会设立不同的O，自然就会有不同的KR。

举个例子：

• 公司在Q1要快速扩张，它对应的KR可能会包含DAU、GMV等指标
• 公司在Q2要提升体验，它对应的KR可能有NPS、秒开率、工单解决工作时长等指标。

参照OKR的概念我们也能发现，我们要从一堆指标中筛选出你真正关注的指标，而不是所有指标一手抓。

3、不解读 或 无效解读 = 毫无意义

筛选出了核心指标后，就需要来合理地解读指标。数据指标分成过程指标和结果指标，结果指标只能告诉你好坏，通常需要参照和它相关的多个过程指标来进行归因。

对于大多数人来说，我们不是专业的数据分析师，即使是长期在项目管理和研发效能领域工作的专家，可能在数据分析方面的能力也有所欠缺，所以如何解读数据指标就成了一个难题。

如果你不解读数据指标，直接把一堆指标丢到用户面前，用户看了半天，没看出指标的好坏，也不知道要不要改进，更不清楚如何改进，最终只能是一脸茫然。

如果你用数学的方式进行了无效解读，比如需求吞吐率下降，解读为团队承接的需求数减少（分子），而提报的需求数增加（分母），这就属于无效解读，这个结论几乎没有价值，需要进一步挖掘分子减少和分母增加的根因。

所以，我们要通过数据指标解读出关键性的结论，告诉用户存在的问题及改进的方法，只有这样你的指标才是有价值的，否则空有指标，啥也不是。

4、解读数据指标的几个步骤

度量数据指标不是目标，只是实现目标的手段。我们希望可以从中获得有价值的信息和结论，从而指导实际的业务决策。碰巧之前数据团队的大佬来团队普及数据分析的基础知识，提出了“可量化、可解释、可干预”的观点，此处正好把想问的三个问题分别对应到其中：

图片

第一层：基础

可量化：我们希望通过客观的数据指标来描述现象，就需要明确数据指标的定义，确定其和业务目标的对应关系，判断指标的适用性，以及在不同场景下的不同意义。

第二层：分析

可解释：就是让通过分析数据指标得到的结果，能够被用户理解。在开始正式工作之前，我们先熟悉下列几个问题，因为接下来的工作，主要都是围绕着这些问题进行的：

• 指标对应的数值是好还是坏？有没有基线标准？跟基线相比是好是坏？
• 跟自己比趋势是变好了还是变坏了？是正常波动还是异动？

带着问题，接下来进入正式的研发数据分析流程：

1. 数据采集及清洗：获取到高置信度的数据，同时可能会使用表格或者可视化的图表来展示数据

2. 选取特定的维度，如业务线、部门、个人等维度，得到相应的数据；同时选定基线，得到基线的数据。根据这些数据，我们可以得出指标对应的数值是好还是坏的结论

3. 使用基础的统计学方法，如对比分析、趋势分析等方式对数据指标进行分析，通过横向对比及历史趋势数据的对比，得出趋势变好还是变坏的结论。与此同时，我们还需要分析出指标是正常波动还是异常波动

4. 如果上一步的数据指标是异常波动，则可以对关联指标进行分析，举例：我们发现研发交付周期数据发生异动，同时发现与它相关的需求变更率、缺陷引入率指标都发生了异动，此时可以通过相关过程指标进行下一步分析

5. 通过具有相关性的过程指标来分析主要影响因素，最终定位指标异动的根因。

至此，我们成功定位了指标异常波动的根因，这也预示着第二步的完成。在实际分析的过程中，此阶段往往是最为耗时的阶段，值得注意的是，我们通常不会将整个分析的过程体现到最终的分析报告中，虽然其复杂耗时，但对大多数用户来说，更加关注的是结论而不是过程。

第三层：价值

可干预：通过适当的方法来改进我们归因发现的问题。辛苦了半天，定位到了数据指标异动的根因，但是这并不意味着结束，接下来还有更重要的一步，这一步能体现你对业务的思考，体现你这份分析报告的真正价值，刚刚让我们辛苦了半天的分析过程，也要靠它赢回票价。

• 首先，需要评估指标异常波动带来的影响，以及关联指标异常波动带来的影响，整体是正向影响还是负向影响，如果影响程度可接受，不需要干预，那到这里就结束了
• 其次，结合该指标的历史数据趋势以及其他相关指标情况，尝试对未来做预测，评估指标再次劣化的可能性
• 随后，针对不同的场景及关联指标情况，提供可改进该数据指标的措施，并评估预期效果（注意预期效果和实际执行落地的效果相比可能会打折）
• 最后，评估改进措施所需要的投入，结合ROI来辅助你做出最终的业务决策。

经过这一波分析可能得出一条结论：指标异常波动，相比基线低XX%，经过分析发现本季度遇到了A、B、C问题，归因是X、Y、Z原因，负向影响显著。结合历史趋势综合评估未来发生的可能性约XX%。建议通过1、2、3等方式来做改进，分别预期投入XXX，能够解决XXX问题，并带来XXX额外效果。

结论是分析数据指标得到的产物，它远比冷冰冰的数字有价值。从管理者及普通用户的视角来看，给我一堆数字我也不知道要从哪下手分析，不如你直接告诉我现在的问题是什么，是否需要改进，要怎么做才能改进，改进后能拿到什么结果。

5、结语

在项目管理和度量领域，基础的数据分析能力是从业者们必备技能，你可以不精通，但需要掌握入门技巧，同时必须要有专业领域的业务思考，一旦脱离了业务，数据指标也就变成了纯纯的“数字游戏”。

纵观整个数据分析过程，从取数、分析，到得出结论并给出改进建议，最终形成一份分析报告，哪怕看起来不算特别复杂的一份报告，实际上都包含着编写者们的一把心酸一把泪。

在实际工作中，受惠于系统工具的不断迭代，已经逐渐向系统化的取数和分析过程过渡，大大简化了数据分析的困难和复杂度。在结合人工分析过程中，也在逐步摸索更加高效的方法，快速得出结论和建议。未来也希望能通过系统化、智能化的方式，让大多数人能够看懂数据指标，能够直接利用有效的建议来实施改进，解决望指标兴叹的问题。