度量避坑指南，合理选择指标（下） | IDCF

作者：Patrick Kua  领导开发团队利用敏捷方法为客户提供有价值的软件，他是《回顾手册：敏捷团队指南》的作者

译者：冬哥

原文：https://martinfowler.com/articles/useOfMetrics.html

三、更恰当地使用指标的指南 

鉴于因指标使用不当而出现的不良行为，这是否就意味着它们没有立足之地？度量指标当然有其发挥空间，只是需要一种不同的方法。使用以下指南可引导你更恰当地使用指标：

• 明确地将指标与目标联系起来；

• 倾向于跟踪趋势而不是绝对数字；

• 使用更短的跟踪周期；

• 当指标停止推动变革时改变指标。

3.1 明确地将指标与目标联系起来

在传统风格中，管理层决定实现特定目标的最佳措施是什么；然后，管理层根据该措施设定目标；然后，管理层只向从事工作的人阐明这个目标，通常是用数字表示。为监控目标进展而选择的措施与实际目标本身之间的界限很模糊。随着时间的推移，衡量背后的原因消失了。即便是该指标与最终目标不再相关，人们却依然专注于实现指标。度量的一个更合适的用途是确保所选的进度度量（指标），始终与其目的（目标）相关。

例如，在软件开发的场景中，您可能会看到如下定义的指标：

• 方法必须少于 15 行，一个方法的参数不能超过 4 个，方法圈复杂度不得超过 20。

适当地使用度量标准，每一项措施都应与其最初的目的明确联系起来。当前的跟踪和监控机制必须与其目标解耦，并明确目标以便帮助人们更好地理解指标的意图。存在于更丰富的上下文中的度量将指导人们为实现目标做出更合适、更务实并且更有用的决策。缺乏目的，付出的努力意味着人们想方设法创造性地和系统做游戏，最终将偏离真正的目标。

这是前面例子该有的样子：

• 我们希望我们的代码不那么复杂并且更容易改变。因此，我们的目标应该是编写具有低圈复杂度（小于 20 行）的短方法（少于 15 行）。我们还应该瞄准少数参数（最多四个），以便方法尽可能保持专注。

将指标与目标明确联系起来，可以让人们更好地挑战其相关性，找到满足需求的其他方法，并帮助人们理解数字背后的意图。如果没有明确的目的，人们可能会想方设法，却无意中违背了隐含的目标。例如，许多技术可能都有助于减少方法长度，但如果不以正确的意图应用则更难阅读，从而增加整体复杂性。

软件开发的本质意味着大多数工作是知识工作，因此很难观察。监控活动（他们坐在电脑前的时间）很容易，但很难观察他们产生的价值（满足实际需求的有用软件）。人们越远离代码，他们就越难理解所涉及的复杂性。这意味着，对于离工作最远的人来说，要真正了解监控目标进展的最佳措施，即使不是不可能，也是非常困难的。

转向更恰当地使用指标意味着管理层不能孤立地提出措施。他们不能再自欺欺人地认为自己知道监控进度的最佳方法，并停止执行可能与目标最相关也可能毫不相关的措施。相反，管理层负责确保始终保持最终目标，与最了解系统的人合作，提出最有意义的措施来监控进度。

3.2 倾向于跟踪趋势而不是绝对数字

管理层对于指标难以抗拒，因为它将组织的复杂性提炼为每个人都能理解的东西，一个数字。很容易看出一个数字比另一个更大或更小，或者一个数字与另一个数字的距离有多远。但是很难看出这个数字是否仍然相关。传统的管理方法喜欢使用这些指标，因为它可以在实现目标时轻松沟通。“只要达到这个数字，我们就会没事的”。

当你将一个定性的和高度解释性的问题（想想生产力、质量和可用性）转化为一个数字时，任何数字都是相对的和随意的。5% 和 95% 的代码覆盖率可能存在显著差异，但 94% 和 95% 之间真的存在显著差异吗？选择 95% 作为目标有助于人们了解何时停止，但如果需要付出一个数量级的努力才能获得最后的 1%，这真的值得吗？这只是人们必须在他们自己的组织环境中主观解决的事情。

与目标是否实现相比，查看趋势提供了更有趣的信息。确定是否达到目标很容易，难的是，管理人员必须与有技能的人一起来完成观察趋势的工作，看看他们是否朝着期望的方向和是否以足够快的速度前进。趋势为随组织复杂性而来的绩效提供了领先指标。当趋势越来越远离理想状态时，关注数字的差距显然毫无意义。

关注趋势很重要，因为它会根据有关实施的任何更改的真实数据提供反馈，并为组织做出更多反应选择。例如，如果团队正在远离理想状态，他们可以问问自己是什么导致他们偏离目标，以及他们可以做些什么。它比简单地在计算出数字之前尽可能多地采取行动要早得多。如果一个团队发现自己趋向于理想状态，他们可以问问自己是什么在帮助他们朝着目标前进，还有什么可以做来加快这个速度。测量团队鼓励人们进行更多的实验，调整一件事并观察它对趋势的影响，

