|
|
# 17｜新手上路，如何引入变化？
|
|
|
|
|
|
你好，我是雷蓓蓓。今天，我们来聊一聊新手上路，如何引入变化。
|
|
|
|
|
|
在留言区，我非常高兴地看到，很多同学已经开始动手实践了。而且，我还了解到，极客时间的研发同学，就把复盘会玩出了新高度，基于三点法创造了自己的复盘玩法。但是，还有一些同学在学习之后，产生了新的困惑：“我该怎么把这么多的好方法，引入到自己的团队中呢？”
|
|
|
|
|
|
其实，想要引入变化，你并不一定非要是项目经理，或者是有多么大的影响力。今天，我会给你介绍一些每个人都可以学得会的实用方法，帮助你更好地引入变化，尽可能地降低你在尝试过程中的碰壁概率。
|
|
|
|
|
|
新手上路，要想引入变化，简单说来，你需要“天时、地利、人和”。
|
|
|
|
|
|
## 天时：找准合适的时机
|
|
|
|
|
|
**首先是“天时”，也就是合适的时机**。时机或早或晚，都会让引入变化的阻力成倍放大。早了，大家还没意识到问题；晚了，他们又找到了可以将就的办法，逐渐形成了惯性，并视为理所当然。那到底什么时候才合适呢？我们先来看一段艾文的故事。
|
|
|
|
|
|
> 这是艾文升任项目经理后的第一个项目，眼看着距离版本发布的日期只剩两天了，任务系统上还显示着有好几项关键任务并没有完成。之前明明说是这两天就可以弄好的，到现在讨论了一个小时，最后敲定先用加缓存的方案来处理。可这么下来，再加上测试，两天肯定搞不定，这个版本想要做完恐怕是无望了。
|
|
|
|
|
|
> 整个团队似乎只有她一个人在意，目标是不是可以达成。老实说，在做项目经理的半年里，她经常感觉自己脑门上写着“监工”两个大字，非常着急，可又觉得无处使力，只能一个一个去催。这个困境到底要怎么破呢？
|
|
|
|
|
|
> 一个念头瞬间击中了她：“对了，每日站会！”艾文一个鲤鱼打挺从床上蹦了下来，连忙打开电脑，不过很快就又陷入了沉思。以现在的形势来看，跟团队提出要每天开会？艾文在想象着大家的反应，“开什么玩笑？活儿都干不完，为啥每天开会，安静写会儿代码不行吗？”
|
|
|
|
|
|
> 是啊，为啥呢，总不能跟大家说为了方便自己跟进问题吧，那样大家会买账才怪！艾文心想，这次，我得讲究“策略”。
|
|
|
|
|
|
好了，讲到这里，就要划重点了。很多同学都能看到自己项目组中存在这样那样的问题，但是问题太多了，一看到问题就想去改变，就想去整治，就觉得这是一个机会，**其实问题还并不等同于时机，你要把问题与痛点相关联，才能形成一个好的时机。**怎么关联？我们接着看故事进展。
|
|
|
|
|
|
> 高峰是这个部门的技术总监，当初就是他把艾文提拔到项目经理的位置上的。又到了每周一次的周会时间，高峰和艾文的问题总是特别得多，不知不觉两个小时过去了。直到预定的会议室到期，他们被撵了出来，状态还没有同步完。
|
|
|
|
|
|
> 会后，艾文叫住了高峰，直接跟他谈起了对目前境况的担忧：“现在我们每周开一次同步会，总感觉信息滞后得很。如果我们同步频率更高一点，就能够提早发现问题，现在也不至于又大费周章了。”高峰没有直接回应，对于艾文的建议也不置可否，在他看来信息同步的问题虽然有，但整体其实还好。
|
|
|
|
|
|
> 艾文猜到了高峰的心思，进一步说：“开发的问题倒还算好办，可是一旦涉及到其他角色、其他模块的支持，事儿就难办了。我们喊了很久要加强测试，加强运维，可也只是喊喊，喊完之后就没了下文。现在，我们产品的基本功能已经成型，质量和运维才是重中之重啊。”。“没错！”高峰坚定地说。可见，艾文的话一下子戳中了高峰的痛点。
|
|
|
|
|
|
这里，停下来敲黑板了。艾文第一次和高峰聊到信息同步滞后的问题，对方虽然也知道这里有些问题，可显然并没有什么改进的动力。
|
|
|
|
|
|
有同学给我留言说，自己跟老板反馈了一堆问题，老板虽然是认同的，但最后往往就没了下文。**其实，之所以不能产生改进动力，只能说明，你还没有抓准痛点。**
|
|
|
|
|
|
所谓痛点，简单地说，就是必须及时解决的问题，包含着强烈的迫切感。**判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼、很痛苦。**
|
|
|
|
|
|
就像艾文之所以在意这个问题，是因为这是她的痛点。作为项目经理，艾文迫切需要一个抓手，去实时跟进项目的动态。如果这个问题不解决，艾文就会非常痛苦。但是，状态更新不及时，这是艾文的痛点，却不是高峰的痛点。
|
|
|
|
|
|
真正让高峰苦恼和痛苦的，是整体团队的协同效率上还有很多问题，这个才是他真正的痛点。所以**要想促发别人的行动，你必须换位思考，去体会和抓住他的痛点**，这才可能一击即中。那么，怎样才能抓到痛点呢？我跟你分享几个方法。
|
|
|
|
|
|
1. 访谈法，也就是直接问。
|
|
|
|
|
|
我在第4讲干系人分析里，给出了针对不同干系人的问题列表，你可以参考。其中，最重要的问题是，“你认为项目组当前最大的风险和问题是什么？从你的角度出发，最迫切需要解决的是什么？”
|
|
|
|
|
|
2. 观察法。
|
|
|
|
|
|
实际上，与其看别人怎么说，不如看他怎么做。很多时候，人们会说这个很重要，但一两个星期下来，也没有投入任何精力，那么这就是个伪痛点。我跟你分享一个简单的方法，就是**去观察那些花他时间和精力最多、反复强调却又没很好解决的问题，那些才是真正的痛点**。
|
|
|
|
|
|
3. 同理心和倾听。
|
|
|
|
|
|
只有你用心倾听，设身处地去理解他人，你才能够准确地感知到他最大的痛点。需要注意的是，抓痛点的过程，并非一蹴而就，你需要多观察多了解，通过非正式的聊天，了解他们对潜在变化的态度，找到合适的契合点。
|
|
|
|
|
|
实际上，**在变革的早期，最重要的就是寻找到早期支持者**。围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了。由早期支持者形成的变革核心团队，就会成为你在推动变化过程中的重要支撑力量。
|
|
|
|
|
|
## 地利：学会因地制宜
|
|
|
|
|
|
好了，我们继续往下看故事。
|
|
|
|
|
|
> 艾文心想，终于等到机会了。于是，她把各角色一起每天开站会的想法，一股脑儿全倒了出来，双方顿时一拍即合。高峰觉得，这的确是个好办法。考虑到人数众多，他们又一起商议了许久，觉得还是有必要分两组来开站会。高峰说，“我们一开始要不还是两天一次，两个组错开进行吧？”艾文知道高峰在顾虑什么，连忙回说：“刚开始的确需要慎重些。”
|
|
|
|
|
|
到这里，我就要讲到**引入变化的第二点，所谓的“地利”，也就是你要学会因地制宜**。结合团队的实际情况，为团队定制适合的解决方案，而不是照搬理论或所谓的“最佳实践”。
|
|
|
|
|
|
在这个故事中，艾文与高峰决定分成两组开站会，每两天轮一次。实践中，你首先要去理解每个团队现有做法背后的历史原因和必要性，**结合每个项目团队的现状，做好本地化的场景适配**，这样才能获得好的效果。
|
|
|
|
|
|
因地制宜的适应性调整，并不是向环境妥协，而是**创造一个最小阻力的落地方法，快速跑起来，让团队感受到变化带来的闭环成效**！
|
|
|
|
|
|
## 人和：找到团队的共识
|
|
|
|
|
|
> 与高峰统一战线之后，艾文信心大增。于是，她立刻找来了几个测试，想聊聊看测试这边怎么分组好。几个人坐定后，艾文说道，“现在大家都坐得很近，但是团队中的沟通似乎并不是那么顺畅，我跟高峰商量着，考虑引入每日站会。”一句话还没说完，测试巴泰插话说：“我觉得现在的沟通挺顺畅的啊，有什么问题？”
|
|
|
|
|
|
> 高峰见状，赶紧出来打了个圆场，说：“咱们现在的沟通方式是有事就喊上两嗓子，快是快。可是很多事情喊过之后，经常就没下文了。”艾文接着说：“是啊，就比方说，开发改个Bug没改好，测试还等着去测，结果问了一次说在修，几天过去了还没动静，再一看，开发已经忘了这茬，做其他的去了。这个情况我想测试肯定碰到过，但我猜巴泰你也不好意思一次一次去问吧。”其他两个测试点头应和，说确实是有这个麻烦。
|
|
|
|
|
|
> 艾文继续说：“可是，我们如果每天站会，花15分钟互相同步下进展，问题就解决了。测试不需要跟着开发去催，每天站会时开发自己会讲我的进展，如果测试需要开发重新安排开发顺序，也容易多了。”看到巴泰若有所思的点头，艾文就知道测试这边已经ok了。接着艾文又找到运维同学，把站会的好处说了一遍，有了高峰和巴泰的支持，进行还算顺利。
|
|
|
|
|
|
这里，就要讲到，**引入变化的第三个关键点，也就是“人和”。**研究表明，企业变革失败的最常见因素就是人的阻力。面对一个变革，每个人都有与生俱来的情绪反应。这个情绪，是自动触发的，跟变革的大小无关。大到企业战略转型，小到仅仅是改变一个会议的方式，只要是引入变化，就会触发情绪反应，人们总是需要一个接受的过程。
|
|
|
|
|
|
那么，如何在引入变化的过程中，最大程度地创造出“人和”的局面，让大家更容易接受呢？**解法就是多聆听彼此，充分理解，找到共同的出发点**。
|
|
|
|
|
|
现实中，很可能你觉得是对的事情，不同人去看，会产生完全不同的看法。**在沟通时，你要因人而异，针对不同的人，你要采用不同的策略**。
|
|
|
|
|
|
那么，如何选用合适的沟通策略？
|
|
|
|
|
|
答案是，先判断立场！立场，是指人们在认识和处理问题时所站的位置**。**立场不同，看问题的视角就不同。
|
|
|
|
|
|
在具体操作时，你可以**把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同区域的人，会怎么看待这个变化带给他的影响**。你要做的就是，找出更多的积极因素，比如测试可以通过站会，更及时地获知和影响开发的进程等。同时，对于变化所带来的消极因素，提前引入相应的工具或方法来规避或改善。
|
|
|
|
|
|
除此之外，就算是立场一致的两个人，也会因为基本假设和价值观的不同，对同一件事有不同的解读，因而呈现出截然不同的态度。在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更加稳妥的做法。
|
|
|
|
|
|
看到这里，你可能会很好奇，艾文最后进展如何了？别着急，我们接着听故事。
|
|
|
|
|
|
> 又是一次例行周会，同步完状态之后，近两个小时已经过去了，屋里闷热得很，大家都有些焦躁，有人凑在一块开小会，有人低头玩手机。
|
|
|
|
|
|
> 艾文感叹道：“现在我们每次周会的时间好长啊，一转眼，两个小时就没了。”大家早已经开会开得有些生厌，经艾文这么一说，纷纷吐起了槽。
|
|
|
|
|
|
> 艾文示意高峰来说两句，于是，高峰就把早就讨论好的分组开站会的想法，讲了出来。
|
|
|
|
|
|
> 艾文接着补充说：“我们现在有15个人，开一次周会要花费所有人30个小时的时间（2小时\*15=30小时）。可如果按照刚才高峰的提议，每个人每周开两次站会，也就花30分钟，能给每个人节省一个半小时的时间！”
|
|
|
|
|
|
> 大家显然心有所动，有人笑着问道：“那以后的周会是不是也不要开了？”
|
|
|
|
|
|
> 艾文说：“以后每周五前，我会收集下大家的议题，如果有需要全员讨论的另行组织，没的话就默认不开啦！”看大家的一脸高兴劲，艾文知道已经大功告成了。
|
|
|
|
|
|
到这里，艾文的故事，就告一段落了。你看，由于经过多次提前沟通和铺垫，整个过程进行得非常顺利。
|
|
|
|
|
|
总体来说，在引入变化的过程中，**面向全员的正式公开沟通，一般会放在最后。**因为这时，关键问题和主要影响已经处理好了，路障也都清理干净了，变化自然就是水到渠成了。
|
|
|
|
|
|
其实，引入站会只是一个例子，无论你想引入什么变化，你都可以从以上三个要素，也就是天时、地利、人和，来一步步地进行分析和推进。
|
|
|
|
|
|
## **总结**
|
|
|
|
|
|
今天，通过艾文的故事，我为你呈现了新手项目经理在引入变化的过程中，最关键的三个因素：天时、地利、人和。**首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通。**
|
|
|
|
|
|
学了这么多的项目管理方法，如果你想成功引入团队，其实最难的部分，不是那些招数，而是招数背后你的发心。之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么。只有解决了大家的问题，这个变化才能最终被所有人打心底里接纳。
|
|
|
|
|
|
所有这一切的发生，必须建立在信任的基础上。这个信任不仅仅是对你能力的信任，更重要的是，**你是否能够站在对方角度设身处地思考问题**。当你是在真心为他着想，为他解决问题的时候，对方自然愿意接受你所带来的变化。
|
|
|
|
|
|
## **畅所欲言**
|
|
|
|
|
|
最后，如果你已经在尝试把我之前讲到的方法引入你的团队中，你遇到过什么困难吗？你有哪些需要支持或解答的困惑吗？还未投入实践的同学，有哪些顾虑阻止了你进一步尝试呢？
|
|
|
|
|
|
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章，分享给你的朋友。
|
|
|
|