一位测试经理,我们叫她玛丽,每周都会与开发主管丹举行一次会议。在最近的一次会议上,她问道:“我们的错误计数情况如何?” 丹回答说:“我们清除了三个一级优先级的错误,修复了四个二级优先级的错误,并清除了创纪录的十二个三级优先级的错误。这周还不错吧?”
玛丽看着开发主管,微微摇了摇头,回答说:“不幸的是,我们的客户报告了五个一级优先级的错误,六个二级优先级的错误和十五个三级优先级的错误。你下周需要更加努力了。” 丹感到非常沮丧,因为他没有达到目标,他离开了会议,想着要让他的团队再加班一个周末。
管理层喜欢他们的指标。他们的想法是这样的:“我们需要一个数字来衡量我们的工作进展。数字可以让人们集中注意力,并帮助我们衡量成功。” 虽然出发点是好的,但数字管理却会无意中导致问题行为,并最终损害更广泛的项目和组织目标。指标本身并不是坏事;只是经常被不恰当地使用。本文阐述了管理层传统使用指标所造成的许多问题,并提供了一种解决这些问题的替代方案。
2013年2月19日
告诉我你如何衡量我,我就会告诉你我的行为方式。
从数字管理的角度来看待指标的组织遵循如下流程
管理层提出一个目标,并制定一个衡量标准
管理层为执行工作的人员设定一个长期目标(3-6个月到一年)
管理层只传达目标(根据商定的指标)
执行工作的人员尽一切努力达到目标数字
这个过程鼓励用以下目的来过度使用指标
指标作为目标 – 数字指标让人们特别容易将其作为传达目标的唯一手段。告诉人们一个尺度和一个数字,往往比解释一个更复杂的目标要容易得多。目标往往是一个任意的数字,有些组织甚至会花费过多的时间来确定这个数字应该是多少。
指标作为绩效衡量标准 – 有了一个既定的数字,而不是一个明确的目标,管理者现在就可以很容易地使用这个指标来跟踪执行工作的人员朝着目标前进的速度。许多组织将这些数字与个人绩效目标联系起来。
指标作为最佳实践 – 将指标既作为目标,又作为绩效衡量标准,会导致一个意想不到的副作用 – 这意味着该指标是实现目标的最佳方法。当一个独立的第三方使用一个数字目标来衡量另一个人时,就会给执行工作的人带来更大的压力,让他们只是为了达到一个既定的数字。由于他们只是根据这个指标来衡量绩效,所以他们会尽其所能地实现这个特定的指标。这意味着没有其他方法是实现最终目标的最佳方法。
用多个目的来过度使用一个指标会导致许多问题,尤其是在处理软件等知识工作时。指标是对更复杂属性的简化。简化复杂性的代价是忽略了真正的最终目标,最终导致结果不理想。
让我们来看一个例子
一位测试经理,我们叫她玛丽,每周都会与开发主管丹举行一次会议。在最近的一次会议上,她问道:“我们的错误计数情况如何?” 丹回答说:“我们清除了三个一级优先级的错误,修复了四个二级优先级的错误,并清除了创纪录的十二个三级优先级的错误。这周还不错吧?”
玛丽看着开发主管,微微摇了摇头,回答说:“不幸的是,我们的客户报告了五个一级优先级的错误,六个二级优先级的错误和十五个三级优先级的错误。你下周需要更加努力了。” 丹感到非常沮丧,因为他没有达到目标,他离开了会议,想着要让他的团队再加班一个周末。
在这个非常简单的故事中,所选择的指标满足了让会议快速进行的一个好处。在丹报告了他的结果以及玛丽做出回应后,两个人都很快了解了进展情况。不幸的是,交付有用软件的隐含目标被忽略了,丹离开会议时想到的解决方案更有可能导致更多软件问题,并拖累软件质量。
玛丽陈述目标的方式给丹带来了减少错误数量的压力。这似乎是一个令人钦佩的目标。虽然减少错误数量是一个很好的目标,但它也导致了一个非常被动的解决方案。丹离开会议时,想到的是要更加努力地工作。玛丽提出的问题没有忽视更广泛的目标,她也没有问出关键问题,即引导丹和他的团队去解决错误存在的根本原因。如果不解决这个根本原因,丹和他的团队就注定要一辈子都在修复错误。
丹正在经历单环学习[1]。单环学习是指重复尝试解决同一个问题,方法没有变化,也从不质疑目标。如果丹希望打破这种恶性循环,他就需要做一些不同的事情。不恰当的软件使用方式导致丹偏离了交付有用软件和提高整体软件质量的最终目标。爱因斯坦对疯狂的定义似乎很适合这里:“一遍又一遍地做着同样的事情,却期待着不同的结果。”
组织喜欢指标,因为它使设定目标更容易,并阻止人们质疑目标背后的目标。这导致管理者对组织效率产生了一种错觉。与强指标挂钩的强激励机制迫使人们只专注于工作的一部分,而忽略了其他可能使目标更容易成功的因素。组织必须警惕这种积极的破坏性关注,因为它会导致人们忽视其他重要因素。
即使是敏捷技术也不能保护团队免受因衡量和跟踪错误数字而产生的不良行为的影响。例如,敏捷团队经常使用故事卡[2] 来进行开发工作。团队经常在板上将这些小的工作增量可视化,因为它在组织的软件生命周期中移动。一个典型的过程可能如下所示,理想的故事流从左到右移动
图1:故事墙示例
管理层和产品管理层经常会问这样一个问题:“那个功能什么时候才能完成?” 团队通常将此解释为编码完成的时间,屈服于这样一种想法,即测试和生产路径是软件过程中微不足道且无关紧要的部分。项目管理层通过询问“我们本周完成了多少个故事的编码?”来强化这种看法,而不是问“我们有多少个故事可以发布给最终用户?”或者更好的是,“我们向最终用户发布了多少个故事?” 一个更好的问题是,“我们的用户从我们最近的版本中获得了多少价值?”
团队希望做正确的事情,而这些问题和指标最终会促使开发人员专注于完成故事的*开发*。让我们来看看过度关注这个次优目标本身的后果
马尔科姆是一位市场代表,他总是对开发人员为他构建的东西很感兴趣,他经常会去团队那里看看。他经常和开发人员丹聊天,询问他的功能什么时候能完成。丹不想让马尔科姆失望,所以他努力专注于完成马尔科姆要求的任何事情,因为他知道马尔科姆很快就会回来询问进展情况。他经常会想:“这个功能一定非常重要。” 团队中最新的测试员蒂姆经常需要找像丹这样的开发人员,以了解如何触发新开发的功能。
有一天,蒂姆找到丹说:“嗨,丹!我真的需要你的帮助,以了解如何测试你上周完成的功能。” 丹在交付压力下说:“你自己就不能做点什么吗?我需要完成这个功能,这样马尔科姆就不会再来烦我了。” 蒂姆对丹的回答感到震惊,他回到自己的办公桌前,等待着。他心想:“除非丹帮我,否则我什么也做不了。”
这种情况每周都在发生,随着时间的推移,等待测试的故事堆积得越来越多。最终,马尔科姆召集团队开会,因为他担心自己还没有看到两个月前在生产中要求的功能。丹感到很惊讶,他说他一个月前就完成了。蒂姆不好意思地回答说:“我无法测试那个故事,因为我需要丹的帮助,而他一直忙于其他工作。我不想打扰他。”
我们能从这个故事中学到什么?首先,对马尔科姆来说,重要的是工作流程要完成。即使马尔科姆询问什么时候能完成,但他真正想要的是能够在生产中使用它。我们知道蒂姆没有完成工作所需的知识,而丹完成更多工作的压力阻止了蒂姆获得更多知识。最终结果是一个恶性循环,工作堆积在测试中,永远无法发布,而马尔科姆则困惑为什么他没有收到他要求的功能。这就是为什么像看板软件开发这样的方法鼓励*明确的在制品*限制。这些限制迫使人们在出现瓶颈时互相帮助。这些在制品限制有助于克服当人们根据个人生产力而不是交付的整体价值这一错误指标进行衡量时出现的不可取行为。《精益软件开发》(Lean Software Development) 一书强调了衡量端到端结果的重要性,而不仅仅是流程的一小部分,并提出了一个他们称之为“优化整体”的原则。优化整体意味着确保使用的指标不会导致针对交付有用软件这一真正目标的次优行为。
鉴于由于不恰当地使用指标而出现的不可取行为,这是否意味着指标没有立足之地?当然,指标有其存在的意义。我们需要的是一种不同的方法。使用以下准则可以引导你更恰当地使用指标
将指标与目标明确关联
优先跟踪趋势而非绝对数字
使用更短的跟踪周期
当指标不再推动改变时,就改变指标
我们将在以下章节中探讨这些内容的含义。
在传统的方式中,管理层决定什么是衡量特定目标的最佳指标。然后,管理层根据该指标设定一个目标。然后,管理层只向执行工作的人员阐述这个目标,通常是用数字表示。为监控目标进展而选择的指标与实际目标本身之间的界限变得模糊。随着时间的推移,指标背后的原因消失了,人们专注于实现目标,即使该指标不再相关。更恰当地使用指标的方法是确保将所选的衡量进展的指标(即指标)与它的目的(即目标)区分开来,但又要与之相关。
例如,在软件开发环境中,你可能会看到如下定义的指标
方法必须少于15行。一个方法的参数不能超过4个。方法的循环复杂度不能超过20。
如果指标使用得当,那么每个度量标准都应该与其最初的目的明确关联。必须将当前的跟踪和监控机制与其目标分离,并明确说明该目标,以帮助人们更好地理解指标的意图。如果指标的存在有更丰富的上下文,则可以指导人们做出更适当、更务实、最终更有用的决策来实现目标。如果没有目的,付出的努力就意味着人们会想方设法地玩弄他们的系统,最终偏离真正的目标。以下是它的样子
我们希望我们的代码不那么复杂,更容易更改。因此,我们应该致力于编写短方法(少于 15 行),并降低圈复杂度(小于 20 就很好)。我们还应该致力于拥有少量的参数(最多四个),以便方法尽可能保持专注。
将指标与目标明确关联,使人们能够更好地质疑其相关性,找到其他方法来满足需求,并帮助人们理解数字背后的意图。如果没有这种明确的目的,人们可能会在无意中找到不利于隐含目标的方法。例如,许多技术可能有助于减少方法长度,但如果应用不当,则会因难以阅读而增加整体复杂性。
软件开发的本质意味着大多数工作都是知识工作,因此难以观察。监控活动(他们在电脑前坐了多长时间)很容易,但要观察他们产生的价值(满足实际需求的有用软件)却很难。人们离代码越远,就越难理解其中涉及的复杂性。这意味着,对于离工作最远的人来说,要真正了解监控目标进展的最佳衡量标准是非常困难的,甚至是不可能的。
转向更恰当地使用指标意味着管理层不能孤立地提出衡量标准。他们不能再欺骗自己,认为自己知道监控进度的最佳方法,并且停止强制执行可能与目标无关的衡量标准。相反,管理层有责任确保始终关注最终目标,与对系统最了解的人员一起制定最有意义的进度监控指标。
管理层发现指标太难抗拒了,因为它将组织的复杂性简化为每个人都能理解的东西,即数字。很容易看出一个数字比另一个数字大或小,或者一个数字与另一个数字的距离有多远。要想知道这个数字是否仍然相关就困难得多。这种传统的管理方法喜欢使用这些指标,因为它可以很容易地传达目标何时实现。“只要达到这个数字,我们就没事了”。
当你把一个定性的、高度解释性的问题(想想生产力、质量和可用性)变成一个数字时,任何数字都是相对的和武断的。5% 和 95% 的代码覆盖率之间可能存在显著差异,但 94% 和 95% 之间真的有显著差异吗?选择 95% 作为目标可以帮助人们了解何时停止,但如果需要付出巨大的努力才能获得最后 1%,那么这样做真的值得吗?这只是人们必须在自己的组织环境中主观地解决的问题。
观察趋势比观察目标是否实现提供了更多有趣的信息。判断目标是否实现很容易。困难的工作是观察趋势,看看它们是否朝着期望的方向发展,以及速度是否足够快,而这项工作必须由管理层与具备完成这项工作技能的人员一起完成。趋势提供了组织复杂性所产生的绩效的领先指标。当趋势越来越偏离期望状态时,关注数字上的差距显然毫无意义。
关注趋势很重要,因为它可以根据对任何已实施变更的真实数据提供反馈,并为组织创造更多做出反应的选择。例如,如果团队正在偏离期望状态,他们可以问问自己是什么原因导致他们偏离目标,以及他们可以做些什么。它比简单地在计算出一个数字之前尽其所能要早得多地采取行动。如果一个团队发现自己正在朝着期望的状态发展,他们可以问问自己是什么帮助他们朝着目标前进,以及还可以做些什么来加快这一速度。衡量团队可以鼓励人们进行更多实验。调整一件事,观察它对趋势的影响,监控你与期望状态的距离,并知道何时停止。
武断的绝对数字也会造成无助感,尤其是当目标进展缓慢,并且依赖于其他部门或团队无法控制的公司政策阻碍了进一步进展时。趋势有助于人们集中精力朝着正确的方向前进,而不是在看似无法解决的差距之间停滞不前。
更恰当地使用指标需要管理层更多地参与报告和记录趋势变化,因为团队周围的生态系统是管理层的责任。这个生态系统包括组织的政策、工作安排或计划的方式,以及团队和人员的组织方式。这种生态系统对趋势的影响往往比个人付出的努力要大得多。管理层应该对趋势感兴趣,以观察对这种生态系统进行更改的效果。
恰当地使用指标会发现趋势比绝对数字更有用。如果没有正确的趋势,武断的目标就没有多大意义,当思考是什么影响了趋势以及还可以做些什么来影响趋势时,就会出现更好的问题,而不是指出武断的数字与现实之间的差距是什么。
许多组织使用指标来设定很长一段时间的目标,通常是 3-6 个月,甚至长达一年或更长时间。管理者设定这个目标,由从事这项工作的人员负责尽其所能地实现这个目标。管理层在期末重新审视这个目标,以*评估*从事这项工作的人员。在这种制度下,管理层与员工之间的关系往好了说是对抗性的。员工尽其所能,尽其所能地实现目标,并隐含地认为管理层没有任何责任。
在很长一段时间后重新审视指标的结果是,未能实现管理层设定的武断目标变得越来越不可接受。我听到管理者说过这样的话:“你们有一整年的时间来实现目标,但你们错过了。”失败的风险和成本随着跟踪时间的延长而增加。
敏捷方法更喜欢较短的评审周期,因为任何绩效差距的成本都较低。一周内没有取得足够的进展,远没有一整年都没有取得足够的进展那么严重。每周审查一次进度比一年审查一次进度会产生更多选择,原因很简单,因为有更多机会做出反应和改变。在短短一周之后,你还可以获得更多关于实际发生了什么的数据,而不是计划了什么,这应该通过使用这些数据来推动变革,从而影响结果。
组织可以从使用较短的跟踪周期中获益,因为它创造了更多重新计划的机会,从而实现价值最大化。
我曾经与一个团队合作,他们每两周发布一次软件到生产环境中。企业喜欢定期发布,因为他们可以几乎立即使用软件。在使用最新版本部署的软件时,企业发现他们有足够的功能,可以完成新营销计划所需的一切。这只是他们最初要求的一小部分。
企业没有让开发团队编写可能永远不会使用的功能,而是从剩下的故事中挑选了一小部分,并开始着手下一个计划。
恰当地使用指标可以在较小的周期内跟踪进度,因为它可以提供更多关于项目在未来可能走向何方的信息。跟踪较短的周期有助于识别趋势,而暂停可以让组织在影响环境和趋势的速度/方向方面处于更有利的位置。
跟踪较短的周期也能促进更多协作,因为它为管理层参与其中提供了更多机会。跟踪较短的周期不是简单地在较长周期结束时*评估*人员,而是提供更多关于实际发生情况的数据,从而影响趋势。
如果组织能够轻松地实现目标,那么他们就永远不需要指标。组织可以改变方向,他们会立即实现目标。不幸的是,这在现实中不会发生,这就是指标存在的原因。实现一个目标通常需要更长的时间。恰当使用指标的第一条准则是将真正目标与为监控实现该目标的进度而选择的衡量标准分开。真正的目标必须始终明确说明。
准则 #2 和 #3,即监控趋势并在较短的时间内进行监控,是为了帮助组织更快地实现目标。这不是本章前面描述的单循环学习所能实现的。组织需要的是 Argyris 所说的双循环学习。恰当地使用指标会促使人们质疑目标,并根据收集到的真实数据实施变革以实现目标。
以下是双循环学习的样子
开发者丹对每周都要修复错误感到沮丧,他开始思考为什么自己总是在修复错误。在过去的三周里,马尔科姆报告了许多关于事情没有按预期进行的问题。他退后一步,思考到底发生了什么,不再关心他总是被问到的错误数量,而是更多地关注为什么他会遇到这些错误。
当丹拿起一个故事时,他经常会问马尔科姆很多关于它应该如何运作的问题。丹知道马尔科姆还有其他的营销活动要忙,他明白马尔科姆不能和他坐在一起回答他的问题。丹承受着巨大的压力,要交付一些东西,所以他做了一些假设,以确保他能交付一些东西,而不是什么都没有。
看看这些错误,丹意识到,报告的许多错误都是基于他不断做出的那些小假设。交付东西的压力意味着丹从来没有第一次就把事情做好。
当 Dan 向 Malcolm 解释这一点时,他们同意在每个新故事开始时坐下来,确保在 Dan 开始编码之前回答他所有的问题。他们在接下来的一周尝试了这种方法,结果该周报告的错误总数减少了。
双环学习需要更多关于实际情况的数据。较短的周期会创建更多数据点,从而更容易看到任何趋势。这些趋势可以洞察系统的当前性能,应用于触发对系统中起作用的更深层次潜在力量的思考和问题解决,而不仅仅是用于跟踪性能测量。实施真正的变革有助于加速组织实现其当前目标。
改变人们的工作系统通常比专注于个人更加努力或更快地工作产生更大的影响。在我们的故事中,Dan 可以每周花费更多时间来修复错误,但通过调整信息流以及 Malcolm 和 Dan 之间的工作关系,他们改变了系统,使其更加有效。
项目事后分析会在项目完成后回顾,寻求经验教训,希望能将这些经验应用于未来的项目或在整个组织中传播。在项目结束时进行事后分析,根本没有机会将这些经验应用于项目本身。《敏捷回顾》的意图有所不同,它寻求在项目进行中进行变更,因为在项目进行中采取行动比在项目结束时更有效。这些会议为团队创造了寻找变革机会的机会,但仍然依赖于人员和组织对这些变革的承诺。
当一个组织实现其目标时,就该退还用于实现目标的指标了。请记住,如果组织立即实现其目标,则永远不需要指标。定义、跟踪、监控和解释指标需要时间和资源,而这些时间和资源可以更好地用于实现新目标。组织需要放弃不再相关的指标,而不是坚持他们习惯收集的所有指标。通过适当使用指标,了解要放弃哪些指标将很容易,因为这些指标已明确链接到目标,并且在一段时间内持续监控趋势鼓励持续审查最终目标的状态。
您可以通过询问人们“为什么我们需要收集这个数字?”来寻找一些可能过时的指标的症状。一个糟糕的回答可能包括“我们一直都是这样做的”,或者更糟糕的是“这是我们的政策”。这个问题不一定能区分解释不清的目标或过时的指标,因此可能需要进行更多挖掘。管理层的责任是确保组织的时间不会浪费在不必要地收集和维护不必要的指标上。
指标在组织和团队中具有目的和地位。它们不能代替思考。组织也不能认为数字管理足以实现有效的软件交付。组织必须警惕因不当使用指标而出现的不良行为。双环学习帮助我们理解,在组织学会更恰当地使用指标之前,专注于个人行为的改变是不存在的。
通过适当使用指标,组织可以将每项衡量指标与其明确的目标联系起来,让每个人都能理解。选择用于监控进度的衡量指标必须与目标脱钩,并且随着时间的推移,欢迎质疑每项指标的相关性。更恰当地使用指标的组织了解观察趋势的价值,在较短的时间段内进行监控,以便了解个人、管理层和组织的影响。更好地使用还意味着经常检查和调整这些影响,以确保趋势在不断评估其适用性的最终目标的背景下加速、减速和逆转。最恰当地使用指标还意味着了解何时衡量指标不再相关,以及随着目标的实现和周围环境的变化而替换或放弃它们。
您可能会发现以下关于指标的使用和误用的文章很有趣
2013 年 2 月 19 日:首次发布