10.8

View in English

10.8 成熟度模型

Overview and motivation

成熟度模型是一种结构化的方式,用于评估你在某个领域的实践能力和一致性有多强,并描述改进它的一条路径。它定义了一个由若干级别组成的小小阶梯。在最底层,工作是随意且被动的。在最顶层,工作被度量、被管理,并持续优化。每一个梯级都有你可以对照检查的可观察特征。

成熟度模型把一个模糊的问题(“我们在这方面做得好吗?“)变成一个可重复的答案(“我们在这个领域处于第 2 级,在那个领域处于第 4 级,而达到第 3 级需要满足这些条件”)。本书在每一章都使用一套五级模型,并在第 12.4 章将其汇总。本章讨论的是这门学问本身:这些模型如何运作、何时有帮助,以及它们如何会产生误导。

它们之所以重要,原因很简单。大型组织无法改进自己看不见的东西。在几十个团队之间,能力水平的差异巨大,却又不可见。有些团队测试做得很好、安全却很薄弱;另一些则恰恰相反。成熟度模型为你提供了一套共同的词汇和一把统一的标尺,使差距变得可比较、投资可以被排定优先级,进展也能够被随时间追踪,而不仅仅是被口头断言。知名的例子包括 CMMI(能力成熟度模型集成,用于流程)、DORA(DevOps 研究与评估)模型(软件交付绩效)、面向软件安全的 OWASP SAMM(软件保障成熟度模型)和 BSIMM(内建安全成熟度模型)、TMMi(测试成熟度模型集成,用于测试)、敏捷流畅度模型,以及各种数据管理成熟度模型,还有数不清的内部记分卡。

对企业、尤其是政府而言,成熟度模型具有特殊的分量。政府合同长期以来一直把 CMMI 评估等级用作供应商资格审查的依据,而美国 CMMC(网络安全成熟度模型认证)之类的框架,直接把网络安全成熟度与是否有资格承接国防工作挂钩。这让成熟度模型拥有了真正的约束力。这也带来了本章的核心风险:一旦某个级别变成了一道门槛或一个目标,人们就会为了通过评估而优化,而不是为了提升背后真正的能力。用得好,成熟度模型是一面镜子。用得不好,它们就是一场表演。

Key principles

  • 成熟度是手段,不是目的。 目标是能力和成果,而不是一个级别数字。
  • 为学习而评估,而不是为打分而评估。 诚实的自我评估胜过一份讨喜的评估报告。
  • 更高不总是更好。 正确的目标取决于风险、场景和成本。
  • 按领域分别度量,而不是给出一个整体分数。 能力水平参差不齐;单一数字会掩盖这一点。
  • 优先处理成熟度最低、风险最高的缺口。
  • 警惕古德哈特定律。 一旦某个级别变成了目标,它就不再能衡量真实能力。
  • 定期重新评估。 随着人员、系统和威胁的变化,成熟度也会漂移。

Recommendations

为该领域选择合适的模型

把模型与你想要提升的能力匹配起来,并在存在成熟、基于证据的模型时,优先选用它们,而不是自行发明:

  • 流程与交付: CMMI(广泛的流程成熟度)、DORA 能力模型(交付绩效,有研究支撑,见第 11.2 章)。
  • 安全: OWASP SAMM 和 BSIMM(软件安全实践)、CMMC(国防网络安全)。
  • 测试与质量: TMMi。
  • 敏捷与工作方式: 敏捷流畅度模型(第 10.7 章)。
  • 数据: 数据管理成熟度模型(DMM、DCAM)。

对内部使用而言,按每项能力分别套用一套简单的四级或五级量表(如本书所做的那样),往往比一套重量级的外部框架更具可操作性。把正式的、经过评估认证的模型留给合同上确有要求的场合。

诚实地、按能力逐项评估

进行能够产出真相、而非产出安心感的评估。让实际做这项工作的人参与进来。收集证据,而不是意见。为每项能力分别打分,使画面反映现实:这里强,那里弱。一份用来指导改进的自我评估,比一份用来获取徽章的外部评估更有价值,因为前者奖励坦诚,而后者奖励表演。第 12.4 章为本书涵盖的每个领域提供了一份汇总的自我评估;把它当作起始工具来使用。

