你好，我是许健。今天我们聊一聊变革管理这个话题。
一般进入一家公司后，我们都会被告知要拥抱变化。比如我加入eBay先去了搜索后端部门，后来搜索部门都调回了美国总部，我和同事们被调配到云计算部门，经理再次强调了要拥抱变化，于是我们就从头开始学云计算。也有不愿意学的人，最后就离开公司了。
后来我转岗做了经理，做着做着就发现遇到了瓶颈，想要做得更好却做不到，我慢慢地意识到我们需要变革，于是开始了从拥抱变化到发起变革的转变。
接下来，我就跟你聊聊发起变革的那些事儿。
拥抱变化：培养对变革的感觉
回看我当经理的经历，我刚转岗做一线经理时就只能看到IaaS Provisioning系统这一块，整天想的也就是要如何提高这块系统的可靠性。
那时我是一个执行者的角色，并不知道我们组织有什么问题，也没有想过要把这个产品做成什么样子，更别说对整个部门有什么长期规划了。
我举个例子给你说说我当时的状态，前面人才培养那一讲我提到过，领导找人做我的Mentor，我的Mentor就是Wilson。有一次Wilson问我：“许健，公司里那些组织变动的announcement邮件你看吗？”我说自己不看的，毕竟看也看不懂，很多邮件的内容感觉跟我也很远，所以都是直接送垃圾邮箱的。
Wilson却告诉我，他不但会看，而且还会试着理解这些组织变动背后的原因，有些变动甚至在发生之前Wilson就有预测，所以他会对比最后的announcement和自己预测的有什么不同，然后思考为什么不同。
总结一下Wilson提出的对比法，其实就是把实际发生的变革和自己推断的变革进行比较。做这个对比有什么作用呢？作用就是可以锻炼经理对组织变革的判断能力。
我意识到这个对比法后曾尝试练习，但因为没有足够的背景信息和当时积累不够，发生在身边的组织变革我也是后知后觉，这让我觉得自己对组织的变革敏感度还要提升。
那么问题来了，经理对变革的敏感度到底该怎么培养呢？除了对比，我发现细致地做推演更重要，这个灵感也是多年之后，我成了二线经理才体会到的。
在这里我给你总结一个三步推演法：
首先，经理要能够看得到组织的问题。
其次，要分析组织要怎么安排才能增加解决这个问题的成功率。
最后一步，评估问题解决的收益和组织变动需要付出的代价，然后想一想这个代价可以接受吗？
经常思考上面的问题，我们就能慢慢培养出对组织变革的敏感度了。用上这个推演思路后，再结合Wilson的对比法，我发现自己的判断也越来越准确了。
记得我们公司新的首席产品官推出了一系列CPS（Customer Problem Statement），也就是一系列重要的客户不满意的问题，并且对整个产品部门提出了这样的要求，安排工作要围绕解决客户问题这个核心点进行。
我当时就想，接下来也许会按这个要求做组织重组了。后来发生的一系列的组织变动果然就是按照CPS来进行的。
要知道敏感度和判断力都来源于多观察，多思考。将来有一天如果轮到我们发起变革了，这些前期的积累会有很大帮助。
发起变革
在成为二线经理的初期，我们更多的是培养自己对变革的感觉，为自己更好地拥抱变革做积累。我们要主动关注领导是如何发起变革的，这样做自己也能逐渐发现组织的问题。
思考了很多，没有实际操练还是火候不到，那什么情况下二线经理自己要主动做变革呢？
如果有个问题严重到影响你的团队效率，但是又没有人站出来解决，这时我们就应该主动发起变革了。那么发起变革又有哪些关键事项呢，下面我就通过案例给你详细说一说。
案例背景
时间回到2014年，当时我团队有16人，分成4个小组，每一个小组都跟美国一个团队对应。其中我直接负责的只有一个做云计算内部监控的小组，其余三个小组的所有工作都是美国的经理直接安排的，说白了我就是一个人事经理罢了。
当时我们公司云计算平台C3主要是在OpenStack上，客户因为平台不稳定很不满意。于是我就动了组织变革的念头，想集中上海这16人的力量来提高C3稳定性。
推演思路如何落地
现在我们对照前面提到的组织变革三步推演法，实际分析一下这个案例。
首先是找到关键问题。我找到的关键问题是：云计算这个组织的最主要产品是云计算平台C3，但是客户对C3的稳定性很不满意。
为什么这样判断呢？我去参加总经理的Offsite，一堆同事群起而攻之，指着鼻子说云计算部门不解决客户问题。我相信总部那里的客服反馈也差不多，总部云计算平台的一把手也深知这一点，但是当前组织的大部分力量都在做什么？他们都在做新功能而不是修复现有系统的稳定性问题。
所以，我觉得必须要把现在云计算平台的业务质量提高，而这里最大的痛点就是解决C3的稳定性问题。
接下来是推演解决方案。找到关键问题以后，推演解决方案就很顺畅了。有个故事我推荐你看一看，就是马云曾经停掉支付宝的所有新功能，强制要求整个支付宝公司做变革，目标是把支付成功率从70%提升到90%。
本质上我这里的变革思路跟支付宝提高成功率是一样的。解决方案很直接，就是把组织的骨干力量从新功能上撤出，转到解决客户当前关心的主要问题上。
最后一步是评估投入产出。想要做成这件事要付出什么样的代价呢？就是一旦我们抽调一个骨干，那个骨干所在的新功能就会受影响，连带着负责那个新功能的经理就会受影响。
那大面积影响美国团队和大面积影响中国团队，这两个方向总部领导会做何选择？我的判断是总部领导会选择让中国团队做组织变革，虽然这个变革要付出代价，但也是中国的云计算负责人希望的。
总结一下，我愿意跳出来解决总部领导当前很头痛的问题，而且总部领导付出的代价可控，所以发起这个变革的可能性很高。如果能做好，上海的团队将不再是一盘散沙，我也不再是人事经理。所以，我决定主动发起这个变革。
确定了要变革，具体怎么做呢？这里有两个关键事项，一个是向变革涉及到的关键人物讲清楚我的想法，另一个是说服上级领导支持变革。
正面冲突，把话当面讲清楚
我想集中力量搞稳定性，就要完全停掉经理T在上海的原有安排，所以我申请去美国出差找T沟通。在美国见到T后，T希望我不要改变他的原定计划，我当时拉不下脸直接拒绝，并没有把话当面讲清楚。我只记得当时说，好吧，我再考虑考虑。
其他经理对变革的态度基本上是中立的，他们认同我要做的是正确的事情，同时又觉得原来计划的工作也很重要。在我飞回上海的路上，我觉得出这趟差什么也没有做成，白白费了公司几万元差旅费。
没过几周，总部的负责人S来上海例行视察，这次我铆足了劲，态度坚决，有理有据，一定要达成变革目标。
具体怎么说服S的我会在后面细讲，这里先说结果。S在上海待了一周，周五晚上飞回了美国，下周的周一就直接宣布了变革决定。
因为我出差时没有和经理T明说，他的理解是这件事儿我们还在谈，结果T突然收到领导这样的通知，自然很不高兴。T经理非常生气，他觉得我不把话当面说清楚，背后使绊子。
当时我的情绪管理做得也不够成熟，S宣布决定后我跟T打电话情绪也比较激动，还记得T在Skype上跟我说“Jian，watch your mouth！”过了一年多，我和T的关系才缓和。
回顾看我跟T交互的过程，我总结了两点经验：
- 在美国的时候，我其实完全可以当面跟T讲清楚我的想法，我就是为了集中力量把可靠性搞好。那为了做成这件事，我需要停掉你原来的工作安排。T也是讲道理的人，他后来对我这么生气，症结就是我没有在他面前把话说明白。
- 我讲清楚我的想法以后，我期望得到T的支持这一点，其实可以和他明确表达出来。
若干年后我已经负责带领更大的团队了，摩擦总会有的。我跟总部云计算高级总监有一次推心置腹的沟通，他也跟我提出来我们可以持不同意见，但是应该互相把想法讲清楚。大家都没有私心，没有什么不可以摆在台面上的，要么不说，要说就说得彻底。
如何说服上级领导支持变革
故事要回到S在上海的那一周，那时我做了什么呢？其实就是把变革的三个问题回答好。哪三个问题呢，我们一起看看：
第一，问题非解决不可吗？也就是解决Cloud Reliability这个问题，是不是S眼中的重点问题？只有重点问题，领导才会为了解决它而支持你发起变革，哪怕要影响总部各个经理的原定计划。
我们当时云计算部门自己的报表显示稳定性在99%，但是客户不买账，说给我们的服务发请求失败频率很高，发十次请求失败七八次，甚至有一个客户给副总写邮件列举了云计算七宗罪。我判断S面对客户也承受着很大压力，问题再不解决，S有可能位子不保。
第二， 解决问题具体怎么做？我给S做了详细分析，把做成Cloud Reliability这件事要解决掉的几大问题逐条列出来。
我们要解决RabbitMQ消息中间件的稳定性问题，要提供能反映用户体验的指标，还要解决虚拟机启动时网络配置问题……每一条都我列得都很具体，这样领导才知道，我提起这个变革是经过深思熟虑的。
第三， 为什么解决这个问题要交给我来做？最后这一步很重要但却很容易忽视，就算是你提了方案，为什么领导要把这个方案交给你来执行呢？
我们始终要记得领导最最关心的就是结果，所以必须向领导阐述解决第二步里的问题需要什么样的人才配置，说明我们就拥有这些人才配置，所以我们才是他手下最有可能办成这件事的人。
因为解决了前面说的这三个问题，我才说服了领导支持变革提议。我觉得重要项目需要领导真正的支持，而不仅仅是口头支持。
那么如此重要的事情，我们有哪些具体的事项需要领导帮忙呢，我和领导S提了下面3个要求：
- 需要请S来宣布变革决定，也就是美国总部那里原定计划变更，上海将集中力量改进Cloud Reliability。
- 我请S请上海的骨干一起吃饭，当面告诉他们这件事对组织的意义，激励这些骨干。我私下跟S说如果事情做成了，希望对这些骨干在年底绩效考评的时候有所体现。
- 需要领导提供人员上的支持，我们毕竟远在上海，我需要总部安排一个项目经理来帮忙协调上海对总部的需求。我还希望美国总部技术实力最强的经理D参与进来，在必要时提供技术支持。
上面说的支持需求，S全部答应了。我现在经常对我的部下说，如果我决定让你改变原计划去做一件我认为很重要的事情，你要是对我一点要求都不提，我会觉得不安，所以发起变革时，我们需要上级给什么支持，一定要提出来。
发起变革后的前三个月
变革启动后的前三个月是关键期，变革是打破原有的方式，前期拖得太长，容易出变故。所以我们需要在前三个月有产出，才能增强所有人对变革的信心。
接下来我们就聊聊在Cloud Reliability Program（后面简称CRP）那次变革的前三个月，我是怎么做的。
第一，前三个月的执行必须亲自指挥。
作为二线经理，可以把执行交给一线经理，但是在这段时间，我们的主要精力必须专注在变革的执行上。我当时做了详细的分工：
- 两个人做监控分析工作。B负责监控量化我们的稳定性指标，这样到底稳定性提高了多少大家一目了然。X负责对现有客户反馈的问题一个一个分析。
- 四个人处理已知问题。J负责攻克最棘手的消息中间件不稳定的问题，G负责数据库的稳定性，H负责网络问题，Y 负责虚拟机镜像问题。
- 我们每天都要自己过一下进度，因为X那边要分析的问题量比较大，我就和他一起做分析。
第二，早做推演，找到可能导致这三个月既定计划无法实现的风险点，及早做出部署。
换句话说，就是如果三个月后变革失败了，会是因为三个月前没做好哪些工作呢？不要以为艰难的决定在发起变革那一步就结束了，后续还有很多问题。
一个典型的问题就是对别人的依赖，注意这个时候把事情做出来，要比把事情做完美要重要，三个月内的目标一旦确定就不要轻易扩大，打移动靶多半会失败。
具体在CRP这件事上，当时我们最棘手的技术难题是消息中间件不稳定，所以一定是安排全组技术实力最强的人去解决。即使是这样，我们在前面近两个月都没有明显进展，压力很大。两个月过去后终于找到了问题，团队真的特别开心，信心也一下子起来了。
接下来又碰到了OpenStack升级，稳定性又跌下来，后来我跟美国的另一个经理D协商又停掉了一个项目，把另一个骨干也拉进来一起解决这个问题。
现在回顾OpenStack升级这件事，我发现这个风险点本该推演出来的，如果现在的我回到当年，就会坚持延后OpenStack升级，减少这个不确定因素。
第三，保持执行的完全透明。
每周给上级领导发工作汇报，每个月做月度汇报，有困难不要藏着掖着。我当时就是每周都向总部做进展汇报，我们和总部毕竟隔着个太平洋，而这次变革也是力排众议进行的，如果沟通不及时、不到位，就会造成总部领导不满，甚至对我们的信心动摇。
这种隐患在上海很难及时处理，所以我们请总部的一位华人来做项目经理，因为他跟我们信任度很高，所以找他负责跨洋沟通。这么安排是为了总部领导有任何问题都能得到及时解答。总部那边有什么情况，我们也可以通过这名项目经理及时了解，然后做出调整。
在整个变革过程，肯定会有困难，但是我们一定要给部下和上级展示出我们的坚定信念。如果真的出现问题，那就算砍功能也不要轻易改动原定交付时间，因为确定的交付时间对外就是一个承诺，而对内是一口气，这口气不能泻。在约定的时间内能准时交付，团队就会更加有信心。
总结
变革不易，从被动地接受变化到有能力主动发起变革，这是二线经理的一个重大进步。
我们要发起变革，首先要对于组织当前的重点问题有清晰的认识，平时就要培养对变革的敏感度，思考怎么通过组织变革进一步释放组织效率。
真正要发起变革肯定会影响到一些关键人员的利益，这时不要回避，摆在台面上讲清楚，给予相关人员足够的尊重。
说服领导的思路要围绕着“怎样做才能最大可能解决组织痛点”来构建。关键是和领导沟通好三个内容：这个问题非解决不可吗？解决问题的具体方案？为什么这个变革要交给我来做？
发起变革一定要获取上级领导的支持，这个支持不只是口头的，有关具体事项的需求也要提出来。
请你注意，发起一次变革只是起点，变革的关键期在启动后的前三个月，二线经理必须在这个期间亲自上阵指挥，专注于变革的执行，做详细分工，并根据推演到的风险点早做部署。
对变革管理有兴趣的同学，我强烈推荐你学习一下中国历史上的变法，体会这些变法成败背后的原因。
思考题
后来我又做了开发部门和运维部门的整合，开发部门觉得运维部门不思进取，而运维部门觉得开发部门也有问题，问题有两个：因为启动的新项目并不真正解决线上的实际问题，做事老是缺少最后一公里，这个欠缺还是要运维部门去填。
- 如果你是我，准备怎么来做这两个部门的整合工作呢？
- 如果你是开发部门或者运维部门的一员，你又准备做些什么？
欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。
精选留言
2020-09-24 08:38:46
我比较好奇的是，上述变革发生后，被你影响的经理T，你是如何缓和了关系的？如果是国内企业，这次改革也许不会那么顺利，他也不会轻易放过这件事情吧…
2021-02-03 03:06:00
我是一位在美国工作的技术管理者，我们公司刚刚开始尝试越洋在咱们国内建立研发中心。我们现在国内的员工都是70多名技术人员，按您今天的说法，我非常像这些人的“人事经理“，大部分时间就是优化优化内部流程，人员分配，请假休假。因为人和项目都比较多，我没有办法深度的跟踪每一个项目的进度，所以现在的方向是国内的开发人员日常工作深度整合到美区的产品组。我想请教您的有三件事，
1. 这种人事经理的职业规划是不是有很大的瓶颈？
2.您在ebay的上海团队如何做到美区出现事故，团队第一时间抢修的，要24小时值班吗？
3.您在国内的开发团队，他们的英语如何，能直接对接到美区的项目组吗？如果不能，您是怎么解决语言问题的？
2020-10-18 20:18:59
2020-09-23 21:43:09
这样也能让双方增加了解，促进团队合作。
2020-10-07 16:59:48
2020-09-18 08:57:16
2020-11-08 10:41:38
如果你是我，准备怎么来做这两个部门的整合工作呢？
如果你是开发部门或者运维部门的一员，你又准备做些什么？
关于思考题，我的想法是这样的
既然开发认为运维有问题，运维认为开发有问题，那就让他们之间互相轮岗，即从开发部门抽一部分人去运维部门，去亲身体验运维部门的一些难处，有些架构团队或运维团队每天面对各个业务线的问题的狂轰乱炸，有时也挺烦的，有句玩笑话是"架构部或运维部好像客服，不断给业务线的开发解答疑问"
同样，也从运维部门调一些人员去开发团队，体验运维系统的一些不足
我想他们站在对方的角度体验过了，应该就懂彼此的难处了，整合起来会容易些
作为其中的一员，对于整合就是拥抱这个变化，做好自己该做的就好啦
2020-09-18 22:56:41
单独询问开发部门：运维部门哪儿有问题，然后再找开发部门确认情况。
根据反馈得出方案，最后大家开一个会议沟通存在的问题，做到分工明确，如果有些事无法清楚划分给哪个部门，就找一个人专门来协调这块。
请问老师文中说的“人事经理”是贬义词吗？具体的定义是啥呀。
2023-02-25 09:19:46
2020-09-19 22:56:39