任意的绝对数字也会造成无助感，尤其是当实现目标的进展缓慢并且对其他部门或团队控制之外的公司政策的依赖阻碍了更多进展时。趋势有助于将人们的努力集中在朝着正确的方向前进，而不是在看似无法解决的差距之间陷入瘫痪。

更恰当地使用指标需要管理层更多地参与报告和记录趋势的变动，因为围绕团队建立生态系统是管理层的责任。这个生态系统包括组织的政策、工作安排或计划的方式以及团队和人员的组织方式。这种生态系统通常对个人付出的努力对趋势的影响要大得多。管理层应该对趋势感兴趣，以观察变化对这个生态系统的影响。

适当使用指标会发现趋势比绝对数字更有用。如果没有正确的趋势，任意给出的目标就没有多大意义，当考虑影响趋势的因素以及可以采取哪些措施来影响趋势时，更好的问题会浮现，而不是随意的指出数字与现实之间的差距。

3.3 指标作为棘轮

Thoughtworks 经常被要求拯救每次更改需要太长时间的软件项目。被认为很小的改变通常需要一个月以上的时间才能真正完成。这些类型的项目具有一个非常共同的特征——代码质量被视为事后考虑项，并且已经产生了大量的技术债务。

典型救援项目的代码库充满了大量代码异味。在许多领域（如许多并行继承层次结构）中都弥漫着单一的代码味道的出现频率很高；其他情况，代码味道很大，例如一个过大的方法；最坏的情况，代码异味的出现频率和程度都很大。解决这些问题中的任何一个一开始似乎都是不可能的，因为解决一个问题的努力是压倒性的。始终如一地解决单一代码异味很困难，因为它需要立即停止交付增量业务价值。

扭转低质量的趋势是唯一的出路，通过棘轮机制使其成为可能，我的同事 Chris Stevenson 在他的博客文章“使用棘轮机制修复损坏的 Windows ”中提到了这个词。

棘轮机制涉及将代码分析工具添加到持续集成的构建中，当某个指标超过某个值时，CI就会失败。团队通常都以这种方式作为开始，将其添加到持续集成构建中，以免进一步朝着错误的方向发展。在交付其他功能和业务价值的同时，逐步解决所选代码异味的问题，一次一小步。在每次小的改进上，团队都会向下修改指标的当前值。

似乎是一个无法解决的问题，一次被拆成一小块。棘轮到位以防止向后移动，每一个小的改进都会将趋势推向正确的方向。

3.4 使用更短的跟踪周期

许多组织使用指标来设定很长一段时间的目标，通常是 3-6 个月，甚至长达一年或更长时间。管理人员制定了这个目标，负责工作的人有责任尽他们所能来实现这个目标。管理层在期末重新审视这一目标，以评估从事工作的人员。在这个系统中，管理层和员工之间的关系，说得好听点，可以描述为对抗性的。员工尽其所能实现目标，而这隐含的想法是管理层没有任何的责任。

长时间之后重新审视指标的结果是，未能达到管理层的目标变得越来越不可接受。我听过经理这样说，“你有整整一年的时间来实现你的目标，但你错过了它。” 跟踪期越长，失败的风险和成本就会增加。

敏捷方法更喜欢较短的审查时间，因为任何性能差距的成本都较低。一周内没有取得足够的进步远不如一整年没有取得足够的进步重要。每周回顾进展比一年后回顾进展产生更多的选择，仅仅是因为有更多的机会做出反应和改变。在短短的一段时间（例如一周）之后，你还会获得更多关于实际发生的事情而不是计划内容的数据，这应该用于通过使用它来推动变革来影响结果。

组织可以从使用较短的跟踪周期中受益，因为它为重新规划创造了更多机会，从而实现了最大价值。

我与一个团队合作，该团队每两周将软件发布到生产环境中。该企业喜欢定期发布，因为这样他们几乎可以立即使用该软件。在使用最新版本之后部署的软件时，该企业发现他们拥有足够的功能，几乎可以完成新营销计划所需的一切，而这只是他们最初需求的一小部分。

与开发团队编写可能永远不会使用的功能不同，业务选择了剩余故事的一小部分并开始着手下一个计划。

适当使用指标可以在较小的周期内跟踪进度，因为它提供了更多关于项目将来可能会在哪里结束的信息。跟踪较小的周期有助于识别趋势，暂停使组织能够更明智地识别影响环境和趋势的速率/方向。

跟踪更短的周期还可以实现更多的协作，因为它为管理层提供了更多参与的机会。不是简单地在较大周期结束时评估人们，而是跟踪较小周期提供有关影响趋势的实际情况的更多数据。

3.5 当指标停止推动变革时改变指标

