CategoryResourceRepost/极客时间专栏/项目管理实战20讲/硬技能篇/13 | 故事案例（上）：新手上路，如何引入变化？.md

<audio id="audio" title="13 | 故事案例（上）：新手上路，如何引入变化？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e3/ad/e324a67006ea286cd6a3a0f40eee27ad.mp3"></audio>

你好，我是雷蓓蓓。今天，我们来聊一聊新手上路，如何引入变化。

在留言区，我非常高兴地看到，很多同学已经开始动手实践了。而且，我还了解到，极客时间的研发同学，就把复盘会玩出了新高度。

但是，很多同学在学习之后产生了新的困惑：“我该怎么把这么多的好方法，引入到自己的团队中呢？”

其实，想要引入变化，你并不一定非要是项目经理，或者是有多么大的影响力。今天，我会给你介绍一些每个人都可以学得会的实用方法，帮助你更好地引入变化，尽可能地降低你在尝试过程中的碰壁概率。

新手上路，要想引入变化，简单来说，你需要“天时、地利、人和”。

**首先是“天时”，也就是合适的时机**。时机或早或晚，都会让引入变化的阻力成倍放大。早了，大家还没意识到问题；晚了，他们又找到了可以将就的办法，逐渐形成了惯性，并视为理所当然。那到底什么时候才合适呢？我们先来看一段典型的故事案例。

> 
小云在半年前刚刚升任项目经理，他跟进的第二个项目，就遇到了麻烦。眼看着距离版本发布的日期只剩两天了，任务系统上还显示着有好几项关键任务并没有完成，之前明明说是这两天就可以弄好的。结果到现在，讨论了一个小时，最后才敲定先用加缓存的方案处理。可这么下来，再加上测试，两天肯定搞不定，要把这个版本做完，恐怕是无望了。


> 
在整个团队中，似乎只有小云一个人在意，目标是不是可以达成。老实说，在做项目经理的半年里，他经常感觉自己脑门上写着“监工”两个大字，非常着急，可又觉得无处使力，只能一个一个去催。那么，这个困境到底要怎么破呢？


> 
一个念头瞬间击中了他：“对了，开每日站会啊！”小云一个鲤鱼打挺，从床上蹦了下来，连忙打开电脑，却马上又陷入了沉思。


> 
以现在的形势来看，跟团队提出要每天开会？小云都可以想象到大家的反应：“开什么玩笑？活儿都干不完，为啥每天开会？安静写会儿代码不行吗？”


> 
是啊，现在缺的就是这个“为啥”，也就是why，可总不能跟大家说为了方便自己跟进问题吧，那样大家会买账才怪！小云心想，这次我得讲究“策略”。


好了，现在我要划重点了。

很多同学都觉得，自己的项目组中有着这样那样的问题，而且，问题简直太多了。于是呢，自己一看到问题就想去改变，就想去整治，就觉得这是一个机会。**实际上，问题并不等同于时机，只有把问题和痛点关联起来，才能形成一个好的时机**。

那么，怎么关联呢？我们接着来看故事进展。

> 
高峰是这个部门的技术总监，当初就是他把小云提拔到项目经理的位置上的。


> 
在每周一次的周会上，高峰和小云的问题特别得多，不知不觉两个小时就过去了。直到预定的会议室到期，他们被撵了出来，状态还没有同步完。


> 
会后，小云叫住了高峰，直接跟他谈起了自己对目前境况的担忧：“现在我们每周开一次同步会，总感觉信息滞后得很。如果我们的同步频率再高一点，就能够提早发现问题，现在也不至于大费周章了。”


> 
高峰没有直接回应，对于小云的建议也不置可否。在他看来，信息同步的问题虽然有，但整体其实还好。


> 
小云猜到了高峰的心思，进一步说：“如果只是开发的问题，倒还好办，可是一旦涉及到其他角色、其他模块的支持，事儿就难办了。我们喊了很久要加强测试，加强运维，可也只是喊喊，喊完之后就没了下文。现在，我们产品的基本功能已经成型，质量和运维才是重中之重啊。”。“没错！”高峰坚定地说。可见，小云的话一下子戳中了高峰的痛点。


讲到这里，我要停下来“敲黑板”了。小云第一次和高峰聊到信息同步滞后的问题，对方虽然也知道这里有问题，可显然并没有什么改进的动力。

