有效管理DevOps实施(二):麦肯锡7-S模型

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





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


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



未完待续~



- ./main end -->

Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1