| 2021-03-05
以下是我个人的经验总结。
百人是组织管理的一个人数临界点，此时才会产生规模化效能提升的诉求，具有一定的代表性。
尽管 DevOps 实践在十年前就已经被广泛理解和接受，但是，我们仍然可以看到，现在大多数组织仍旧在努力扩展 DevOps ，让它的成功进一步扩大到更多的团队。然而，DevOps 经常无法进一步扩张。其中一个原因是，大多数企业的组织结构、想做的事情，以及激励机制者的不一致，并且对他们应该推动的结果缺乏责任感或 Ownership 。
百人组织 DevOps 转型的前三个步骤
当软件组织达到百人以上，仅仅生搬一组 DevOps 实践，是无法进一步让 DevOps 所提倡的文化扎根的；您必须进行相应的结构调整，从而优化团队的工作方式。
然而，在结构调整之前，很可能还需要先经历三个步骤，如下所示。
规范化 （Normalization）
DevOps 运动（或者理念）有一个非常重要的关键点，就是“度量 （ Meature ）”。然而，现实中的大多数软件企业的软件工程化管理并不具备可度量性。常常出现的情况是，一些常见的工程生产活动因“执行人”的不同，而产生不同的“最终效果”。所以，某个活动的结果好坏很大程度上取定于所谓的“执行人是否靠谱”。这种方式在创业初期是无可非的。但当创业进入快速发展期（业务规模扩大，人员规模增加）之后，会带来“生产效率下降”的直观感受。
这是因为在快速发展过程中，队伍的壮大使得原有的信息传递方式不再有效，新加入公司的人对工程生产活动中的各环节都有自己固有的默认标准（但并不是公司所公认的，而是自己心目中的）。
所以，即使是同一类型的生产活动，在公司的多个团队的执行方式都有所不同（各团队的约定不同）。
所以，必须通过规范化来解决因信息传递不一致（活动执行不规范）带来的不必要浪费问题。
这是一个组织成员共同建立新的协作共识的过程。
例如：工程生产活动中的需求分析与拆分，软件质量验证，部署上线流程等领域进行了规范，限定了基本动作与产出要求。但因为很多历史原因，同一领域可能会有两套以上的规范，以应对不同的场景。
当规范化达到一定的程度，才能使有效的度量成为可能。
标准化（Standardization）
当具备了有效度量的基础之后，下一个要解决的问题的达到可验证的有效性度量。
通过规范化，我们是可以收获一些数据（多数是人工收集和统计）来指导我们的 DevOps 改进，但会带来进一步的管理诉求，即：我需要更多更详细的数据，来指导改进。例如：为什么两个团队的同一指标会有如此大的差异。这种差异是因人工参与而导致的异常数据，还是因为其场景真正的不同而带来的差异。这种场景的不同是真实业务本身需求不同，还是因为其它原因导致的不同。
所以，此时会对每个工程生产活动中的下沉场景进行分析，将规范化的内容进行建模，提炼出数字化流程模型，在各专业工程流程领域找到相应的工具支撑。
此时，组织已具体了有效度量的能力。
平台化（Platfomation）
当组织进一步扩大以后，就有必要进行平台化建设，以便应对人员及生产规模化带来的附加管理成本。此时，需要通过多领域平台的集成，解决工程生产各环节之间的信息流动效率问题，解决 Scaling up ，使得业务增长曲线高于人员增长曲线，至少不明显阻碍规模化收益。
解释说明
初始时，因组织快速扩张，会因人员行事方式不一致， 导致效率低问题。通过前两个阶段，使得工作流程中每个环节的协作结果及其交付质量情况可预期（一定程度的受控），从而解决人与人之间的“协作信任”问题。
第三步的贯通性是在解决了“协作信任问题”的基础之上，通过进一步连通各数字化工具，建立集成平台，消除原来一些环节中“人与人之间的信息依赖”问题，此时的贯通性会带有一定的自助化特征，同时也会带来更丰富的有效度量项。
是否可以三步合成一步
理论上来说，三步是可以合成一步的，但此时组织所面临的阻力也很大，结果达成率低，很可能会夭折。但并不是说，不具有理论上的可能性。