前言：DevOps实施本质上就是一种变革管理。上一篇文章介绍了第一个变革管理模型 -- Lewin模型。Lewin模型适用于业务需要深入的分析和改进的变革。本文是系列的第2篇（共8篇），阐述了麦肯锡的7-S模型。个人觉得7-S模型对于想快速引入DevOps并要求立马见效的企业是一剂清醒剂，尤其当企业认为实施DevOps就是要引入一套工具平台时。另外，DevOps确实涉及到了模型里所有的7个方面，非常值得借鉴 -- 不管你是企业DevOps转型负责人，还是咨询顾问。
麦肯锡的7-S模型并非为深度分析和重大转型而设计，但非常适合分析公司内在的一致性和耦合性。如果你知道某些方面需要改变，但是不确定要做什么，那么这就是适合你的变革管理模型。 通过分析公司的以下七个方面，以及它们是如何相互影响的，你将能够发现那些需要做出的改变，以创建一个统一的业务方法: 策略（Strategy） 架构（Structure） 系统（System） 共同的价值观（Shared Value） 风格（Style） 工作人员（Staff） 技能（Skills）
变革管理模式——麦肯锡7s模型
你的公司策略需要足够正式，能够让你有目标地前进以获得（或保持）相对于竞争对手的优势；同时也要足够灵活，能够适应变化而不会破坏你的进步。因此，在评估你的策略时，你需要回答以下问题: 你的目标是什么? 你实现这些目标的策略是什么? 你如何保持竞争力? 你的策略如何适应当前（和未来）的形势? 许峰：在DevOps的上下文里，我们需要考虑组织的软件交付和运维能力（DevOps的核心价值）对于公司的策略意味什么？换句话说，IT能力对于你的企业时间战略目标有多重要？当你的企业不以IT能力为核心竞争力时，自建DevOps能力可能不是你的第一选择。 变革管理模式-组织架构 你的公司是如何组织的（部门、团队等）? 层级制度是怎么样的? 部门是如何组织和管理的? 团队是如何组织和管理的? 团队成员是如何组织自己的? 谁来做决定? 决定是如何被传递下来的? 每个人如何沟通? 沟通发生的频率是怎样的? 许峰：在DevOps的上下文里，我们需要考虑组织架构。这里经常有人会问，做DevOps是否意味着组织架构一定要改？如果我们现有的架构无法改变，是否意味着不能做DevOps？显然，这里的问题是如何使得架构（比如虚拟团队）更利于共享知识，打破部门墙，共担责任。没有哪种类型的组织架构是必须的才能采纳DevOps。你需要评估它的有效性，再决定是否是制约演进的核心约束。 你的业务核心系统（人力资源、财务、文档管理、团队管理/会议等）是什么? 这些系统和/或过程是如何存储和使用的? 它们是如何更新的（以及它们是最新的吗）? 这些系统准确吗（它们是被逐字逐句使用的吗）? 你如何跟踪和评估这些过程的结果? 谁有权访问这些系统? 许峰：在DevOps的上下文里，系统更多的指我们用到的工具+流程。这是大多数技术人员或者IT部门最关心的部分。同样，建议采用价值流图来分析你现在的流程有效性。同时设计需要改进（比如，在工具支撑下的自动化）的部分，在有度量的情况下迭代改进。不理解问题的情况下上马工具失败的风险很高。 虽然文化似乎与管理变革无关，但如果使用得当，它确实可以成为一个强大的工具。把价值观和文化与要进行的变革联系起来，会使员工对变革的接受度更高，也会进一步帮助员工主动投身变革。 你的公司核心价值观是什么? 你的公司文化是什么? 你的团队的文化是什么? 团队文化与公司文化一致吗? 你的价值观有多牢固? 你如何在实践中加强它们? 许峰：很难想象一个不团结的足球队能持续赢得比赛。同样，DevOps鼓励分享、不追责、同理心、持续学习等文化，如果企业忽视这些，DevOps的“成功”（比如引入一套工具平台）只能是昙花一现。对于DevOps咨询师/教练来讲，这往往是最难改变客户的部分。
你的部门和团队是如何管理的? 这种管理/领导力有多活跃? 这种风格有效吗?在多大程度上有效? 这种风格更鼓励竞争还是合作? 许峰：领导者亲自参与变革是至关重要的。领导者的风格对于变革能发成功影响巨大，DevOps的实施也概莫能外。没有领导支持的DevOps，可以洗洗睡了。
哪些工作职位已经招到人了? 这些员工为你的公司带来什么技能? 团队是否缺乏特定的技能? 你还需要招聘吗? 如果是的话，你的下一次聘用会是谁? 许峰：做DevOps需要正确经验和技能的人。你不太能变出一个有经验的人。如果你的团队只会手工测试，你可能真的需要招些自动化测试的专业人员。
你的员工是否具备必要的技能，使他们的工作达到预期的质量? 你的公司缺少什么技能? 这些缺失的技能有多重要? 你的公司/团队中最强大的技能是什么? 你是如何评估这些技能的? 你的公司哪些方面被认为做得好，通过这些反映出了什么技能? 许峰：不想在团队培训上投入，害怕让团队试错，不希望“浪费”时间磨练员工能力，只希望发出一个指令，或找一个咨询团队来“搞定”DevOps -- 那只能是“Good luck！”了。 你需要看看你的7-S是否互相支持，如果还没有的话，你需要计划一些渐进的更改以实现此目标。例如，查看架构是否支持你的策略，系统又是如何帮助这两者的，以及这三方面如何反映在共享价值观上的。 一旦你知道了需要做些什么，你就可以计划一些渐进的改变，这些改变不会过多地扰乱你的日常运营，也不会疏离你的员工。在改变被实施之后（或者甚至在你进行每一次更改之后），再次检查7-S模型，重新评估并找出下一步需要做什么。 麦肯锡7-S模型 许峰：说到重点了 -- 看看这7个方面，想想你目前最大的问题到底是什么。很可能你当下最需要解决的问题不是工具的问题。你愿意直面你最重要的（但可能不易改变的）部分吗？重要的是：认清什么是关键绩效制约因素。不要试图用DevOps解决并不属于它的问题。 优点 7-S模型显示了公司的不足之处，并突出了部署变更时最需要注意的领域。除此之外，确保公司的各个方面都支持其他方面也会有所帮助，从而为你提供一个强大的业务计划，同时这个计划又非常灵活，可以适应更进一步的改变。 不足 除非你正在经营一家只有少数员工的小公司，否则麦肯锡的模式无法单独或在短时间内有效实施。你可能没有足够的知识来评估公司的每个要素，因此必须投入额外的时间和资源来构建总体评价并估算可行的变更。 结论 麦肯锡7-S模式最适合那些想知道如何才能变得更好的公司。对公司各个要素的一致性和有效性进行总体评价后，可以进一步分析你的当前情况，并起草变更以解决问题。 换句话说，如果你不知道从哪里开始，这个模型是很好的，但是如果你只是想评估一个特定变更的可行性，那么最好使用一个范围更小的模型。 未完待续~
Copyright © 2020 All Rights Reseverd Designed by 5thspace.net 备案号：沪ICP备15017019号-1