【VSM每周观点】价值流度量指标应用：思想、原则、策略｜第6期

本文目录

01 前言

02 度量指标背后的DA思想

03 度量指标的8个基本原则

04 软件研发效能度量原则

05 本周推荐阅读

前言

我们在上周（VSM每周观点第5期）分享了业界非常全面的价值流度量指标体系和度量指标全景图。那么，这么多度量指标我们是否要全部采纳呢？我们如何根据自己组织的情境选择合适的指标呢？应用指标的过程中有什么可以遵循的思想和原则吗？

本期我们为大家揭晓应用价值流度量指标背后的思想、原则和指导方针。

度量指标背后的DA思想

DA 是什么？

规范敏捷（DA™）思维模式是以原则、承诺和指导方针的形式体现。规范敏捷实践者相信DA原则，因此我们承诺采纳这些行为并在这样做时遵循这些指导方针。

DA原则（Principles）

规范敏捷（DA）包括了8个原则，其中有3个是跟度量指标密切相关的，也是我们在实践度量时应当遵循的原则。

DA承诺（Promises）

规范敏捷（DA）在思想层面上提出了8个承诺（Promises），有3个是与应用度量指标相关的。

使工作和工作流可见（Make all work and workflow visible）：度量是为了使工作和工作量流可见。报告指标是让领导和股东看到工作、业绩和结果的一个方式。

持续改进（Improve continuously）：度量本身是为了发现问题所在和潜在的改善点，从而持续改善。我们必须知道我们需要改进的地方以及如何改进。指标提供了起点，并使我们能够做到持续改善。

DA指导方针（Guidelines）

规范敏捷（DA）提供了8个指导方针，有2个可以更好地指导我们应用度量指标。

通过度量提升效能（Adopt measures to improve outcomes）：在度量方面，注意情境。我们希望改进的是什么？质量？产品上市时间？员工士气？客户满意度？还是它们之间的组合？每个人、每个团队和每个组织都有自己的改进优先级和自己的工作方式，因此他们将拥有自己的一套度量标准，并通过收集这些度量数据，以洞察他们当前的工作情况，更重要的是，了解后续如何调整。这些度量会随着其情况和优先事项的演变而随着时间的推移而演变。这意味着我们的度量策略必须灵活且适合目标，并且会因团队而异。

创建半自治的自组织团队（Create semi-autonomous self-organizing teams）：有些团队在领导层提供的边界范围内，在日常层面上自我管理。当团队朝着他们设定的具体结果衡量他们的进展时，他们更有能力提高他们的表现。

度量指标的8个基本原则

原则1：这里没有简单唯一的答案

对于度量来说，没有最佳的答案。你需要根据你的团队和上下文情况来定义你的度量标准。如果你需要一些想法，可以从通用或常见的度量指标开始，并在实践的过程中持续调整。

原则2：每一个度量指标都有其优点和缺点

了解并分析你正在考虑的度量指标，根据其优缺点找到何时应用以及何时不应用这些指标。我们可以通过收集多个指标提供足够的洞察数据。

原则3：从结果和目标指标开始

我们搜集的指标应该能够为我们提供一种洞见，用于判断我们是否完成了预期的成果。我们可以从业务、产品和技术多个维度进行度量。 （指标详见 第5期文章）

原则4：你度量什么，就得到什么

我们采用的度量指标能否激励预期的行为方式？你度量团队的方式将改变其团队的行为模式。因此，确保你清楚你想要促进和激励什么样的行为。

我们是否得到我们预期的成果？确保你度量的指标是你真正想要改进的。

原则5：尽可能实现自动化

度量指标的自动化能力可以降低数据采集成本、提升数据准确率，获取实时的反馈。目前业界主流价值流管理平台（VSMP）或度量平台可以提供自动采集能力和实时的洞察数据。

原则6：趋势优先于数量

如果两个团队同一度量指标的数值是一样的。但是，其中一个是处于上升趋势，而另一个团队是处于下降趋势。此时，你有更多关于每个团队进步的信息。单靠量化的数据你可能无法判断该团队是处于上升还是下降趋势；而度量趋势有利于我们判断当前的实践/行为是否有效果，并决定继续遵循该实践还是采用新的实践。

原则7：领先指标优于滞后指标

领先指标为你提供对正在发生或即将发生事情的洞察。而滞后指标展示的是已经发生过的事情。领先指标可以为我们提供实时的反馈，便于及时发现问题和调整，而滞后指标一般用于事后回顾和总结。

原则8：拉动（Pull）优于推动（Push）

不管什么时候当人们想要用到度量数据的时候，度量指标必须是实时可用的。仪表盘（Dashboard）是一种拉动（Pull）的机制，而状态报告（Status Reports）是一种推动（Push）的机制。

软件研发效能度量原则

在2022年由茹炳晟和张乐2位老师领衔主编的书籍 《软件研发效能提升实践》也总结了软件研发效能的7个度量原则。

1）结果指标优于过程指标：以终为始，通过结果指标评估结果，通过过程指标指导改进。

2）全局指标优于局部指标：过度局部优化可能导致全局劣化，只聚焦在易于度量的局部指标上，会以牺牲组织更好地提升全局目标为代价。

3）定量指标优于定性指标：尽量使用量化指标客观评价，并通过系统自动采集，降低对团队的干扰。也不排除部分综合评价的定性指标。

（可以发现，这条原则与DA第6点原则是不一致的，对此你怎么看？）

4）团队指标优于个人指标：指标设定需要促进团队协作，共同努力达到组织目标。不能因相互冲突的指标而破坏团队配合，制造出更多的部门墙。

5）指导性，可牵引行动：指标设定为目标服务，指标数值和趋势可以牵引团队改进，比如适当设定缺陷类指标可以促进质量内建能力的建设。

6）全面性，可相互制约：如：需求周期 vs 缺陷数量；需求吞吐量 vs 需求规模；研发周期 vs 技术债务。

7）动态性，按阶段调整：随着团队能力的提升，指标也需要随着进行适当调整，从而促进团队持续改进。