如何衡量一个逐渐走向规模化敏捷的研发组织是否稳定以及足够成熟

首先这感觉是我许多不来CSDN以后，时隔了几年才来更新的一篇文章

过去一直穿梭在各种企业的敏捷转型活动和workshop中，自感也有一些飘忽。现在经过最近这2年的深入细节的管理和实施项目的熏陶下，逐步才开始找寻到了真实的自己。

唯有做自己最最适应，感到愉快，并且充分能反应出硬核技能的工作，才能让自己路真正走宽，并不是说自己走的多窄多冷门于是乎你就有多牛逼的人生的。这条也请广大网友思考一下自己的职业生涯。

那么闲话就不多说了，我们直接来谈正题，为什么要在这个论题上说一说自己的看法呢？

首先，我们还是想来谈一谈敏捷组织的本质。构建敏捷型的企业，本质是利用更多由小团队构成的敏捷业务线或者部落将很大程度上提供企业一种快速响应的作用。组织因为被切分成了专精于某一个特定业务领域或者职能领域的小颗粒的团队，因此这些小颗粒的敏捷领域的小队能够在内部快速反馈和思考。真正达到群体智慧。那么在这个情况下，研发组织本身是否敏捷或者敏捷了但是是否足够的稳定，符合一定成熟度或者标准。该如何来衡量呢？这是我们希望来探讨的第一个问题。

根据我们第一个敏捷本质论的说法，研发组织结构与业务如何高效融合便是重要的第一课题。假设我们在一个组织结构仍然存在严重壁垒的情况下，自然是一种错误的敏捷方式，那么自然的沟通效率或许只会比过去更大。这里还可能存在第二种情况，那就是我们的组织看起来朝着敏捷方向在走了，但是其实背后的问题是，仍然存在着巨大的沟通成本，究其原因可能业务线的划分可能并没有很好的将业务需系统的耦合度拆解清晰，因此就可能出现A业务线中具有B业务线中所包含的一个子业务，那么当B在谈论业务线具体的需求时，仍然需要A的支持，那么本质上A和B业务线并没有得到完好的切割，最后就导致了仍然存在巨大的沟通成本，甚至可能比原来更大。

个人所可以给出的建议是：尽可能清晰的梳理业务线并且梳理业务的价值流所流经的系统。也就是我们俗称的价值流分析。这样，无论是否真可能改变，但是至少我们可以清晰的梳理出各条价值流中所流经的业务需求以及系统和团队。帮助以后可以更快速的识别风险与问题。

其次，衡量组织好坏，成熟度与否的方法自古以来就有好几种了。那么是否我们应该用其中的某一种方式来衡量组织是否成熟了呢？答案也是很肯定的，你希望用哪种成熟度模型来衡量组织，你就会得到一种什么样形态的组织。怎么理解这句话的意思呢？我们衡量组织能力一般而言可以通过衡量组织能力成熟度（CMMI，ASPICE，ISO等等）。用该类成熟度衡量的好处是，可以迅速达到标准化流程的目的，并且当一个组织可能是百废待兴的过程中更需要的并不是让组织快速达到自管理的状态，而是快速进入一个可管理的状态才是企业中高层领导者所愿意看到的，这也是让所有的新加入者愿意看到的。应该没有人愿意加入一个到处留有上升通道可以让基层改变组织，但是在必要的统一标准化部分看不到统一流程和角色边界的组织的。很多组织中人员严重流失的问题根因也大多如此，组织是否可以整齐划一步调一致战略目标对齐一致，都是衡量组织是否具有战斗力的基础考量因素之一。

个人所可以给出的建议是：尽可能参考一些标准化模型来打造一个具有价值观，原则，基本工作方法统一的组织，在不同业务领域允许采用一些基于基本原则的个性化改动，这其实更符合大众的需要，试想过分的自制相当于组织缺乏一个有效的控制中心，那么如何保证步调一致朝着共同的业务战略方向前进呢？当然不可否认的，随着组织文化和领导力的逐步演变，我们必然会朝着绿色甚至青色组织的方向去发展，但是这个过程中也必然经历一个标准化建设的过程。两者其实并不冲突。对于领导力与组织文化，也是我们所需要怎样的成熟度的一个重要考量因素之一。

这里本人就不去罗列到底是要怎样的标准化模型了，难免陷入对于解决方案的错误与否的探讨。

这里再做一个重要解释，为什么我们没有说才有敏捷的某些体系例如S@S，Nexus，Scrum of Scrums，SAFe或者LeSS，甚至Scott Ambler的DA框架和模型来衡量研发组织体系呢？主要原因在于从整个研发组织体系建设的角度来讲，敏捷的价值观理念一定是轻量级且各家都没有过多阐述具体的体系维度的，愿意也是回到我们的第一条，敏捷组织的本质是需要组织能够学会思考和演变。因此不同组织对于体系的认知和需要也是不同的。在这里个人经常的用法是结合敏捷的原则和价值观来衡量组织敏捷程度和意识形态，而用更全面的组织能力成熟度模型来对组织有一个全面的认知。本人也并不是某一个组织能力成熟度的铁杆粉丝或者评估师，但是也参与过几次大型的评估活动，深知其中的奥妙和必要性以及非必要性，所以并不希望在本文中过多推销某成熟度体系。

最后，无论我们采用怎样的模型，设置了怎样的组织架构，都及不上一个有效的交付成果，也就是说如果研发所努力的业务需求投入方向与业务战略并不一致，自然再高的研发效能也无济于事。

总结来说，如何衡量研发组织是否稳定且灵活，我们需要如下因素：

1. 灵活的可接受不断演变改进的组织架构，维持足够的独立性足够的解耦合

2. 选择合适的成熟度模型是为了给组织带上一个适合的铠甲，起码在我们整体体系方面可以有一层保护作用，知道什么层面应该做什么样的体系，即便今天不需要改进，我们也可以对组织的研发体系有一个全面的认识

3. 业务方向的正确性是衡量研发组织是否足够与业务端对齐的重要依据，是比单纯存在于研发端的效能提升更有效的考量因素。当然我们这里只是说更优于而并不否认研发效能的重要性。

希望本文对于那些正在构建组织研发成熟度的企业或者企业内部的研发组织有帮助。

有任何问题欢迎来和我本人探讨，目前本人作为外部顾问任职于某头部车企数字化研发部门。

微信号: nuchannelx