如果组织能够轻松实现目标，他们就永远不需要指标。组织可以改变方向，可以立即达到目标。不幸的是，这在现实中不会发生，这就是措施存在的原因，实现目标通常需要更长的时间。正确使用指标的第一条准则将实际目标与为监控实现该目标的进度而选择的措施分开。真正的目标必须始终明确。

准则#2 和#3，监控趋势并在更短的时间内，这样做是为了帮助组织更快地实现他们的目标。它不是通过本章前面描述的单循环学习来实现的。组织需要的是 Argyris 所说的双循环学习。适当使用指标会促使人们质疑目标，并根据收集的真实数据实施变革以实现目标。

这是双循环学习的样子：

因每周修复错误而沮丧的开发人员Dan考虑为什么他要不断修复错误。在过去的三周里，马尔科姆报告了许多关于事情没有按他预期工作的问题。他退后一步思考到底发生了什么，不再关心他总是被问到的错误数量，而是更多地关心他为什么要开始处理这些错误。

当丹拿起一个故事时，他经常向马尔科姆提出很多关于它应该如何运作的问题。丹知道马尔科姆还有其它营销活动让他忙碌，也明白马尔科姆不能坐在他旁边回答他的问题。丹在交付某些东西方面承受着巨大的压力，因此他做出了几个假设以确保他可以交付一些东西而不是什么都没有。

看着错误，Dan 意识到报告的许多错误都是基于他不断做出的那些小假设。交付某些东西的压力意味着 Dan 从来没有第一次就做出正确的东西。

当丹向马尔科姆解释这一点时，他们同意在每个新故事的开头坐下来，以确保丹的所有问题在他开始编码之前都得到解答。他们在第二周尝试这个，并且报告的错误总数减少了。

双循环学习需要更多关于实际情况的数据。较短的周期会产生更多的数据点，从而更容易看到任何趋势。这些趋势提供了对系统当前性能的洞察力，应该用于引发对系统中更深层次潜在力量的思考和问题解决，而不仅仅是跟踪性能测量。实施真正的变革有助于加速组织实现其当前目标。

改变人们工作的系统通常比关注个人更努力或更快工作的影响要大得多。在我们的故事中，丹本可以每周花更多时间来尝试修复错误，但是通过调整信息流以及马尔科姆和丹之间的工作关系，他们使系统变得更加有效。

项目的事后分析会在项目完成后进行回顾，从中汲取经验教训，希望将其应用于未来的项目或在整个组织中传播。在项目结束时进行事后分析没有机会将这些学习实际应用于项目本身。敏捷回顾的意图有所不同，他们在项目进行中寻求改变，在这种情况下，行动比最终产生的影响更大。这些会议为团队寻找变革机会创造了机会，尽管仍然依赖人员和组织来承诺这些变革。

当组织达到其目标时，就该返回用于实现目标的指标了。请记住，如果组织可以立即实现他们的目标，则永远不需要度量指标。定义、跟踪、监控和解释指标需要时间和资源，而这些时间和资源本可以更好地用于实现新的目标。适当的使用指标，组织需要随时放弃不再相关的指标，而不是保留他们习惯收集的所有指标。

你可以通过询问人们“为什么我们需要收集这个数字？”来寻找可能过时的指标的一些症状。一个糟糕的回应可能包括：“我们一直都是这样做的”，或者更糟的是，“这是我们的政策。” 这个问题不一定能区分解释不清的目标或过时的指标，因此可能需要多挖掘一些。管理层有责任确保组织的时间不会浪费在收集和维护不必要的指标上。

结论

指标在组织和团队中具有目的和地位，它们不能用作思考的替代品。组织也不能认为按数字管理就足以有效地交付软件。组织必须警惕因指标使用不当而出现的不良行为。双循环学习帮助我们理解，在组织学会更合适地使用指标之前，不可能存在关注个人行为的不同。

通过适当使用指标，组织可以将每个指标与每个人都理解的明确目标联系起来。选择用于监控进度的措施必须与目标脱钩，并随着时间的推移挑战每个指标的相关性。使用指标的组织更恰当地理解观察趋势的价值，在更短的时间内进行监控以了解个人、管理和组织的影响。更好的使用还意味着经常检查和调整这些影响，以确保在不断评估适合度的最终目标的背景下趋势加速、减速和逆转。

【相关文章】

您可能会发现以下有关使用和误用指标的文章很有趣：

• Esther Derby 的 Gaming Incentives - 反思人们如何操纵情况以最大化他们的激励计划。

• Vanity Metrics vs. Actionable Metrics 作者 Eric Ries - 精益创业布道者，Eric Ries 描述了如何使指标更具可操作性以及为了衡量而衡量的危险。

• 速度是杀死敏捷性的 吉姆海史密斯 - 一篇高度相关的文章，描述了公司如何将速度误用为指标。

脚注

• 1：Chris Arygris 和 Donald A. Schön 在他们的著作《组织学习：行动视角理论》中描述了单循环和双循环学习的概念。 

• 2：如应用的用户故事中所述：用于敏捷软件开发。