用成熟度来排定优先级,而不是用来惩罚

一次评估的产出,应当是一份经过优先级排序的改进待办事项列表,而不是一份用来问责的成绩单。把成熟度与风险结合起来看。一个低风险领域中的第 1 级能力可能完全没问题。而一个安全或合规攸关领域中的第 2 级能力则是紧急事项。把投资导向低成熟度与高风险交汇的缺口,并把这项工作与成果(第 11.1 章)联系起来,使改进是依据结果来衡量的,而不是为了攀爬阶梯本身。

有意识地设定目标级别:更高并非没有代价

每提升一级都要付出努力,往往还会增加流程负担。正确的目标很少是”处处都要第 5 级”。而应当是这样的级别:对该领域的风险而言,额外的能力仍然能够证明额外成本的合理性。受监管和安全攸关的能力可能确实需要最高的几级,而审计往往至少要求达到”已定义”的第 3 级。而许多其他能力在第 3 级就已经服务良好,继续往上推只会累积官僚主义。按每项能力分别决定目标,一旦风险调整后的回报停止增长,就停止攀爬。

警惕成熟度表演

摧毁成熟度模型价值的那一种失败模式,就是为了分数而优化。警惕那些打分过于慷慨的评估、只为应付评估而临时拼凑的证据,或是与生产环境中的事故相矛盾的”第 5 级”声明。让评估始终与可观察的行为和真实的成果绑定。轮换你的评估人员,或引入外部核查。把可疑地高的自评分数视为一种异味。一旦级别本身变成了目标,这个模型就不再告诉你真相。

Trade-offs: pros and cons

方案优点缺点
正式的、经过评估认证的模型(CMMI、CMMC)可比较、受合同认可、严谨成本高;容易招致刻意迎合;可能使流程僵化
轻量级的内部记分卡快速、可操作、开销低对外部的可比性较弱;容易带有偏见
基于证据的能力模型(DORA)与真实成果绑定;有研究支撑范围较窄;需要真实的指标数据
单一的整体成熟度分数便于沟通传达掩盖了参差不齐的能力;具有误导性
按能力逐项评估准确,能支持可操作的优先级排序需要更多精力;没有单一的概括性总分

核心张力在于评估作为一面镜子,与评估作为一个目标之间的对立。同一个能帮助团队清楚看清自身的模型,一旦某个级别与奖励、资格或地位挂钩,就会立刻变得适得其反。一个级别越是举足轻重,就有越多的精力会流向成熟度的表象,而不是其实质。

