前言：DevOps实施本质上就是一种变革管理。上一篇文章介绍了第一个变革管理模型 -- Lewin模型。Lewin模型适用于业务需要深入的分析和改进的变革。本文是系列的第2篇（共8篇），阐述了麦肯锡的7-S模型。个人觉得7-S模型对于想快速引入DevOps并要求立马见效的企业是一剂清醒剂，尤其当企业认为实施DevOps就是要引入一套工具平台时。另外，DevOps确实涉及到了模型里所有的7个方面，非常值得借鉴 -- 不管你是企业DevOps转型负责人，还是咨询顾问。本文原作者Ben Mulholland，英文原文请点击文章底部"原文链接"。

麦肯锡7-S模型

麦肯锡的7-S模型并非为深度分析和重大转型而设计，但非常适合分析公司内在的一致性和耦合性。如果你知道某些方面需要改变，但是不确定要做什么，那么这就是适合你的变革管理模型。

通过分析公司的以下七个方面，以及它们是如何相互影响的，你将能够发现那些需要做出的改变，以创建一个统一的业务方法:

◦策略（Strategy）

◦架构（Structure）

◦系统（System）

◦共同的价值观（Shared Value）

◦风格（Style）

◦工作人员（Staff）

◦技能（Skills）

方法解读

变革管理模式——麦肯锡7s模型

评估策略（Strategy）

你的公司策略需要足够正式，能够让你有目标地前进以获得（或保持）相对于竞争对手的优势；同时也要足够灵活，能够适应变化而不会破坏你的进步。因此，在评估你的策略时，你需要回答以下问题:

•你的目标是什么?

•你实现这些目标的策略是什么?

•你如何保持竞争力?

•你的策略如何适应当前（和未来）的形势?

记录下每个问题的答案（以及你能想到的任何其他答案），然后继续。

许峰：在DevOps的上下文里，我们需要考虑组织的软件交付和运维能力（DevOps的核心价值）对于公司的策略意味什么？换句话说，IT能力对于你的企业时间战略目标有多重要？当你的企业不以IT能力为核心竞争力时，自建DevOps能力可能不是你的第一选择。

审视组织架构（Structure）

你的组织架构应该是很容易画出来的，因为它比策略更具体，但是与你的团队一起再次审视它还是很重要的。除非这些信息能准确地反映公司的实际架构，否则你只会使变革的有效性被削弱。

问问自己:

•你的公司是如何组织的（部门、团队等）?

•层级制度是怎么样的?

•部门是如何组织和管理的?

•团队是如何组织和管理的?

•团队成员是如何组织自己的?

•谁来做决定?

•决定是如何被传递下来的?

•每个人如何沟通?

•沟通发生的频率是怎样的?

许峰：在DevOps的上下文里，我们需要考虑组织架构。这里经常有人会问，做DevOps是否意味着组织架构一定要改？如果我们现有的架构无法改变，是否意味着不能做DevOps？显然，这里的问题是如何使得架构（比如虚拟团队）更利于共享知识，打破部门墙，共担责任。没有哪种类型的组织架构是必须的才能采纳DevOps。你需要评估它的有效性，再决定是否是制约演进的核心约束。

分析系统（System）

我们的任何一位老读者都知道拥有流程并有效管理流程的重要性，现在麦肯锡模型应用了同样的理念。在这里，你需要评估你的业务系统，包括官方流程、非官方快捷方式、规则以及如何跟踪所有内容。

换句话说，问问自己:•

你的业务核心系统（人力资源、财务、文档管理、团队管理/会议等）是什么?

•这些系统和/或过程是如何存储和使用的?

•它们是如何更新的（以及它们是最新的吗）?

•这些系统准确吗（它们是被逐字逐句使用的吗）?

•你如何跟踪和评估这些过程的结果?

•谁有权访问这些系统?

许峰：在DevOps的上下文里，系统更多的指我们用到的工具+流程。这是大多数技术人员或者IT部门最关心的部分。同样，建议采用价值流图来分析你现在的流程有效性。同时设计需要改进（比如，在工具支撑下的自动化）的部分，在有度量的情况下迭代改进。不理解问题的情况下上马工具失败的风险很高。

记录共享的价值观（Shared Value）

我们现在回到抽象领域，因为下一步是分析你们共有的价值观。这通常包括官方的公司价值观和公司（也可能包括个体团队）的文化。

虽然文化似乎与管理变革无关，但如果使用得当，它确实可以成为一个强大的工具。把价值观和文化与要进行的变革联系起来，会使员工对变革的接受度更高，也会进一步帮助员工主动投身变革。

看一看:

•你的公司核心价值观是什么?

•你的公司文化是什么?

•你的团队的文化是什么?

•团队文化与公司文化一致吗?

