成熟度模型将复杂的事情简化，但我们需要认识它们被许多组织采用的背后的原因。
译自 Why Maturity Models Are Fundamentally Broken 。译者感同身受，确实自治是无比重要的要素。
成熟度模型有一定的吸引力。它们将大量复杂的内容简化为称为成熟度等级的简单步骤。只要完成第一个等级的所有要求，就可以进入下一个等级。
成熟度模型之所以受欢迎，是因为它们使复杂的事情看起来简单。特别是，它们可以以无相关专业知识的人也能理解的方式来呈现一个课题。
成熟度模型的简单性也是其最大的弱点。尽管如此，如果我们想要超越它们，我们需要认识到导致它们被许多组织广泛采用的原因。
让我们简要总结一下为何成熟度模型从根本上有问题，然后探讨您应该做些什么。
我在一家医疗保健行业的公司工作，该公司需要开发一个新的软件产品。由于过于热心的销售团队，已经制造了一个危机，这意味着公司愿意给团队它需要的一切来交付该产品的第一个版本。
我们组建了一个小团队，包括交付软件所需的所有人员，其中还有一名接受过临床培训的护士。我们对流程进行了实验，实现了高度协作的方法、单件流动和快速反馈循环。我们在每个功能开发结束后使用回顾过程来细调流程。
经过几次迭代后，我们可以每三个小时交付一个功能。在六个月的时间里，我们交付了许多没有回归缺陷的软件工作版本。
拥有设计自己流程的自主权，让临床和技术人员组成的团队可以创建一个完美契合复杂和具有挑战性的环境的流程。这是我们可以应用于当前问题的最佳流程。
当组织中的管理人员看到这个流程工作效果出色，他们迫不及待地要将其推广到所有其他软件团队。这种标准化做法存在一些问题。
流程和能力并没有带来奇效。关键是这些实践的组合，以及临床和技术团队成员之间的紧密协作。由于我们创建和调整了流程，我们也完全致力于流程。每次变更的驱动因素以及什么行之有效、什么不行之有效的证据，意味着我们理解为何要以这种方式工作。
使这个团队取得如此成功的关键因素是自治。
这就是问题的核心所在。在创建一个成功的团队和一个有效的流程中非常重要的一件事，却是成熟度模型排除的。
成熟度模型并非完全不合理。正如统计学家 George Box 曾说，所有模型都是错误的，但有些却是有用的。它们基于特定的起始条件和目标条件。每个模型都是为了响应一个不可取的状况和对理想未来状态的构想而创建的。它们捕捉从两个明确定义的点之间的步骤。
如果您有相同的不可取起点，一个成熟度模型可能会给您带来描述的结果。例如，软件成熟度能力模型(CMM)之所以获得关注，是因为许多组织共享相同的不可持续起点。
即使获得了高度关注，结果也非常可变，因为采用成熟度模型的组织与模型作者所处的环境不同。设计一个模型，要求它在不同的产品、行业、人员和组织文化面前都产生相同结果，这是不可能的。
许多引入成熟度模型的尝试在变革管理的过程中失败。一些管理者在每个员工桌上留下《谁动了我的奶酪》的副本，让员工知道问题出在他们身上。其他人试图开展内部营销活动，结果是员工翻白眼和集体冷淡。没有一支写有口号的笔可以挽救一家步向自我毁灭的公司。
如果不关注变革过程，它就会失败。由于成熟度模型内置了“我们比你更懂”的理念，它们对变革工作是一场灾难。
这将我们带回软件交付有效流程的关键组成部分: 自治。
与严格定义专业软件开发者的工作方式相反，应该让他们自己解决这个问题。如果存在约束，开发者会找到创造性的方法来满足业务需求。如果您在一个安全关键或受管制行业，他们会达到必要的条件。
对团队和组织来说最佳的流程，将是他们自己创建的流程。如果他们定期调整流程以改进它，这种流程将保持解决问题的最佳方式。
为了反驳 George Box 关于模型都是错误的说法，我们可以引用统计学家 Peter McCullagh 和 John Nelder 的话:
“所有模型都是错误的；然而，有些模型比其他模型更好，我们可以寻找更好的模型。与此同时，我们必须认识到永恒的真理不在我们的掌握之中。”
如果您评估成熟度模型中列出的每个实践的影响，您就会知道它们是否改善了结果，对结果没有影响，或者使情况变得更糟。您最终会采用有效的实践，而不是全部实践。这是能力模型的基础。
能力模型鼓励持续改进。您可以根据环境定制能力模型，并在情况发生变化时进行调整。您不再是应用一套预定的实践，而是寻找能改善结果的能力。
对于软件交付来说，DORA能力模型是一个很好的例子。没有成熟度级别或步骤顺序。您甚至不需要采用模型中列出的每一项。
相反，您思考您的未来理想状态，并将该模型作为获取想法的来源。通过跟踪结果，您可以避免恶化情况，并及早发现潜在问题。吞吐量和稳定性指标是常见的测量标准，因为它们很好地平衡了竞争的需求。
您可能会引入其他指标来跟踪特定的改进。如果您关注使部署流水线更快，您可能会跟踪构建或测试软件所需的时间。在您收集的任何测量不再需要或转化为健康函数时，必须停用它们，这将在问题重新出现时发出警报。
能力模型提供了预测某些结果的实践线索。我们鼓励您确认这种关系是否适用于您的情况，而不是仅凭信念应用功能。
您还必须开发每项技能，而不仅仅满足最低的证明标准。引入自动化测试等实践可能会在发展技能的同时暂时降低速度。一旦获得足够的掌握，不同之处就会变得明显。
采用一种技术或实践需要投入成本。成熟度模型没有考虑成本/收益权衡。虽然一些模型基于学术严谨的研究，但仍然关键是将改进工作定位到您的团队和组织环境中。
如果有人根据 DORA 研究为您提供 DevOps 成熟度模型，请提醒他们，DORA 团队的许多成员，包括联合创始人 Nicole Forsgren，都说这是一个坏主意。