Questions to discuss with your team

  1. 我们是否应当把一份坦诚的内部自我评估,与任何经合同认可的评估级别分开保存?各自由谁负责? 当 CMMC 或 CMMI 的级别决定着收入时,评估结果和真相就会渐行渐远,因为精力会流向”通过”,而不是流向”改进”。对大型企业或政府供应商而言,风险正藏在这道缺口里:你通过了审计,却依旧暴露在风险之中。要有意识地维护两本账。把正式评估留给资格审查用途,同时保留一份没有人会因虚报而获得奖励的直白内部记分卡。为各自指定一位负责人,把二者之间的任何差距都当作需要调查的信号,而不是需要掩盖的东西。把近期的事故、险情和评估之后能力的衰退情况带到会议上,作为判断哪一本账在说真话的证据。

  2. 对每个领域,我们采用的是成熟的、基于证据的模型,还是在自行发明记分卡?这个选择正确吗? 成熟的模型(用于交付的 DORA、用于安全的 SAMM 或 BSIMM、用于测试的 TMMi)带有研究支撑和外部可比性,这是自制表格无法匹敌的。一套轻量级的内部四级量表更快、更具可操作性,对于内部引导而言往往是更好的选择。陷阱在于发明一套重量级的定制框架,它具备正式模型的全部仪式感,却没有任何证据基础。按领域分别决定:把正式的、经过评估认证的模型留给合同确有要求之处,在合适且存在基于证据的模型时使用它们,其余情况则保持一套简单的按能力分级的量表。带上领域清单,标出每个领域今天在使用哪个模型,并对每一份自行发明的记分卡提出质疑。

  3. 谁来运行我们的评估?我们如何发现打分过于慷慨的情况?我们多久重新评估一次? 一次由自己给自己打分的评估会自我美化,而随着人员、系统和威胁的变化,成熟度也会漂移,因此一份两年前的评估结果往往已经形同虚构。轮换评估人员,或引入外部核查,把一个可疑地高的自评分数当作需要追查的异味,而不是值得庆祝的胜利。设定一个与各领域变化速度相匹配的重新评估节奏:比如安全领域就应比文档领域更频繁。收集证据,让实际做这项工作的人参与进来,而不是只收集经理们的意见。如果你的答案是某个团队一年只给自己打一次分、也没有交叉核查,那你度量的是安心感,而不是真实能力。

  4. 每项能力实际需要的目标成熟度级别是什么?在哪些地方继续往上推只会带来流程负担? 更高并非没有代价:每提升一级都要付出努力,通常还会增加仪式性流程,因此一个”处处都要第 5 级”的笼统目标,会把有限的改进预算耗费在一些永远回不了本的官僚主义上。对大型组织而言,正确的目标因能力而异,因为一个低风险领域停留在第 2 级可能完全安全,而同一级别的一个安全或合规攸关领域却是一场紧急事态。带上按能力划分的风险评级、对下一级所需精力和流程成本的诚实估算,以及任何审计或合同要求的底线,因为许多审计至少要求达到”已定义”的第 3 级。在企业和政府场景中,一些受监管的能力确实需要最高的几级,而大多数在第 3 级就已经服务良好,因此要按每项能力分别有意识地设定目标,一旦风险调整后的回报停止增长,就停止攀爬。

  5. 我们上一次提升某个成熟度级别时,它本应保护的那个成果是否真的改善了,还是只有分数在移动? 一个级别在攀升,而事故数量、前置时间或缺陷率却纹丝不动,这就是古德哈特定律在起作用:一旦这个数字变成了目标,它就不再衡量真实能力。对大型团队而言,这很容易被忽视,因为一次成功的评估感觉像是进步,即便生产环境讲述的是另一个故事。在投入之前,把每项能力的级别与一个真实的成果指标绑定,然后把前后对比的证据带到讨论中:每季度事故数、变更失败率、恢复时间()不管这项能力存在的目的是要改善什么。在评估级别决定资格准入的企业和政府投资组合中,这道缺口尤其危险,因为级别可以凭拼凑出来的证据上升,而底层实践却在悄悄衰退,而第一个证明这一点的往往就是一次入侵、一次中断或一次未通过的审计。

  6. 我们沟通的是一个笼统的概括性成熟度分数,还是一幅按能力划分的画面?级别是否曾与奖励、排名或团队地位挂钩? 一个单一的整体数字便于向领导层汇报,却恰好掩盖了真正要紧的那种不均衡,因为出色的交付能力可能掩盖了一个第 1 级的安全能力;一份按能力划分的热力图工作量更大,却能显示出低成熟度与高风险的交汇之处。更难的问题在于这些分数如何被使用,因为一旦某个级别与团队的奖励或排名挂钩,诚实的汇报就会消亡,精力也会流向成熟度的表象,而不是其实质。带上这份热力图,并坦率地说明目前有哪些地方,级别正在影响绩效评审、预算决策或供应商记分卡。对于评估级别可能决定收入和资格的企业和政府供应商而言,要明确说清楚哪些分数带有实际后果,哪些只是用来引导方向的,因为一幅人们因虚报而受奖励的成熟度画面,就不再描述现实了。

Sector lens

创业公司。 一套重量级的、经过评估认证的模型,是你在短暂跑道上负担不起的开销。针对少数几项能力,用一套简单的量表做一小时的自我评估,只修复那个阻碍某件具体事情(比如你第一个企业客户提出的安全问卷)的、成熟度最低的缺口,其余的先不要管。这次评估应当只花一个下午,而不是请一位顾问,它的产出应当是一个具体的下一步行动,而不是一个你既不需要、也负担不起的均衡高分。

