【】成熟度模型罪与罚

成熟度模型是一种工具，可以帮助人们评估一个人或一个团队当前的有效性，并分析他们下一步需要获得哪些能力以改善其绩效。在许多领域，成熟度模型的名声很差，很容易被滥用，但在适当的情况下可能会有所帮助。
成熟度模型在软件行业里流行甚广， CMM（Capability Maturity Model）可以说是软件领域最著名的成熟度模型。在敏捷开发之前，大部分软件开发组织都会尝试通过CMM评估来确定自身的能力水平和确定提升方向。 CMM本身对于推进软件开发的过程规范性起到了一定作用，但基于成熟度的认证却将大部分参与CMM评估的组织推向了形式化，远离了建立能力成熟度模型的初衷。

本文插图
（CMM基本分级模型示例来自wikipedia）
成熟度模型一般会被构造为一系列有效性级别，比如CMM的1到5级。使用成熟度模型时，首先要进行评估，确定被评估者当前正在执行的等级。确定现行等级之后，便可以使用之上的等级来确定接下来的能力发展方向。明确所需能力的优先级确实是使用成熟度模型的最大好处，基于这样的认知，如果处于第二级，那么获取第三级的能力要比第四级的重要很多。针对复杂领域，这样的分级认知有助于快速共识和改进计划的制定。
Martin Fowler在Maturity Model一文中提出的观点是：成熟度模型评估的真正结果不是您处于什么水平，而是您需要改进的工作清单。您当前的水平只是一项中间工作，以便能够确定接下来需要获得的技能列表。
敏捷开发普及以后，成熟度也成为一个不可不谈的工具，特别在大型组织里，成熟度成为了敏捷规模化推广的首选。在过去的5年时间里，我们已经帮助数十家企业建立了自己的敏捷成熟度模型，成效和副作用应该说都客观存在，借用此文小结，供大家参考。
成熟度模型的药效
在敏捷开发的上下文里，历史的经验告诉我们是不太可能在近期出现一个可以通用的能力成熟度模型的。这里有两个客观原因：

软件服务的业务领域太广，各个业务领域对于软件开发能力的诉求存在较大差异，比如互联网服务平台和大型工程设备制造。
软件仍然是一个新兴产业，技术的更新换代造成能力的迭代速度很快，即使在比较成熟的Web技术上，也没有人可以准确告知两年后主流的JavaScript框架是什么。

基于这样的认知，在帮助企业建立自己的敏捷成熟度模型之时，我们还是强调从企业自身的发展目标出发，考虑企业的业务愿景和自身的研发诉求。

本文插图
（敏捷成熟度模型AMM的基本构建过程示意）
只有结合组织和业务上下文的成熟度模型才可能产生正向的成效，从多年的经验来看，主要成效聚焦在以下两个方面。
敏捷改进目标共识
敏捷开发的导入对一个组织来说是一次变革，对于任何变革来说，设定明确的改进目标都是关键的第一步。即使仅从研发视角出发，统一目标也不是一件容易的事情。开发同学们觉得需求不清是最大问题，而业务分析会认为开发质量差是关键，最后测试团队强烈建议先解决环境不足问题。
面临这样的不同声音，成熟度模型很大程度上可以帮助大家建立一个更加全局的系统性认知。任何组织引入敏捷的初衷都是希望能够构建快速响应外部变化的能力，基于组织存在的业务环境和经营愿景，大家的关键改进点是不同的。比如金融机构可能需要更多的考虑变快的过程中安全能力如何跟上，互联网服务公司则更需要看到整个团队对用户体验的关注。
如果执行正确，建立敏捷成熟度模型的过程就是一次帮助大家跳出自身角色帽子限制，真正站在组织视角来审视变革改进关键点的机会。从这个视角出发，其实构建成熟度模型的过程就是一个敏捷项目，同样强调跨职能的协作。通过端到端的分析，开发同学可能会发现需求不清也许不是现在需要改进的关键点，而集中力量构建端到端的流水线是更重要的任务。