•你的价值观有多牢固?

•你如何在实践中加强它们?

许峰：很难想象一个不团结的足球队能持续赢得比赛。同样，DevOps鼓励分享、不追责、同理心、持续学习等文化，如果企业忽视这些，DevOps的“成功”（比如引入一套工具平台）只能是昙花一现。对于DevOps咨询师/教练来讲，这往往是最难改变客户的部分。

理解管理风格（Style）

这个阶段是主要是评估在业务中使用的管理和领导风格。尽管把自己的领导力做一个理想化的描述很诱人，但要抵制这种冲动并坦诚地说出你和公司其他人是如何管理他人的。

你需要问的问题是:•

你的部门和团队是如何管理的?

•这种管理/领导力有多活跃?

•这种风格有效吗?在多大程度上有效?

•这种风格更鼓励竞争还是合作?

许峰：领导者亲自参与变革是至关重要的。领导者的风格对于变革能发成功影响巨大，DevOps的实施也概莫能外。没有领导支持的DevOps，可以洗洗睡了。

列出人员（Staff）

这部分正如你所期望的那样：查看一下员工名单，评估一下是否所需的职位已经被填补了，还有哪些空缺，等等。

看一看你的员工名单，他们的工作描述，常见的工作任务，以及总的技能。•

哪些工作职位已经招到人了?

•这些员工为你的公司带来什么技能?

•团队是否缺乏特定的技能?

•你还需要招聘吗?

•如果是的话，你的下一次聘用会是谁?

许峰：做DevOps需要正确经验和技能的人。你不太能变出一个有经验的人。如果你的团队只会手工测试，你可能真的需要招些自动化测试的专业人员。

评估员工的技能（Skills）

最后，是时候看看你的员工目前拥有的技能了。这不应该止于一个泛泛的描述——你需要收集一些关于你的公司被如何看待的反馈，因为这会让你了解客户眼中你公司的技能如何（这可能同样重要）。

看一看:

•你的员工是否具备必要的技能，使他们的工作达到预期的质量?

•你的公司缺少什么技能?

•这些缺失的技能有多重要?

•你的公司/团队中最强大的技能是什么?

•你是如何评估这些技能的?

•你的公司哪些方面被认为做得好，通过这些反映出了什么技能?

许峰：不想在团队培训上投入，害怕让团队试错，不希望“浪费”时间磨练员工能力，只希望发出一个指令，或找一个咨询团队来“搞定”DevOps -- 那只能是“Good luck！”了。

交叉检查7-S，找出你需要实现的变更一旦你分析了所有的7-S，你就应该花时间去思考它们是如何相互影响的。与许多其他的变革管理模型一样，至少需要与管理层的高层会面才能做到这一点，并且你将在实践中更准确地了解这些方面。

你需要看看你的7-S是否互相支持，如果还没有的话，你需要计划一些渐进的更改以实现此目标。例如，查看架构是否支持你的策略，系统又是如何帮助这两者的，以及这三方面如何反映在共享价值观上的。一旦你知道了需要做些什么，你就可以计划一些渐进的改变，这些改变不会过多地扰乱你的日常运营，也不会疏离你的员工。在改变被实施之后（或者甚至在你进行每一次更改之后），再次检查7-S模型，重新评估并找出下一步需要做什么。

麦肯锡7-S模型

许峰：说到重点了 -- 看看这7个方面，想想你目前最大的问题到底是什么。很可能你当下最需要解决的问题不是工具的问题。你愿意直面你最重要的（但可能不易改变的）部分吗？重要的是：认清什么是关键绩效制约因素。不要试图用DevOps解决并不属于它的问题。

优点

7-S模型显示了公司的不足之处，并突出了部署变更时最需要注意的领域。除此之外，确保公司的各个方面都支持其他方面也会有所帮助，从而为你提供一个强大的业务计划，同时这个计划又非常灵活，可以适应更进一步的改变。

不足

除非你正在经营一家只有少数员工的小公司，否则麦肯锡的模式无法单独或在短时间内有效实施。你可能没有足够的知识来评估公司的每个要素，因此必须投入额外的时间和资源来构建总体评价并估算可行的变更。

结论

麦肯锡7-S模式最适合那些想知道如何才能变得更好的公司。对公司各个要素的一致性和有效性进行总体评价后，可以进一步分析你的当前情况，并起草变更以解决问题。

换句话说，如果你不知道从哪里开始，这个模型是很好的，但是如果你只是想评估一个特定变更的可行性，那么最好使用一个范围更小的模型。

许峰：在开始DevOps之前请认真审视你组织的这7个方面。对于咨询师来讲，这可能给了你有用的提示：你该帮助客户解决的问题到底应该聚焦在哪里。请不要上来就给客户来一套“行业最佳实践”。