DevOps 实践指南 : 变革管理

组织转变 – 变革 Change Management

我遇过几次大的变革，英文写起来轻松多了change management，但没有轻松这回事。有从130亿的大公司转变成35亿的变革，也有从上千人的公司转变成数百人的公司的变革，这些年来即便我是以顾问的位阶参与组织的改变，但我总觉得自己从没有看到过变动的全貌，甚至是事后来自报刊杂志上的描述我都没办法分变真假，也习惯把不能了解的原因推给自己不是核心成员,因此看不见内幕、不知道是谁、为何做成那样的决策，又怎么可能看见全貌呢？！

旁观者清

但其实是当局者迷，旁观者清。例如:我尝试把英文版的DevOps Handbook 5～8章专讲变革的部分节录下来传给他们(正在进行变革的主管)参考，但总是没有获得好的回应(现在可以传中文版了，结果一样没反应)，想想；实在不能责怪他们，人们总觉得必需靠自己想清楚了变革才会成功，而书本上讲的只是原则，实际上没那么简单，等过了这段浑沌的时间后再来看吧！但其实不是这样的……

用价值流Value Stream帮你看见全貌

变革之初；要先画出企业引以为生的产品或服务的流程图来，它可以帮你看见全貌。运用可视化的方式来看清楚自己是怎么运作的，画出来的价值交付过程的图示就叫作“价值流程图”（value stream diagram）。这不是什么新技术，Toyota 用它来调整工厂运作的生产线效能已经很多年了(注1)。OK，画出价值流之后呢? 也就是当你客观的去面对自己团队的工作流程时，接下来该做什么呢?

选择合适的「价值流」作为切入点

本书最重要的一章，就放在概述完三步工作法之后

用来判读「企业效能」的流程范例 ( 效能: 企业都不能忽视的地方)

二种团队的转变方向: 「职能导向与市场导向」图示

书中屡次提到的 Puppet Lab Report (DevOps Team由2014的16%进步到2017的27%)

显示企业效能的4个重要指标

验证 Robin Dunbar 的 150人上线法则

注1：企业面临转型时（re-organize) 传统的作法： 先拟定方针再规划过程最后才决定执行的程序，由这三方面来考虑铺成细节。现在的组织则说动就动，步调变快了，往往疏忽了许多细节，但更见勇气可嘉。

注2：价值流其实是多维度的，而价值流的描述或是应用的工具却多是线性的，这一点经常为人垢病，但把它视为抽像化的结果却可以让我们看得更清楚些，也是值得的。

流程改变参考书籍： 《过程改进手册》by: 特里斯坦·布特罗斯 《组织变革管理》by:伊恩·帕尔默

注：本文转自李智桦老师的博客