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

新兴业务领域，组织规模有限，并且没有形成固定的职能划分。不同于成型业务，这样的研发团队内部大家往往会觉得缺乏规则比较混乱，很容易寄希望于成熟度模型来明确职责规范。但必须认识到这样的混乱其实更多是业务不确定性所带来的，反而应该尝试让团队理解这样的不确定，让持续变化成为团队常态。

组织改进的过程中还没有培养出自己的敏捷教练队伍（或类似改进力量），外部顾问和教练仍然是转型推动的主要依靠，这个时候建立成熟度模型会直接造成模型成为一纸规范，和一线实践脱节。

从临床经验看，成熟度模型的药效和副作用都可能很显著，本着敏捷精神，持续实践反馈、迭代调整是必不可少的正确用药方式。
成熟度模型的提炼
如果决定采用成熟度模型，提炼也是有讲究的。下图我们给出了一个比较常用的过程。

本文插图
（典型的成熟度模型提炼过程，来源于多家企业实践）
这里要特别强调后面两步，模型本身是用来指导团队改进的，所以整个组织、每个团队的共识理解是关键一步。这样的共识是不可能通过红头文件达成的，更需要人和人之间的互动交流，通过不同渠道让更多人参与到讨论反馈过程中来。
模型的初步验证也需要团队真正去使用，只有驱动出真正有效的改进，模型才是有价值的。
【【】成熟度模型罪与罚】 伴随组织复杂度的流畅度模型
在敏捷领域里其实很早已经有了不一样的思考 —— 敏捷流畅度模型，由Diana Larsen和James Shore在2012年提出的。

本文插图
（敏捷流畅度模型）
不同于成熟度模型，流畅度模型总结了四个区域（Focusing、Delivering、Optimizing和Strengthening），打破了成熟度模型的线性结构。不同的企业和组织根据自己的环境上下文可以选择适合于自己的区域去改进和发展。
在复杂业务场景下，成熟度级别区分带来的绝对好坏评判越来越不确定，取而代之的是针对特定上下文的适合与不适，进而随着上下文改变而改变的不同选择。正如我们每个人日常语言学习都能体会到的，如果只是希望能够玩电子游戏，几个典型的英语单词就够用了；而如果需要在外企工作，则至少需要基本的英语沟通；如果选择外派，那么英语可能就需要到达一定专业水平。
随着数字化时代的深化，每家企业和每个研发组织实际上面临的业务场景是日益复杂的，所以流畅度的理念也为越来越多的团队所接受。
ThoughtWorks也将这样的流畅度元模型借鉴到了企业数字化转型这个复杂工程中，形成了数字化流畅度模型，希望能够帮助面临时代挑战的企业构建真正的组织级敏捷能力。

本文插图
(ThoughtWorks数字化流畅度模型示意，从横轴的五个板块儿去帮助企业分析自身数字化转型所需的核心投入）
不久的将来，我们可能不会再问 “你的组织成熟度几级？” ，取而代之的是“你的组织保持应有的流畅度了吗？” 。
文/ThoughtWorks 肖然
更多精彩洞见，请关注微信公众号：ThoughtWorks洞见