有同学给我留言说，自己跟老板反馈了一堆问题，老板虽然是认同的，但最后往往就没了下文。

**其实，之所以不能产生改进动力，只能说明，你还没有抓准痛点。**

所谓痛点，简单地说，就是必须及时解决的问题，包含着强烈的迫切感。**判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼、很痛苦。**

小云之所以在意这个问题，是因为这是他的痛点。作为项目经理，小云迫切需要一个抓手，去实时跟进项目的动态，这个问题不解决，小云就会非常痛苦。状态更新不及时，的确是个问题，但这显然并不是高峰的痛点。

真正让高峰苦恼和痛苦的，不是开发状态更新不及时，而是在整体全局的高效协同上，还存在着很多问题，这个才是他真正的痛点。

**要想促发别人的行动，你必须换位思考，去体会和抓住他的痛点**，这才可能一击即中。那么，怎样才能抓到痛点呢？我跟你分享几个方法。

**1.访谈法，也就是直接问。**

我在[第4讲](https://time.geekbang.org/column/article/161108)中，给出了针对不同干系人的问题列表，你可以参考一下。其中，最重要的问题是，“你认为项目组当前最大的风险和问题是什么？从你的角度出发，最迫切需要解决的是什么？”

**2.观察法。**

实际上，与其看别人怎么说，不如看他怎么做。很多时候，人们会说这个很重要，但是一两个星期过去了，他也没有投入任何精力，那么这就是个“伪痛点”。这里有一个简单的方法，就是**去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他真正的痛点**。

**3.同理心和倾听。**

只有你用心倾听，设身处地去理解他人，你才能够准确地感知到他最大的痛点。需要注意的是，抓痛点的过程，并不是一蹴而就的，你需要多观察、多了解，通过非正式的聊天，了解他们对潜在变化的态度，找到合适的契合点。

实际上，**在变革的早期，最重要的就是寻找到早期支持者**。**围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了**。由早期支持者形成的变革核心团队，就会成为你在推动变化过程中的重要支撑力量。

好了，我们继续往下看故事。

> 
小云心想，终于等到机会了。于是，他把各个角色一起每天开站会的想法，一股脑儿地全告诉了高峰，双方顿时一拍即合。


> 
高峰觉得，这的确是个好办法。考虑到人数众多，他们又一起商议了很久，觉得还是有必要分两组来开站会。


> 
高峰说：“要不我们一开始还是两天开一次，两个组错开进行吧？”小云知道高峰在顾虑什么，连忙回说：“刚开始的确需要慎重些。”


到这里，我就要讲到**引入变化的第二点“地利”，也就是说，你要学会因地制宜**，结合团队的实际情况，为团队定制适合的解决方案，而不是照搬理论或所谓的“最佳实践”。

在这个故事中，小云与高峰决定分成两组开站会，每两天轮一次。实践中，你首先要去理解每个团队现有做法背后的历史原因和必要性，**结合每个项目团队的现状，做好本地化的场景适配**，这样才能获得好的效果。

因地制宜的适应性调整，并不是向环境妥协，而是**创造一个最小阻力的落地方法，先快速地跑起来，让团队感受到变化带来的闭环成效**！

> 
与高峰统一战线之后，小云信心大增。于是，他立刻找来了几个测试，想聊聊看测试这边怎么分组好。几个人坐定后，小云说道：“现在大家都坐得很近，但是团队之间的沟通似乎并不是那么顺畅，我跟高峰商量着，想要引入每日站会。”一句话还没说完，测试巴泰插话说：“我觉得现在的沟通挺顺畅的啊，有什么问题？”


> 
高峰见状，赶紧出来打了个圆场，说：“咱们现在的沟通方式是有事就喊上两嗓子，快是快，可是很多事情喊过之后，经常就没下文了。”


> 
小云接着说：“是啊，就比方说，开发改个Bug没改好，测试等着去测，只好去问开发，开发说正在修，但几天过去了还没动静。再一看，开发已经忘了这茬儿，做其他的去了。这种情况，我想测试肯定碰到过，但我猜，巴泰你也不好意思一次次地去问吧。”


> 
其他两个测试点头应和，说确实是有这个麻烦。


> 
小云继续说：“可是，如果我们每天开站会，花15分钟互相同步下进展，问题很容易就解决了。测试不需要再去找开发催进度了，因为每天开站会的时候，开发自己就会讲进展。如果测试需要开发重新安排开发顺序，也容易多了。”看到巴泰若有所思地点着头，小云就知道，测试这边已经ok了。


> 
接着小云又找到运维同学，把站会的好处说了一遍，有了高峰和巴泰的支持，进行得还算顺利。


现在，我就要讲到**引入变化的第三个关键点了，也就是“人和”**。

研究表明，企业变革失败的最常见因素就是人的阻力。面对变革，每个人都有与生俱来的情绪反应。这个情绪，是自动触发的，跟变革的大小无关。大到企业战略转型，小到仅仅是改变一个会议的方式，只要是引入变化，就会触发情绪反应，人们总是需要一个接受的过程。

那么，如何在引入变化的过程中，最大程度地创造出“人和”的局面，让大家更容易接受呢？**解法就是多聆听彼此，充分理解，找到共同的出发点**。

现实中，很可能你觉得是对的事情，不同人去看，会产生完全不同的看法。**在沟通时，你要因人而异，针对不同的人，采用不同的策略**。

那么，如何选用合适的沟通策略？

答案是，先判断立场！**立场，是指人们在认识和处理问题时所站的位置。立场不同，看问题的视角就不同**。

在具体操作时，你可以**把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同区域的人，会怎么看待这个变化带给他的影响**。

你要做的就是，**找出更多的积极因素**。比如，通过开站会，测试可以更及时地获知和影响开发的进程，这对于测试来说，就是一个积极因素。同时，对于变化所带来的消极因素，你要提前引入相应的工具或方法来规避或改善。

除此之外，就算是立场一致的两个人，也会因为基本假设和价值观的不同，对同一件事有不同的解读，从而呈现出截然不同的态度。

**所以，在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更稳妥的做法。**

看到这里，你可能会很好奇，故事中的小云进展如何了？别着急，我们一起接着看故事。

> 
这天，又是一次例行周会。同步完状态之后，近两个小时已经过去了，屋里闷热得很，大家都有些焦躁，有人凑在一块儿开小会，有人低头玩手机。


> 
小云感叹道：“现在我们每次周会的时间好长啊，一转眼，两个小时就没了。”大家早已经开会开得有些生厌，经小云这么一说，纷纷吐起了槽。


> 
小云示意高峰来说两句，于是，高峰就把早就讨论好的分组开站会的想法，讲了出来。


> 
小云接着补充说：“我们现在有15个人，开一次周会要花费所有人30个小时的时间（2小时*15=30小时）。可如果按照刚才高峰的提议，每个人每周开两次站会，也就花30分钟，能给每个人节省一个半小时的时间！”


> 
大家显然心有所动，有人笑着问道：“那以后的周会是不是也不要开了？”


> 
小云说：“以后每周五前，我会收集下大家的议题，如果有需要全员讨论的，我就另行组织周会，没有的话，那就默认不开啦！”看大家的一脸高兴劲儿，小云就知道，这时已经大功告成了。


到这里，小云的故事，就告一段落了。你看，由于经过多次提前沟通和铺垫，整个过程进行得非常顺利。

总体来说，在引入变化的过程中，**面向全员的正式公开沟通，一般会放在最后**。因为这时，关键问题和主要影响已经处理好了，路障也都清理干净了，变化自然就是水到渠成的了。

其实，引入站会只是一个例子，无论你想引入什么变化，你都可以从以上三个要素，也就是天时、地利、人和，来一步步地进行分析和推进。

## 总结

今天，通过一个生动的故事案例，我为你呈现了新手项目经理在引入变化的过程中，最关键的三个因素：天时、地利、人和。**首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通**。

如果你想成功地把学到的那么多的项目管理方法引入团队，最难的其实不是那些招数，而是招数背后的你的发心。**之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么**。只有解决了大家的问题，这个变化才能最终被所有人打心底里接纳。

所有这一切的发生，必须建立在信任的基础上。这个信任不仅仅是对你能力的信任，更重要的是，**你是否能够站在对方的角度设身处地地思考问题**。当你是在真心为他着想，为他解决问题的时候，对方自然会愿意接受你所带来的变化。

## 畅所欲言

最后，如果你已经在尝试把我之前讲到的方法引入你的团队中了，你遇到过什么困难吗？你有什么需要解答的困惑或者支持吗？还没有投入实践的同学，有哪些顾虑阻止了你进一步尝试呢？

欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。