00、前言

软件研发管理作为企业数字化的关键组成部分，其核心目标是提升商业效率，带来业务价值。因而该环节长期以来备受管理者的关注。而如何合理地、科学地、可持续地执行这一事项，是部门管理者、项目经理、或数据产品经理常常遇到的难题。今天笔者抛砖引玉，浅谈一些相关的经验与方法。

01、制定目标，以终为始

“无量化不管理”是企业深谙的道理，这一点在软件工程领域更是凸显得淋漓尽致。然而面对研发过程，管理者总是有着头痛的问题：效率低、规范度低、可控度低、交付质量低、人力费用高、交付周期长等。如何解决这些痛点呢?

定位问题是解决问题的起点，其中又以分析度量为定位问题的第一步。面对提升研发效能的目标，可采用“定义→统计→分析→改进”的流程与方法来定义衡量的指标，从而收集数据和统计分析。如下图所示：

02、深入流程，精于业务

如何去定义一套适合自己企业的度量标准呢?通常来说，良好的度量指标体系具有专业而深入的特征。专业来自对软件研发过程的熟悉和长期积累，深入来自对业务领域的了解。必须具有这两种视角，才能制定出准确体现效能的度量方式，否则指标就像空中楼阁一样没有意义。以软件研发行业通用的协同流程为例，全流程一般从工单提交开始，中间经历需求沟通、需求受理、产品方案输出、产品方案沟通、排期预沟通、需求评审、技术方案制定、开发、测试、产品验收、发布，最终以业务验收结束。当然，我们建议勿以业务验收为终点，业务验收之后仍应该持续跟踪业务效果。

研发效能管理具备明显的阶段性指标。对于研发数字化的管理过程，可通过交付效率、交付质量、交付能力四个衡量维度来持续跟踪，如下图所示：

下面展开讲一下相关指标的具体意义。

• 需求前置时间：也称为需求交付周期，是指从需求提出，到完成开发、测试，直到完成上线的时间周期。反映了与问题相关的整个团队对客户问题或业务机会的交付速度，依赖整个组织各职能和部门的协调一致和紧密协作。

• 产研交付周期：从需求被产研团队确认，到完成开发、测试，直到完成上线的时间周期。反映了产研团队的交付速度，依赖需求的拆分和管理，研发团队的分工协作。

• 需求吞吐量：统计周期内交付的需求个数 / 统计周期，即单位时间交付的需求个数。需要注意的是，需求颗粒度要保持一定规则(如约定业务需求、产品需求的颗粒度上限)，避免需求大小不统一导致的数据偏差。

• 线上缺陷密度：统计周期内线上或单个版本严重级别 Bug 数量 / 需求个数。

• 故障恢复时间：线上系统和应用如果发生故障，多长时间可以进行恢复。

• 变更成功率：上线部署成功，且没有导致服务受损、降级或需要事后补救的比例。

• 部署频率：单位时间内的有效部署次数。团队对外响应的速度不会大于其部署频率，部署频率约束了团队对外响应和价值的流动速度。

• 变更前置时间：代码提交到功能上线的时长。反映了团队的工程技术能力，依赖交付过程中高度自动化以及架构、研发基础设施的支撑能力。

以上是指标的定义，而衡量的方法也相当重要。度量指标并非固定不变，在实际使用中可以根据具体情况对元指标自行组合。元指标即最小颗粒度的指标。举例来说，需求交付周期是元指标，需求相关的项目收入也是元指标，将两个元指标组合可得出第三个指标需求性价比(收入/交付周期)，以衡量该需求的价值大小。用于衡量的维度也是多变的，既可以从人的维度衡量需求价值，也可以从业务线的维度来衡量。总而言之，制定指标时需遵循专业的规则，并结合实际业务灵活运用。