小型企业。 在没有专职评估人员、预算又紧张的情况下,借用一套轻量级的公开模型,而不是委托定制一套框架:一份可以自评的简短交付或安全清单。把它当作一场一年一度的对话,讨论哪个薄弱环节会让你失去一个客户,而不是一项常设项目。保持它廉价而直接,因为一份你花钱请供应商做出来的讨喜分数,价值远不如一份你自己花一个下午做出来的坦诚分数。

企业。 价值在于一份在众多团队中被一致应用的共享按能力记分卡,这样差距就变得可比较,改进预算就能流向低成熟度与高风险交汇之处。一旦级别开始影响预算或地位,就要严防成熟度表演:轮换评估人员或引入外部核查,把结果当作一幅指导铺路投资(第 4.2 章)的热力图来管理,而不是一张给团队排名、扼杀诚实汇报的排行榜。

政府。 在这里,一个成熟度级别往往就是一道字面意义上的门槛:CMMC 之于国防工作,CMMI 评估之于供应商资格审查。用真实的能力去达到所要求的级别,并把一份坦诚的内部自我评估与正式评估分开保存,这样审计的底线就永远不会悄悄变成天花板。为评估人员透明地整理证据,把认证级别与真实实践之间的任何差距,当作需要弥合的可问责风险,而不是需要归档了事的文书工作。

Examples

创业公司。 一家十人的 SaaS 创业公司,针对交付、测试、安全和待命这几项能力,用一套简单的四级量表做了一小时的自我评估。结果发现交付和测试处于第 3 级,但安全却停滞在第 1 级,这一点很重要,因为公司即将签下第一个提出安全问卷要求的企业客户。于是创始人们用接下来的一个月,只把安全提升到一个站得住脚的第 2 级,其余的先不动,而不是去追逐一个他们既不需要、目前也负担不起的均衡高分。

企业。 一家金融服务公司用一套轻量级的按能力记分卡(交付、测试、安全、可观测性、待命)评估了旗下 40 个团队。热力图显示,安全成熟度在监管暴露程度最高的地方最为滞后,因此平台团队优先为这些团队提供铺路型安全工具(第 4.2 章)的资金支持。由于这次评估被用来排定投资优先级,而不是给团队排名,管理者们如实汇报。一年后的重新评估显示出真实的进展,更关键的是安全事件减少了,而不只是分数升高了。

政府。 一家国防承包商必须达到规定的 CMMC 级别才能参与投标,而一家系统集成商则把 CMMI 评估作为合同资格的依据。在这里,成熟度级别是通往收入的一道字面意义上的门槛。运作良好的做法,是把所要求的级别当作真实能力的底线,并把一份坦诚的内部自我评估与正式评估分开保存。运作糟糕的做法,则是为评估拼凑证据,评估一结束就任由真实实践衰退,通过了审计,却依旧暴露在风险之中。

Business case: motivations, ROI, and TCO

成熟度评估的回报来自定向投资。改进预算是有限的。若盲目投入,它们会流向声音最响亮的地方。成熟度评估会向你展示相对于风险而言能力最薄弱之处,因此同样的支出能买到更多的风险降低和成果改善。评估本身成本很低,只需几天有结构、基于证据的审查,与之相对的,是错配的改进项目的成本,或者更糟()一个未被察觉的能力缺口,最终以一次入侵、一次中断或一次未通过的审计的形式浮出水面。

在总拥有成本方面,如果保持轻量化,这门学问成本很低;一旦它硬化成评估官僚主义,成本就会很高。最主要的隐性成本是成熟度表演:花费精力去制造成熟度的表象,却毫无回报,甚至可能掩盖真实的风险,这是负的投资回报。要向领导层论证这一点,应把成熟度呈现为一副风险与投资的透镜,一幅把”改进一切”变成”优先改进这三件事”的热力图,并明确为抵御”为攀爬级别而攀爬”的诱惑编列预算。在某个级别是合同强制要求的地方(CMMC、CMMI),投资回报是直接的:这是获得资格所必须付出的代价,而目标是用真实能力去达到它,而不是用代价高昂的伪装。

