译者前言：DevOps实施本质上就是一种变革管理。本文是系列的第3篇（共8篇），阐述了著名的Kotter变革管理模型。我记得王明兰老师曾经在《华为云DevCloud 百人大规模精益DevOps转型》演讲中（2018，DevOpsDays北京站），将Kottter模型和华为DevCloud团队如何引入大规模精益和DevOps做了对应阐述，印象非常深刻（文末有引用）。本文原作者Ben Mulholland。

Kotter（科特）理论

Kotter理论是这个系列中的第一个较少关注变革本身，而更多地关注其背后人（尽管是从自上而下的角度来看）的变革方法。通过激发变革的紧迫感并保持这种势头，Kotter 的理论可以很好地调整你的业务以适应当前环境。

科特的理论共8个步骤：

1.营造紧迫感

2.建立核心联盟

3.形成战略愿景

4.让每个人都参与进来

5.消除障碍、减少摩擦

6.产生短期胜利

7.保持加速度

8.将改变固化下来

方法说明

1、创造紧迫感

首先，你需要为变革创造一种紧迫感，这将提供你所需的初始动力，以使你的团队参与并有动力进行改变。

其中好的地方在于，你不需要为创造紧迫感做所有的工作 — 一旦你有一个核心小组，他们愿意讨论这些变化，那么他们很可能会与其他人交谈并说服他们使其有同样改变的意愿。

评估潜在威胁、竞争对手正在做什么、以及你可以利用的机会，然后利用这些与你的团队开始讨论对公司的影响以及应该采取哪些措施。

2、建立核心联盟

一旦你启动变革，你需要让关键人员加入。召集组织中的领导者和利益相关者，并使他们相信变革的必要性。

这一步非常简单，但应该确保你拥有来自不同经验水平、技能组合的优秀人员。请务必特别要求他们对这些变化做出承诺，因为你需要一个强大的推广核心，能够接触到你业务中的每个员工。

3、形成战略愿景

这一步需要定义你的变革和目标愿景。这里的关键是不要用大量的细节或复杂的想法或语言使听众困惑。

写下变革要实现的价值、变革的内容以及预计带来的结果。将摘要总结为一两个句子，并用足够简单的语言让核心小组中的每个人都完全明白你的意思。

如果你的联盟不能用几句话来描述你所希望的变革，你就没有希望说服一线员工为什么它们很重要。

4、让每个人都参与进来

现在是时候将变革的想法传播给组织的其他人员，包括一线员工了。

尽管定期召开会议与你的团队讨论愿景和变化是一个重要手段，但您还需要在会议之外推广这些要素。不仅如此,你不能只是将信息塞给员工，并期望他们盲从 — 你需要对反馈持开放态度，并主持有关该主题的讨论。

从本质上讲，这里的目标是让整个组织相信变革是必要的，以及为什么要进行这些改变 — 这为稍后的员工能够部署变革奠定了基础。

5、消除障碍, 减少摩擦

如果一切顺利，那么您的员工应该渴望开始改变。在此之前，花点时间评估哪些因素可能会阻碍变革的进展，这至关重要。

例如，员工可能没有使用新技术的技能，或者团队可能没有用于执行新任务的足够人力。无论问题是什么，确保尽可能解决它。

可以通过分析架构和流程来观察它们是否对变革造成了阻碍，并在问题出现后尽快解决（人和技术）。

6、产生短期胜利

我们终于开始部署变革，但现在你必须格外警惕 — 改变的最初动机不会永远持续下去。相反，你需要确保与变革相关的短期胜利，用于展示取得的成果并表彰员工。

这既能带给你的团队一种成就感，同时向他们展示了正在进行的改变，使他们更有意愿推进变化。

尽管最好提前规划这些里程碑，但你可以随时测量变革的影响，然后将该数据呈现给团队，以准确显示其绩效改变的幅度。

如果你正在努力找出任何里程碑，你还是可以随时奖励那些坚持变革、并帮助你实现目标的人。

7、保持加速度

此阶段旨在保持变革的势头。如果成功了，加速度本身就可以把你带来足够的变化，使得在团队劲头消退之前，改变的部分已经成为新的行为习惯。

评估您的团队所取得的任何成功（或失败)，看看发生了什么以及下次可以改进的地方。除此之外，无论何时达到目标，都要确保设定新目标，让您的团队有所作为。

8、将改变固化下来

最后,您需要确保改变被很好地固化下来，不光在文档中更要在公司文化里。除了需要对必要的流程做更新外，你还需要把变革的成功发扬光大，并帮助他们坚持下去。

例如，巩固变革的一个好方法是宣布并肯定核心联盟及其对最终产品的贡献。这凸显了他们在变革中的工作，你对反馈的积极倾听，以及变革作为一个整体的正面意义。

现在要做的就是对下一轮改变重复以上的变革过程。

好的方面

Kotter 理论的最初几个阶段非常出色，它们通过创造紧迫感和说服每个人为什么需要变革来为成功奠定基础。这为你的团队提供了实施变革所需的动力，因为有足够的人员进行部署以使其快速将其成为标准做法。

不足的方面

然它主要关注于如何使变革在组织中被广泛采纳，但本质上Kotter 的模型是一种自上而下的方法。由于这里没有太多自下而上的反馈，如果不额外做些努力而只是告诉该员工该怎么做，很可能会使他们对变革疏远。

这可能是因为 Kotter 的大部分经验来自与大型自上而下的公司合作，但对于依赖更具协作性的公司来说，这可能是一个问题。对于大公司以外的任何公司来说，双向的反复沟通是至关重要的，因为可以从不同观点和技能组合对变化提供背景信息，并可以让员工适应变化。

Kotter首次在他的《领导变革》一书中详述了他的变革管理模型

这样说 — 如果你的公司小到你知道几乎所有为你工作的人的名字，那么你需要超越科特一步来倾听你的团队的意见。这样他们就更有可能采纳你提出的改变，因为他们至少对变革表达了自己的意见，并建立了直接的关联。

结论

科特的理论作为一个清单使用很好，但缺乏必要的双向沟通（以及在某种程度上，可操作的指导）作为一个可以逐步实施的过程。较小的公司更多地依赖于每位员工成为变革的拥护者，这意味着你需要更多关注他们的反馈。

因此，与Lewin和麦肯锡的变革管理模式一样，Kotter应该补充其他方法（或者至少其中的一些元素来弥补其缺点。

译者补充说明

也只正如前言所说，DevOps的引入可以充分借鉴变革管理模型。这里给出一个案例，关于华为DevCloud团队如何实施大规模精益和DevOps的方法。从下图的对照可以看出（左边为Kotter的变革模型，右边为对应的华为具体变革实现流程）。对应上文的分析可以看出：

•Kottetr的模型适用于大范围的变革推动（对应华为DevCloud的大规模精益及DevOps转型）

•Kotter的模型是至上而下的（对应华为的年报和红头文件文件）

•Kotter的模型需要将成果融入文化（反过来说，华为的执行力文化也使得Kotter模型可以成功）