我们落地的任何研发效率提升实践，推动的任何敏捷或 DevOps 转型，其目标都应该要促进交付效率、交付质量、交付能力中一个或多个要素的提升，而其中交付能力的提升通常需要一定的周期沉淀和积累，所以是延迟反馈的，但最终还是会体现量化的数字上。重要的事情重申一遍，无量化不管理。

另外，软件研发效能的提升只是过程，最终会助力组织效能的提升和业务结果的优化。所以当我们在设计度量指标体系时，还应该增加业务结果维度的考量，包括业务价值、交付成本和满意度等(包括客户满意度 NPS 及员工满意度 eNPS)。这样的指标体系才更完整，才更能体现出研发效能提升对于组织效能提升的贡献。

03、审慎思考，呈现结果

指标定义完成后，下一步是根据制定好的指标收集原始数据。囿于规模的原因，多数企业的数字化水平可能并不高，因此项目管理、产品研发中的大量数据仅在线下发生，没有留下系统性的记录。于是辛苦的项目经理进入到了熟悉的手工搬数据、洗数据、做报表的过程中。这个过程应该是极为小心的，因为工具不统一，数据分散，一旦vlookup出现错位，对最终的汇报结果都是差之毫厘失之千里。做数据的同学应该对此深有体会。更糟糕的是完全未曾留存过数据，那么将要面临巧妇难为无米之炊的局面。(当然造假数据也不是不行不在本文讨论范围内。)

为避免最终的凄惨局面，我们建议相关岗位的同学即使在未定义衡量指标时，也应对正在发生的业务过程积极留存数据，毕竟未雨绸缪大于后期补救。最好尽量让员工在同一个软件上协同工作(小广告：Please考虑一下ONES)，以防后期在数据统一时阻碍过多，不仅浪费人力成本，甚至可能根本无法得到数据，从公司文化上养成统一的工作习惯与工作方法，对步骤明确的工作类型规范其工作流程，不规范的工作可能引发不可控的风险。

对于最终数据可视化的呈现方法，笔者亦有一点小建议。对于时间周期类的内容，可以制作折线图表示;对于查看占比类的内容，可以使用饼图、环形图，如果需要多层透视，可以增加玫瑰图(也称南丁格尔图)。使用此类高级图表，可能是走向升职加薪的小窗哦。对于不同团队、人的数据的对比，多用柱状图。另外要知道，可视化不仅仅只是将数据变得好看，更重要的作用是便于发现问题的存在。如果能在分析过程中发现问题并提出解决方案的话，小窗可能变成大窗。

04、小心验证，积极调整

那么发现问题之后应该怎样制定解决方案呢?一定要分析造成问题的根因。找到问题根结才能对症下药。一定要针对公司的具体环境进行分析，关键原则是坚持、耐心与灵活应变。需要提醒的是，制定措施时要考虑到是否会带来衍生影响，如果有，那么应提前制定评估办法。

接下来最关键、最激动人心的一步便是验证其有效性。如何验证呢?基本方法是持续观察已制定的指标，监测其变化。符合预期则证明措施是有效的，反之则回到上一步，再次进入分析流程。依然需要注意的是，由于措施的实行，或导致原有指标已经不能百分百适用，因此制定改进措施时也要同期关注是否应更新度量体系。如果二者没有同步更新，很可能会导致验证的结果不准确，进而前功尽弃。在明确措施的有效性之后，应尽快把措施固化到工作流程里去，从根源上提升整体效能。为了保持良好的效能水平，应长期坚持定义→统计→分析→改进的过程。

效能提升的过程与长期敏捷迭代的过程是相似的，在遇到困难和收效渐微时要保有耐心与平和，去观察、接纳并坚持做出改变，最终收获由健康心态、终身学习和持续改进的习惯所带来的成功。

预祝读到此处的你在该过程中发现属于自己的成就与快乐。

@一个圆圈儿，SaaS公司产品经理;擅长AI、搜索、数据分析、商业化;智能客服系列文章作者;“数据人创作者联盟”成员。