Anti-patterns and pitfalls

  • 把级别当作目标: 追逐一个数字,而不是它本应代表的那种能力。
  • 成熟度表演: 为一次评估拼凑证据,而真实实践却在衰退。
  • 单一的整体分数: 一个掩盖了危险不均衡的单一成熟度分数。
  • “越高越好”的思维: 不顾风险或成本,把每一项能力都推向第 5 级。
  • 只评估一次、再无下文: 把一次性的评估当作永久的真相。
  • 给团队排名以问责: 把成熟度用于惩罚,这会扼杀诚实的汇报。
  • 对模型的盲目崇拜: 超出实用价值的范围,仍然遵循一套重量级框架的全部仪式。
  • 忽视成果: 一边攀爬阶梯,一边交付、可靠性或安全性却没有任何改善。

Maturity model

  • 第 1 级,启动。 没有关于成熟度的共同概念;能力被假定存在,参差不齐且未被度量;任何评估都是被动的,由一次事故或一次审计要求触发,而不是有计划地进行。
  • 第 2 级,发展。 少数团队依据某种量表进行随意的评估,但模型、节奏和严谨程度因团队而异;结果的使用方式不一致,证据也很单薄,因此为了表象而打分的风险始终存在。
  • 第 3 级,标准化。 一套统一的按能力模型和评估节奏被记录成文并在全组织范围内应用;评估基于证据,让实际做这项工作的人参与其中,并汇入一份经过优先级排序的改进待办事项列表,而不是一份成绩单。
  • 第 4 级,管理。 成熟度被数据度量并加以控制:每项能力的级别都相对基线被追踪,与一个成果指标(事故、前置时间、变更失败率)绑定,并按设定的节奏重新评估,因此漂移和慷慨打分会以数字的形式显现出来,而不是靠意见判断,目标也依据风险和成本按领域有意识地设定。
  • 第 5 级,编排。 评估在整个组织范围内被集成并持续改进:成熟度、风险和成果作为一幅自适应的整体画面来指导投资,目标随着威胁和场景的变化而重新平衡,评估人员的轮换或外部核查成为常态,这门学问也会主动淘汰那些已经不值得其成本的仪式性流程。

Ideas for discussion

  1. 你们哪些能力是被假定为成熟的,却没有任何证据支撑?
  2. 你们最低的成熟度与最高的风险在哪里重合?你们的改进预算是否正流向那里?
  3. 你们组织中的任何成熟度级别,是否曾是一个目标或一道门槛?这产生了什么样的行为?
  4. 对每项能力而言,正确的目标级别是什么?在哪些地方继续攀爬只会增加官僚主义?
  5. 你们的团队会诚实地汇报自己的成熟度吗,还是你们使用分数的方式在惩罚坦诚?
  6. 你们上一次”提升成熟度”时,成果是否真的发生了变化?

Key takeaways

  • 成熟度模型依据一个级别阶梯来评估能力,并描述一条改进路径:它是一面镜子,而不是一座奖杯。
  • 为每个领域选择成熟的、基于证据的模型(CMMI、DORA、SAMM/BSIMM、CMMC);一套轻量级的按能力量表往往最具可操作性。
  • 诚实地、按能力逐项评估,并用结果按风险排定优先级,而不是用来排名或问责。
  • 更高不总是更好: 依据风险和成本,有意识地设定目标级别。
  • 警惕成熟度表演和古德哈特定律:一旦某个级别变成目标,它就不再衡量真实能力。
  • 关于本书汇总的成熟度自我评估,参见第 12.4 章,以及每一章自己的成熟度小节。

References and further reading

  • CMMI Institute / ISACA, Capability Maturity Model Integration (CMMI).
  • Watts Humphrey, Managing the Software Process(软件流程成熟度的起源)。
  • Nicole Forsgren, Jez Humble, Gene Kim, Accelerate(面向交付的能力思维,而非成熟度级别思维)。
  • OWASP, Software Assurance Maturity Model (SAMM); BSIMM (Building Security In Maturity Model).
  • U.S. Department of Defense, Cybersecurity Maturity Model Certification (CMMC).
  • TMMi Foundation, Test Maturity Model integration.
  • James Shore and Diana Larsen, The Agile Fluency Model.
  • Martin Fowler, “Maturity Model”(bliki 博客),关于其用法与滥用。