管理层往往热衷于各种指标。他们的想法大致是：“我们需要一个数字来衡量工作表现。数字能让大家聚焦，也能帮助我们判断是否成功。”这种初衷并没有错，但以数字为核心的管理方式，往往会诱发一些问题行为，最终损害项目和组织的整体目标。
在软件交付和敏捷管理中，指标管理尤其需要谨慎。指标本身并不是坏事，问题在于它们常常被不恰当地使用。本文将讨论传统管理方式使用指标时容易引发的问题，并提出一种更合理的替代方法：将指标与目标明确关联，重视趋势而非绝对数字，缩短跟踪周期，并在指标不再驱动改进时及时调整。
指标管理出了什么问题？
在很多组织中，指标驱动管理通常遵循这样的流程：
- 管理层设定目标，并确定衡量指标；
- 管理层为实际执行工作的人员设定一个较长周期内的目标，例如 3 到 6 个月，甚至一年；
- 管理层只传达目标，而目标通常用双方约定的指标来表达；
- 实际执行工作的人尽全力达成这个数字。
这个过程会让单一指标被赋予多重用途。
将指标当作目标。 数字指标很容易被当成传达目标的唯一方式。相比解释一个复杂目标，告诉人们一个度量方式和一个数字，通常要简单得多。而这个目标值往往是任意设定的。有些组织甚至会花费大量时间争论这个数字到底应该是多少。
将指标当作绩效衡量方式。 一旦目标被简化成数字，管理者就不再需要清晰描述目标本身，而是直接用既定数字来衡量绩效。这样一来，追踪人们达成目标的速度就变得更容易。许多组织还会把这些数字与个人绩效目标绑定。
将指标误认为最佳实践。 当同一个指标既被用作目标，又被用来衡量绩效时，还会产生一个意外副作用：人们会误以为这个指标就是实现目标的最佳方式。当第三方用数字目标衡量执行者时，执行者会承受更大的压力，只能围绕这个数字努力。由于绩效只取决于该指标，他们自然会竭尽全力优化这个指标。这等于暗示：没有其他方法比达成这个数字更能实现最终目标。
当单一指标承担过多职责时，就会引发很多问题。尤其是在软件开发这类知识密集型工作中，指标往往只是对复杂属性的简化。简化复杂性的代价，是我们可能忽略真正的最终目标，进而导致次优结果。
来看一个例子。
测试经理每周都会和开发负责人开会。在最近一次会议上，她问：“我们的缺陷数量怎么样？”
开发负责人回答：“我们修复了 3 个一级缺陷、4 个二级缺陷，还破纪录地修复了 12 个三级缺陷。这周成绩不错，对吧？”
测试经理看着他，微微摇了摇头，说：“可惜的是，客户又报告了 5 个一级缺陷、6 个二级缺陷和 15 个三级缺陷。下周你们得加把劲了。”
开发负责人因为没有完成目标而感到沮丧，也感到压力巨大。他离开会议室时，开始琢磨是不是该让团队周末再加班。
在这个非常简单的例子中，所选指标确实有一个好处：它让会议进展得很快。开发负责人汇报结果，测试经理迅速回应，双方都能立刻理解当前进展。然而，那个隐含的真正目标——交付有用的软件——却没有实现。开发负责人离开时想到的解决方案，很可能只会引发更多软件问题，并进一步降低软件质量。
测试经理表达目标的方式，给开发负责人施加了减少缺陷数量的压力。表面上看，这似乎是一个值得追求的目标。减少缺陷当然是好事，但它也可能导致一种被动应对模式。开发负责人离开会议时，只觉得未来要更加努力。测试经理的问题忽略了更广泛的目标，也没有问出真正关键的问题：是什么原因导致这些缺陷持续出现？这个问题本应引导开发负责人和他的团队去解决缺陷产生的根本原因。如果不解决根因，他们注定会一直与缺陷作斗争。
这个开发负责人正陷入“单环学习”。所谓单环学习，是指人们不断尝试用同一种方式解决同一个问题，却从不质疑目标本身，也不反思方法是否应该改变。如果他想摆脱这种恶性循环，就必须改变方法。不恰当地使用指标，让他偏离了交付有用软件、提升整体软件质量这一真正目标。那句常被引用的话在这里很贴切：一遍又一遍地做同样的事情，却期待不同的结果。
软件交付中的指标衡量要谨慎
组织喜欢指标，因为指标能简化目标设定，也能减少人们对目标背后真正含义的追问。这会让管理者产生一种组织运行高效的错觉。
一旦强指标与强激励绑定，人们就会被迫只关注工作的某一个局部，而忽略其他同样有助于达成目标的因素。组织必须警惕这种破坏性的关注点，因为它会导致人们忽视其他重要因素。
即使是敏捷方法，也无法让团队天然免受错误指标的影响。例如，敏捷团队通常使用故事卡记录开发工作。团队会把这些小粒度工作可视化，并记录它们在软件交付流程中的流动情况。一个典型的流程可能如下所示，理想的故事流是从左到右：
图 1：故事墙示例
管理层和产品经理经常会问：“这个功能什么时候能完成？”团队通常会把这个问题理解为“编码什么时候完成”。于是，组织很容易陷入一种误区：仿佛测试和上线只是软件开发流程中不太重要的后续环节。
项目管理也可能强化这种观念。人们会问：“我们这周完成了多少个用户故事的编码？”而不是问更好的问题：“我们有多少个用户故事已经可以发布给最终用户？”或者更进一步：“我们实际发布了多少个用户故事？”更恰当的问题则是：“用户从我们最近的发布中获得了多少价值？”
团队通常都想做正确的事，因此这些问题和指标会驱使开发人员专注于完成用户故事的开发。让我们看看过度关注这个次优目标会带来什么后果。
一位市场代表非常关心开发团队正在为他构建的产品，所以他经常去团队那里了解情况。他常常和一位开发人员聊天，询问自己关心的功能什么时候完成。开发人员不想让市场代表失望，于是努力集中精力完成对方提出的每个要求，因为他知道对方很快又会来问进度。他常常想：“这个功能一定非常重要。”
团队新来的测试人员也经常需要向这位开发人员请教，才能知道如何触发新开发的功能。
一天，测试人员找到开发人员说：“我真的需要你帮忙，才能弄明白怎么测试你上周完成的那个功能。”
开发人员因为赶工压力很大，回答说：“你就不能自己先想想办法吗？我必须赶紧把这个功能做完，不然市场那边不会放过我的。”
测试人员被这个回答吓了一跳，只好回到自己的座位上等着。他心想：“开发人员不帮我，我什么都做不了。”
类似的事情每周都在发生。随着时间推移，等待测试的功能越来越多。最终，市场代表召集团队开会，因为他两个月前提出的功能至今仍未上线。
开发人员惊讶地说：“我一个月前就已经完成了。”
测试人员不好意思地回答：“我没能测试那个功能，因为我需要开发人员的帮助，但他一直忙于其他工作。我不想打扰他。”
我们能从这个故事中学到什么？
首先，对市场代表来说，真正重要的是工作能够顺利流经整个交付流程。虽然他问的是某个功能“什么时候完成”，但他真正想要的是能在生产环境中使用这个功能。
其次，测试人员缺乏完成测试所需的知识，而开发人员面临的工作压力又让测试人员无法获取这些知识。结果就是测试工作不断堆积，功能迟迟无法发布，市场代表也因此困惑：为什么自己一直得不到想要的功能？
这也是为什么看板等软件开发方法会鼓励设置明确的在制品限制。在制品限制会迫使团队在出现瓶颈时互相帮助。它们有助于克服那些由错误衡量方式带来的不良行为，尤其是当人们被个人生产力而不是整体交付价值来衡量时。
精益软件开发强调，应该衡量端到端结果，而不是只衡量流程中的某个局部。这被称为“优化整体”。优化整体意味着，我们要确保所使用的指标不会诱导人们偏离真正目标——交付有用的软件。
合理使用指标的四个原则
既然不当使用指标会导致不良行为，这是否意味着指标完全没有用？当然不是。指标仍然有价值，但我们需要以不同方式使用它们。
可以遵循以下原则：
- 将指标与目标明确关联起来；
- 重视趋势，而不是绝对数字；
- 使用更短的跟踪周期；
- 当指标不再驱动改进时，就应该更换指标。
下面分别展开说明。
将指标与目标明确关联起来
传统做法是，管理层决定用哪个指标来衡量某个目标，然后根据这个指标设定目标值。之后，管理层通常直接以数字形式向员工传达目标。这样一来，用来监控目标进展的指标，与目标本身之间的界限就变得模糊。
随着时间推移，指标背后的真实意图会被遗忘，人们只关注如何达成数字目标，即使这个指标本身已经不再适用。
更合理的指标使用方式，是确保所选的进度衡量指标清晰明确，同时与它背后的目的，也就是真正目标，紧密关联。对于研发组织来说，PingCode 这类智能化研发管理工具可以帮助团队把目标、需求、评审排期、开发测试、发布上线和 Wiki 知识沉淀串联起来，让指标不只是孤立数字，而是嵌入完整研发流程的数据线索。
例如，在软件开发环境中，你可能会看到这样的指标定义：
方法行数必须少于 15 行。方法参数不得超过 4 个。方法的圈复杂度不得超过 20。
合理使用指标，意味着每一项指标都应与其最初目的紧密关联。当前用于跟踪和监控的机制，必须与目标本身区分开来；同时，目标必须被清楚表述，以帮助人们理解指标的意图。
一个存在于更丰富语境中的指标，能引导人们做出更恰当、更务实，也最终更有利于目标实现的决策。如果指标失去了目的，人们就会想方设法钻空子，最终偏离真正目标。
更好的表述应该是：
我们希望代码更简洁，更易于修改。因此，我们应该尽量编写较短的方法，例如少于 15 行，并降低圈复杂度，例如低于 20。此外，我们也应该尽量减少方法参数数量，例如最多 4 个，以保持方法简单易懂。
将指标与目标明确关联起来，能让人们更好地质疑指标是否仍然相关，寻找满足需求的其他方法，并理解数字背后的真正意图。如果缺少这种明确目标，人们可能会找到一些方式，在无意中违背隐含目标。例如，某些技巧也许能缩短方法长度，但如果使用不当，反而会增加整体复杂度，使方法更难理解。
软件开发的大部分工作都是知识型工作，因此很难直接观察。观察工作活动很容易，比如一个人在电脑前工作了多久；但观察他创造了多少价值，也就是是否交付了满足真实需求的有用软件，则困难得多。人们离代码越远，就越难理解其中的复杂性。这意味着，对于远离实际工作的人来说，要判断哪个指标最能衡量目标进展，即使不是不可能，也非常困难。
转向更合理的指标使用方式，意味着管理层不能再孤立地制定衡量标准。他们必须停止自欺欺人地认为自己已经掌握了监控进展的最佳方式，也必须停止强制执行那些与目标相关性可能并不高的指标。相反，管理层的责任是确保最终目标始终清晰，并与最了解系统的人合作，制定最合理的进度监控指标。
重视趋势指标，而不是绝对数字
管理层很难抗拒指标的诱惑，因为指标能把组织内部的复杂性简化成人人都能理解的数字。人们很容易判断一个数字比另一个数字大还是小，或者两个数字之间差距有多大。但要判断这个数字是否仍然有意义，却困难得多。
传统管理方式喜欢这些指标，因为它们便于传达“什么时候算达成目标”。例如：“只要达到这个数字，我们就没问题了。”
当你把一个定性且高度主观的问题，例如生产力、质量或可用性，转化为一个数字时，任何数字都是相对且任意的。5% 的代码覆盖率和 95% 的代码覆盖率之间，可能确实存在显著差异。但 94% 和 95% 的代码覆盖率之间，真的存在本质差异吗？选择 95% 作为目标，可以让人们知道什么时候该停止，但如果为了最后 1% 的覆盖率，需要付出数量级更高的努力，这真的值得吗？这只能由人们结合组织的具体情况进行判断。
观察趋势比判断目标是否达成更有意义。判断是否达到某个数字很容易，真正困难的是分析趋势，判断它是否正朝着期望方向发展，以及发展速度是否足够快。这项工作需要管理层与具备相应技能的人协作完成。
趋势能够提供组织复杂系统下绩效变化的先行信号。当趋势与期望状态渐行渐远时，仅仅关注数字差距并没有太大意义。
关注趋势之所以重要，是因为它能基于真实数据提供反馈，帮助组织应对已经实施的变更，并创造更多调整方案。例如，如果团队的进展偏离预期状态，他们可以反思是什么导致了偏离，以及可以采取哪些措施。相比等到最后才竭尽全力补救，这种方式更早、更有效。
如果团队发现自己正朝着期望状态前进，他们也可以思考：哪些因素正在帮助我们前进？还可以采取哪些措施来加快这个过程？
衡量团队表现，应该鼓励更多尝试。一次调整一个因素，观察它对趋势的影响，持续监控与期望状态之间的差距，并知道什么时候该停止。
武断的绝对数字也容易制造无助感，尤其是当目标进展缓慢，并且受限于团队无法控制的其他部门或公司政策时。趋势则能引导人们把精力集中在朝正确方向前进上，而不是被一个看似无法跨越的差距困住。
更合理地使用指标，需要管理层更多参与趋势报告和趋势记录，因为团队所处的生态系统是管理层的责任。这个生态系统包括组织政策、工作安排方式、计划方式，以及团队和人员的组织方式。这个生态系统对趋势的影响，往往远大于个人努力。
管理层应该关注趋势，观察生态系统变化对趋势产生的影响。
合理使用指标时，趋势远比绝对数字更有价值。如果没有正确的趋势，任意设定的目标数字意义不大。与其纠结某个任意数字与现实之间的差距，不如思考哪些因素正在影响趋势，以及还可以采取哪些措施来改变趋势。这才会带来更有价值的问题。
使用更短的指标跟踪周期
许多组织会用指标设定长期目标，周期通常是 3 到 6 个月，甚至一年或更久。管理者制定目标，而责任则落在执行任务的员工身上，要求他们尽一切努力达成目标。管理层会在周期结束时重新评估目标，并评价员工表现。
在这种体系下，管理层与员工之间的关系，充其量只能说是对抗性的。员工竭尽全力完成目标，而默认前提却是管理层无需为结果承担多少责任。
长时间后才重新审视指标，会带来一个后果：未能达到管理层设定的目标，会变得越来越难以接受。我曾听到一些经理说：“你们有一整年的时间来达成目标，结果还是没做到。”跟踪周期越长，失败的风险和代价就越高。
敏捷方法倾向于采用较短的评审周期，因为任何绩效差距的成本都更低。一周内没有取得足够进展，远比一年内没有取得足够进展影响更小。每周评审一次，比一年后才评审一次，能提供更多选择。原因很简单：组织有更多机会做出反应和改进。
在一周这样的短周期后，你还能获得更多关于实际情况，而不是计划情况的数据。这些数据应该被用来推动变化，从而影响最终结果。
缩短跟踪周期有利于组织，因为它能创造更多重新规划的机会，从而实现最大价值。
我曾与一个团队合作，他们每两周就会将软件发布到生产环境。业务部门很喜欢这种定期发布方式，因为他们几乎可以立即使用新软件。在使用最新版本后，业务部门发现现有功能已经足够强大，几乎可以满足一项新营销计划的全部需求。而这仅仅是他们最初需求的一小部分。
与其让开发团队继续编写可能永远不会被使用的功能，不如让业务部门挑选少量剩余功能，然后开始下一个项目。
合理使用指标来跟踪较短周期内的进展，能够提供更多关于项目未来方向的信息。较短周期有助于识别趋势，而这种停顿能让组织更有效地影响环境，以及趋势的速度和方向。对于需要频繁同步目标、任务、文档、日历、工时和审批的团队，Worktile 这类通用项目协作系统可以帮助管理层和团队在短周期内更好地共享信息、记录变化和推动复盘改进。
跟踪较短周期的数据，也有助于加强协作，因为它为管理层提供了更多参与机会。与其只在较长周期结束时评价员工，不如通过更短周期的数据，获得更多关于哪些因素正在实际影响趋势的信息。
当指标不再驱动改变时，就应该改变指标
如果组织能够轻易达成目标，就根本不需要指标。组织可以随时调整方向，并立即实现目标。然而现实并非如此，这正是指标存在的原因。达成目标往往需要较长时间。
合理使用指标的首要原则，是将真正目标与用于监控目标进展的指标区分开来。真正目标必须始终被清楚表达。
前面提到的第二和第三条原则，也就是监控趋势和缩短监控周期，都是为了帮助组织更快实现目标。这并不能通过前文描述的单环学习实现。组织真正需要的是双环学习。
合理使用指标，能够促使人们质疑目标，并基于收集到的真实数据实施变革，从而更好地实现目标。
下面用一个故事说明双环学习。
开发人员每周都要修复缺陷，这让他很沮丧。他开始思考，为什么自己总是在修复缺陷。过去三周，市场代表报告了很多问题，说一些功能没有按预期运行。开发人员停下来反思，不再只关注别人总是问他缺陷数量，而是开始关注为什么会出现这些缺陷。
开发人员接到一个用户故事后，常常需要问市场代表很多关于如何推进这个故事的问题。他知道市场代表还有其他市场工作要忙，也知道对方没有时间坐下来一一回答他的问题。开发人员承受着巨大压力，必须交付成果，于是他做了一些假设，以确保最后至少有东西可以交付，而不是一无所获。
查看这些缺陷后，开发人员意识到，许多被报告的问题都源于他不断做出的那些小假设。交付压力意味着他永远无法一次把事情做对。
当开发人员向市场代表解释清楚后，他们同意在每个新故事开始前先坐下来，确保开发人员的所有问题都得到回答，然后再开始写代码。他们在下一周尝试这种做法，结果当周报告的缺陷总数下降了。
双环学习需要更多关于实际运行情况的数据。较短周期会产生更多数据点，从而更容易发现趋势。这些趋势能够揭示系统当前的表现，并用于思考和解决问题：不仅仅是跟踪绩效数字，而是探究系统中更深层次的驱动因素。真正的变革，能帮助组织更快实现当前目标。
改变人们所处的工作系统，往往比要求个人更努力或更快地工作更有意义。在这个故事中，开发人员原本可以每周花更多时间修复缺陷；但通过调整信息流，以及他和市场代表之间的协作方式，他们改变了系统，使整个流程变得更加有效。
项目复盘通常在项目结束后进行，目的是总结经验教训，以便应用到未来项目或在整个组织内推广。然而，在项目结束时复盘，实际上已经没有机会把这些经验教训应用到当前项目本身。
敏捷回顾则不同，它旨在项目进行过程中寻找改进机会。此时采取行动，往往比项目结束后才总结更有影响力。这些会议为团队提供了发现改进机会的平台，但真正落实改进，仍然需要个人和组织的共同承诺。
当组织已经达成目标后，就应该停止使用那些为实现该目标而设定的指标。请记住，如果组织能够瞬间达成目标，指标就失去了存在的必要。定义、跟踪、监控和解读指标都需要时间和资源，而这些时间和资源本可以更好地用于实现新的目标。
组织需要舍弃不再相关的指标，而不是固守所有曾经收集过的数据。如果能够合理使用指标，那么判断哪些指标应该被弃用会变得容易得多。因为这些指标都与目标明确关联，而对指标趋势的持续监控，也会促使组织不断审视最终目标的实现情况。
你可以通过询问员工“我们为什么要收集这个数字？”来发现可能已经过时的指标。糟糕的回答可能是“我们一直都是这么做的”，或者更糟糕的是“这是公司的政策”。当然，这个问题未必能区分“目标解释不清”和“指标已经过时”，因此可能还需要更深入的调查。管理层的责任，是确保组织不会把时间浪费在不必要地收集和维护无用指标上。
结论：指标不能替代思考
指标在组织和团队中确实有其存在意义和价值。但指标不能替代思考。组织也不能以为，仅仅依靠数字管理，就能实现高效的软件交付。
组织必须警惕因指标使用不当而产生的不良行为。双环学习帮助我们理解，如果组织想更合理地使用指标，仅仅关注如何改变个人行为是不够的。
通过合理使用指标，组织可以将每一项衡量指标与一个清晰明确、人人都能理解的目标关联起来。用于监控进展的指标必须与目标本身区分开来，并且随着时间推移，对每项指标的相关性提出质疑应该被鼓励。
更合理使用指标的组织，会理解观察趋势的价值，并通过更短周期的监控，了解个人、管理层和组织层面的影响因素。更有效地使用指标，也意味着要经常检查并调整这些影响因素，确保趋势的加速、减速和逆转都与最终目标相关，同时持续评估最终目标是否仍然适用。
最恰当地使用指标，还意味着知道什么时候指标已经不再适用，并根据目标进展和环境变化，替换或放弃某些指标。
如果用一句话总结：好的指标管理不是用数字替代判断，而是用数字帮助团队看清目标、理解趋势，并持续改进软件交付系统。
文章包含AI辅助创作，作者：liu，如若转载，请注明出处：https://docs.pingcode.com/baike/5242624
