效能改进中的度量实践

You can’t manage what you don’t measure. - Peter Drucker

你如果无法度量它，就无法管理它。——彼得·德鲁克

笔者在面试项目经理时，常会抛出这样一个问题：如何在改进过程中进行度量？答案大多是关于质量方面的指标。然而，众所周知，效能管理中的很多问题，并不只是发生在项目的研发过程，还可能出现在其他环节或管理领域。所以，如何进行有效度量，成了摆在管理者和效能改进者面前的一个现实问题。

一、度量的目的

度量是管理者发现和处理问题的有效抓手，所以度量的最终目的一定是为了解决问题。而迈出管理第一步的推动力，则必然是管理者意识到组织可能出现了（或潜在的、预防的）一些问题，但因为没有数据支撑，无法对问题进行定量分析。

所以，笔者认为，度量是基于假设的，只有用数据模型来印证假设成立，才能给予管理者信心，进而采取行动加以改进，最后再基于改进结果，发现更深层次的问题，修正和优化度量手段。形成 PDCA 式的闭环。

二、度量的过程

第一步：指标收集

基于度量目的（即：问题假设），定义相关的指标，进行数据采集。组织的成熟度不同，亟需在当下阶段被解决的问题也各异，需要读者用心挑选。如果能找到有效的指标，则改进工作将事半功倍。举个笔者在有赞效能改进中的实际场景为例：

某个时段收到产品经理的反馈：「最近的项目周期感觉有点长，印象中甚至有一些要持续两个月才会上线」。那么，我们要收集的基础指标就可能包括：历史项目的研发周期、研发周期中各阶段的处理时长、参与人员投入时间及工作量分布、各项任务的依赖关系等等。要看一下所谓的「感觉很久」到底是多久，以及在哪个环节停留得比较久。目的是要「适当缩短项目的研发周期」。

有赞效能改进团队，在组织的不同阶段和场景下，幸运地提取到了若干指标，目前依然在有赞内部自研的「起码效能平台」上持久地发挥作用，现列举如下，供读者参考：

1）流动效率。从「事」的角度，收集每件事（比如：需求、项目、线上问题、工单等）的处理时效，并以进度、周期、 SLA （ Service-Level Agreement，服务等级协议）达标率等方式进行体现。精益方法十分重视流动效率，我们通过指标关注问题是否得以按时解决。下图是用控制流图的方式，展示了在一段时期内，有赞某业务线的项目吞吐情况：

2）资源效率。从「人」的角度，收集研发人员的工作任务，并以各种维度进行聚合。一般来说，研发人员的日常工作大致包括：参与项目开发、处理零碎的日常小需求、解决线上 Bug 等。所有的工作任务都可以量化，然后折算成指标（比如：工时、天数等），便能推算出组织资源的利用率，进一步可以发现资源瓶颈或资源闲置情况。下图是以有赞技术经理的视角查看团队中每个人的工作负荷：

3）价值偏差。也是从「事」的角度，但它统计的是在长周期范围里，与战略目标的一致性情况，代表了组织的交付成果展示，以及按各种细分维度（比如：业务属性、需求来源、当前状态分布）进行的统计和比较。采集价值偏差相关的指标，能帮助我们站在业务的视角，观察研发产出与商业价值之间的关系（并非高流动效率和高资源效率，就能带来高价值回报）。下图是有赞在某一业务线，上线项目与公司战略目标重合度的相关指标统计：

第二步：相关性分析

万事万物皆有联系，指标并非孤立存在的，避免将所有指标一股脑儿平铺罗列——这只是一种无序的堆砌，并没有发挥数据的价值。而通过相关性分析，可以发现一些造成目前状况的驱动因素。这样的成果不亚于发现「在超市里，与尿布一并购买最多的商品是啤酒」。

笔者对有赞的部分度量指标进行相关性分析时，就发现过一些很有趣的现象。

比如下图所示，工单交付（红色折线）的峰值出现在中午前后（12 点）、傍晚前后（18 点）、午夜前后（23 点），这与工单递交（蓝色折线）的时间节奏完全无法匹配。然而，对研发人员的工作习惯进行调研后发现：为了避免时间被碎片化，大家会将自己收到的工单，积攒在某个相对空闲的时间段，进行集中处理和回复。

前文「适当缩短项目的研发周期」案例，当拿到基础指标的数据后，要与研发周期相关的因素进行对照，比如：需求颗粒度不够 MVP （ Minimum Viable Product，最小可行产品）？、人员净投入（并行参与多个项目？）、项目节奏感（缺少项目经理的参与？）、代码质量（缺少单测等必要保障？），分析一下问题会出在哪里。如果条件有限，可参考的数据不完整，那也可以通过跟进项目、访谈、问卷、走查等方式了解和感受，再有针对性地设计关联性的度量指标，去抓住问题的根源。

第三步：结论和行动项

度量数据及其相关性分析是非常重要的改进依据，但如果没有给出一个具有较高可信度的结论、以及可落地的改进项，度量就没有任何意义。切忌不要只是陈述数据的增减变化或图表的走势变化（这谁都看得出来），也不要「推测」可能是什么因素造成的（这并没有说服力），也许未来新生成的数据就与你的臆测相左，结果贻笑大方。而且对当事人来说，容易丧失信心。

此外，所谓的结论，请注意是「较高可信度的结论」，而非完全正确的结论。因为并不存在完全正确的结论。一方面，在结论被落实之前，无法证明它是完全正确的；另一方面，随着时间的推移和局势的发展，最初的「正确」结论会变得并不那么正确。这也是我们为什么说「管理是一门艺术」的原因了。

前文「适当缩短项目的研发周期」案例，有可能是是某一项（或几项）因素造成的影响。故而，我们可以给出一个结论，并提出若干行动项。比如说——

结论：根据数据显示，目前的平均研发周期 X 个工作日。其中技术方案筹备时间约 Y 个工作日，用专家法评估认为筹备过久，且通过项目的过程数据发现，技术负责人未设定技术方案评审的时间目标，调研发现多是在并行处理其他事项，故造成该阶段节奏较为拖沓，影响整体进度。

行动项：

1. 与产研团队共同约定项目流程，增加「技术评审时间」的里程碑，并与各项目经理约定落实；

2. 与技术部门达成一致，技术方案筹备阶段，核心成员切勿并行其他工作；

3. 建立技术筹备时长的数据度量指标；

4. 技术筹备一旦超时，通过工具触发预警，调用企微通知到技术负责人和架构师。

下图是有赞某技术团队，为度量单测质量等情况，而采取的行动（在工位旁开辟一块看板，关键的度量指标达成与否一目了然）。而且，在有赞，这样的实践比比皆是：

三、小结

所谓「数据驱动」，在笔者看来，这并非是盲目地让数据指挥实践，而是以事实调研为前提，再辅以数据度量来证明，并据此制定目标，进而驱动实践。正所谓：

效能管理须度量，问题假设心中酿。

相关指标再三尝，结论目标行动项。

从系统思考的角度看，没有一项数据是会永远增长的，它一定会受到现实中的某些因素的制约（所谓「增长的极限」）。所以在根据度量结果来制定目标时，需要尽量客观和保守（但可以频繁地改进）。上文案例「缩短项目的研发周期」必定是有限的，因为如果过度压缩，反倒会因为方案设计质量降低而可能导致返工。

那么，如果我们想提升处理时效，在拿到度量数据后，是：1）在「数据密集区」附近画一条红线，超过就是违规，抑或是：2）设定一个「期望时长」，以提升「达标率」来作为度量目标呢？这个就留给读者来思考和实践吧！欢迎大家在留言区给出你的答案，并说明理由喔～