管理层往往热衷于各种指标。他们的想法大致是“我们需要一个数字来衡量工作表现。数字能让大家聚焦也能帮助我们判断是否成功。”这种初衷并没有错但以数字为核心的管理方式往往会诱发一些问题行为最终损害项目和组织的整体目标。在软件交付和敏捷管理中指标管理尤其需要谨慎。指标本身并不是坏事问题在于它们常常被不恰当地使用。本文将讨论传统管理方式使用指标时容易引发的问题并提出一种更合理的替代方法将指标与目标明确关联重视趋势而非绝对数字缩短跟踪周期并在指标不再驱动改进时及时调整。指标管理出了什么问题在很多组织中指标驱动管理通常遵循这样的流程管理层设定目标并确定衡量指标管理层为实际执行工作的人员设定一个较长周期内的目标例如 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 这类通用项目协作系统可以帮助管理层和团队在短周期内更好地共享信息、记录变化和推动复盘改进。跟踪较短周期的数据也有助于加强协作因为它为管理层提供了更多参与机会。与其只在较长周期结束时评价员工不如通过更短周期的数据获得更多关于哪些因素正在实际影响趋势的信息。当指标不再驱动改变时就应该改变指标如果组织能够轻易达成目标就根本不需要指标。组织可以随时调整方向并立即实现目标。然而现实并非如此这正是指标存在的原因。达成目标往往需要较长时间。合理使用指标的首要原则是将真正目标与用于监控目标进展的指标区分开来。真正目标必须始终被清楚表达。前面提到的第二和第三条原则也就是监控趋势和缩短监控周期都是为了帮助组织更快实现目标。这并不能通过前文描述的单环学习实现。组织真正需要的是双环学习。合理使用指标能够促使人们质疑目标并基于收集到的真实数据实施变革从而更好地实现目标。下面用一个故事说明双环学习。开发人员每周都要修复缺陷这让他很沮丧。他开始思考为什么自己总是在修复缺陷。过去三周市场代表报告了很多问题说一些功能没有按预期运行。开发人员停下来反思不再只关注别人总是问他缺陷数量而是开始关注为什么会出现这些缺陷。开发人员接到一个用户故事后常常需要问市场代表很多关于如何推进这个故事的问题。他知道市场代表还有其他市场工作要忙也知道对方没有时间坐下来一一回答他的问题。开发人员承受着巨大压力必须交付成果于是他做了一些假设以确保最后至少有东西可以交付而不是一无所获。查看这些缺陷后开发人员意识到许多被报告的问题都源于他不断做出的那些小假设。交付压力意味着他永远无法一次把事情做对。当开发人员向市场代表解释清楚后他们同意在每个新故事开始前先坐下来确保开发人员的所有问题都得到回答然后再开始写代码。他们在下一周尝试这种做法结果当周报告的缺陷总数下降了。双环学习需要更多关于实际运行情况的数据。较短周期会产生更多数据点从而更容易发现趋势。这些趋势能够揭示系统当前的表现并用于思考和解决问题不仅仅是跟踪绩效数字而是探究系统中更深层次的驱动因素。真正的变革能帮助组织更快实现当前目标。改变人们所处的工作系统往往比要求个人更努力或更快地工作更有意义。在这个故事中开发人员原本可以每周花更多时间修复缺陷但通过调整信息流以及他和市场代表之间的协作方式他们改变了系统使整个流程变得更加有效。项目复盘通常在项目结束后进行目的是总结经验教训以便应用到未来项目或在整个组织内推广。然而在项目结束时复盘实际上已经没有机会把这些经验教训应用到当前项目本身。敏捷回顾则不同它旨在项目进行过程中寻找改进机会。此时采取行动往往比项目结束后才总结更有影响力。这些会议为团队提供了发现改进机会的平台但真正落实改进仍然需要个人和组织的共同承诺。当组织已经达成目标后就应该停止使用那些为实现该目标而设定的指标。请记住如果组织能够瞬间达成目标指标就失去了存在的必要。定义、跟踪、监控和解读指标都需要时间和资源而这些时间和资源本可以更好地用于实现新的目标。组织需要舍弃不再相关的指标而不是固守所有曾经收集过的数据。如果能够合理使用指标那么判断哪些指标应该被弃用会变得容易得多。因为这些指标都与目标明确关联而对指标趋势的持续监控也会促使组织不断审视最终目标的实现情况。你可以通过询问员工“我们为什么要收集这个数字”来发现可能已经过时的指标。糟糕的回答可能是“我们一直都是这么做的”或者更糟糕的是“这是公司的政策”。当然这个问题未必能区分“目标解释不清”和“指标已经过时”因此可能还需要更深入的调查。管理层的责任是确保组织不会把时间浪费在不必要地收集和维护无用指标上。结论指标不能替代思考指标在组织和团队中确实有其存在意义和价值。但指标不能替代思考。组织也不能以为仅仅依靠数字管理就能实现高效的软件交付。组织必须警惕因指标使用不当而产生的不良行为。双环学习帮助我们理解如果组织想更合理地使用指标仅仅关注如何改变个人行为是不够的。通过合理使用指标组织可以将每一项衡量指标与一个清晰明确、人人都能理解的目标关联起来。用于监控进展的指标必须与目标本身区分开来并且随着时间推移对每项指标的相关性提出质疑应该被鼓励。更合理使用指标的组织会理解观察趋势的价值并通过更短周期的监控了解个人、管理层和组织层面的影响因素。更有效地使用指标也意味着要经常检查并调整这些影响因素确保趋势的加速、减速和逆转都与最终目标相关同时持续评估最终目标是否仍然适用。最恰当地使用指标还意味着知道什么时候指标已经不再适用并根据目标进展和环境变化替换或放弃某些指标。如果用一句话总结好的指标管理不是用数字替代判断而是用数字帮助团队看清目标、理解趋势并持续改进软件交付系统。