前言: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