【】成熟度模型罪与罚( 二 )

本文插图
(成熟度模型梳理现场照片，不同角色共聚一堂进行研讨）
正确建立成熟度模型后，具体改进工作的设计也会得到很大的提升。在敏捷转型的过程中，对于组织最有效果的改进往往是跨部门、跨职能的，当然也是最困难的，需要打破组织内部已经形成的边界。只有让大家看到全局，才有可能让团队理解为什么开发也需要进行自动化测试的撰写，而测试也需要和业务分析结对。
最后想要获得目标共识上的最大成效，千万别忘了敏捷迭代，定期根据改进结果进行目标的调整，乃至成熟度模型的调整，都是必要的。同时也并非一次要把成熟度的每个级别都进行详细分解，如果大部分团队都处于变革的初始，对成熟度模型的高级别进行具体定义是没有意义的。别忘了目标本身应该是团队努力可及的，而不是飘在空中的海市蜃楼。
敏捷规模化组织推广
很多组织在启动变革时并没有构建自己的成熟度模型，而是聘请了外部顾问，根据他们的经验模型进行分析和诊断。 AMM评估也成为ThoughtWorks咨询团队在帮助企业启动敏捷转型的一个相对标准实践。

本文插图
ThoughtWorks最早提出的AMM原型，包含了10个实践领域和6个评级
（此模型多年前内部共识是不公开发表的，避免行业误解为通用敏捷开放能力模型。）
真正的敏捷成熟度模型构建工作是在第一阶段的试点和实践导入之后，其目的是为敏捷在组织的规模化推广做准备。从转型的视角看，这是我们推荐的，也是针对大型组织一种行之有效的落地执行方式。
在规模化推广上，正确执行的敏捷成熟度模型同样遵循前文描述的构建方式，并能够结合多方意见，包括企业的业务部门，设定合理的组织级改进目标。 “组织80%团队达到成熟度3级”这样的目标很容易设置，但却需要异常小心，别忘了不同的研发团队间可能差异很大，移动APP应用团队和大数据平台团队不管在人员结构和技能，还是在节奏和产出上都不可能一刀切。
在一些卓有成效的敏捷改进过程中，我们看到组织将组织级成熟度模型的建立和敏捷教练组工作进行联动，让一线的敏捷教练成为成熟度模型的负责人，从而能够真正让团队在改进工作中践行成熟度模型中的要求。这样的实践思路是接地气的，也是敏捷宣言提倡的，通过工具更加关注人与交流！
成熟度模型的副作用
CMM从最早提炼的良好初衷到后期认证带来的形式化，给我们生动地展示了成熟度模型的副作用。作为一种线性的模型，存在两个致命的缺陷：
团队和组织容易在成熟度模型的牵引下形成惯性的“升级”思维，忘记业务发展和改进成效才是目的。为了升级，很多改进动作实际上并没有落地，也没有人研究是否真的应该去构建更高一级的能力，投入产出的ROI是否合理。成熟度模型本身成为了僵化的根因，由于成熟度上要考察测试能力，所以就有专门的测试部门进行“持续改进” 。这点即使在我们经历的各个组织转型过程中也屡见不鲜。成熟度模型制定后，各个部门开始认领自己的维度，每次的评估结果成了各个部门PK的工具。
怎么规避副作用是大家共同关心的问题，然而第一个问题却应该问是否采用成熟度模型。显然如果这个问题有标准答案，那么我们又会陷入成熟度模型已经遇到的尴尬，时代的持续发展和组织形态的持续进化，要求我们在建立任何模型的时候都需要谨慎。有几种典型情况下，我们建议研发组织暂时不要启动成熟度模型的建设：

组织刚开始导入敏捷开发的基本理念，组织结构仍然是相对比较传统的职能仓筒划分，这个时候尝试建立成熟度模型很难不被已经存在的部门壁垒所左右。
- 上一页
- 1
- 2
- 3
- 下一页