极客时间已完结课程限时免费阅读

17|新手上路,如何引入变化?

17|新手上路,如何引入变化?-极客时间

17|新手上路,如何引入变化?

讲述:雷蓓蓓

时长16:40大小15.22M

你好,我是雷蓓蓓。今天,我们来聊一聊新手上路,如何引入变化。
在留言区,我非常高兴地看到,很多同学已经开始动手实践了。而且,我还了解到,极客时间的研发同学,就把复盘会玩出了新高度,基于三点法创造了自己的复盘玩法。但是,还有一些同学在学习之后,产生了新的困惑:“我该怎么把这么多的好方法,引入到自己的团队中呢?”
其实,想要引入变化,你并不一定非要是项目经理,或者是有多么大的影响力。今天,我会给你介绍一些每个人都可以学得会的实用方法,帮助你更好地引入变化,尽可能地降低你在尝试过程中的碰壁概率。
新手上路,要想引入变化,简单说来,你需要“天时、地利、人和”。

天时:找准合适的时机

首先是“天时”,也就是合适的时机。时机或早或晚,都会让引入变化的阻力成倍放大。早了,大家还没意识到问题;晚了,他们又找到了可以将就的办法,逐渐形成了惯性,并视为理所当然。那到底什么时候才合适呢?我们先来看一段艾文的故事。
这是艾文升任项目经理后的第一个项目,眼看着距离版本发布的日期只剩两天了,任务系统上还显示着有好几项关键任务并没有完成。之前明明说是这两天就可以弄好的,到现在讨论了一个小时,最后敲定先用加缓存的方案来处理。可这么下来,再加上测试,两天肯定搞不定,这个版本想要做完恐怕是无望了。
整个团队似乎只有她一个人在意,目标是不是可以达成。老实说,在做项目经理的半年里,她经常感觉自己脑门上写着“监工”两个大字,非常着急,可又觉得无处使力,只能一个一个去催。这个困境到底要怎么破呢?
一个念头瞬间击中了她:“对了,每日站会!”艾文一个鲤鱼打挺从床上蹦了下来,连忙打开电脑,不过很快就又陷入了沉思。以现在的形势来看,跟团队提出要每天开会?艾文在想象着大家的反应,“开什么玩笑?活儿都干不完,为啥每天开会,安静写会儿代码不行吗?”
是啊,为啥呢,总不能跟大家说为了方便自己跟进问题吧,那样大家会买账才怪!艾文心想,这次,我得讲究“策略”。
好了,讲到这里,就要划重点了。很多同学都能看到自己项目组中存在这样那样的问题,但是问题太多了,一看到问题就想去改变,就想去整治,就觉得这是一个机会,其实问题还并不等同于时机,你要把问题与痛点相关联,才能形成一个好的时机。怎么关联?我们接着看故事进展。
高峰是这个部门的技术总监,当初就是他把艾文提拔到项目经理的位置上的。又到了每周一次的周会时间,高峰和艾文的问题总是特别得多,不知不觉两个小时过去了。直到预定的会议室到期,他们被撵了出来,状态还没有同步完。
会后,艾文叫住了高峰,直接跟他谈起了对目前境况的担忧:“现在我们每周开一次同步会,总感觉信息滞后得很。如果我们同步频率更高一点,就能够提早发现问题,现在也不至于又大费周章了。”高峰没有直接回应,对于艾文的建议也不置可否,在他看来信息同步的问题虽然有,但整体其实还好。
艾文猜到了高峰的心思,进一步说:“开发的问题倒还算好办,可是一旦涉及到其他角色、其他模块的支持,事儿就难办了。我们喊了很久要加强测试,加强运维,可也只是喊喊,喊完之后就没了下文。现在,我们产品的基本功能已经成型,质量和运维才是重中之重啊。”。“没错!”高峰坚定地说。可见,艾文的话一下子戳中了高峰的痛点。
这里,停下来敲黑板了。艾文第一次和高峰聊到信息同步滞后的问题,对方虽然也知道这里有些问题,可显然并没有什么改进的动力。
有同学给我留言说,自己跟老板反馈了一堆问题,老板虽然是认同的,但最后往往就没了下文。其实,之所以不能产生改进动力,只能说明,你还没有抓准痛点。
所谓痛点,简单地说,就是必须及时解决的问题,包含着强烈的迫切感。判断是否是痛点的标志,就是看这个问题,如果不解决,对方是否会很苦恼、很痛苦。
就像艾文之所以在意这个问题,是因为这是她的痛点。作为项目经理,艾文迫切需要一个抓手,去实时跟进项目的动态。如果这个问题不解决,艾文就会非常痛苦。但是,状态更新不及时,这是艾文的痛点,却不是高峰的痛点。
真正让高峰苦恼和痛苦的,是整体团队的协同效率上还有很多问题,这个才是他真正的痛点。所以要想促发别人的行动,你必须换位思考,去体会和抓住他的痛点,这才可能一击即中。那么,怎样才能抓到痛点呢?我跟你分享几个方法。
访谈法,也就是直接问。
我在第 4 讲干系人分析里,给出了针对不同干系人的问题列表,你可以参考。其中,最重要的问题是,“你认为项目组当前最大的风险和问题是什么?从你的角度出发,最迫切需要解决的是什么?”
观察法。
实际上,与其看别人怎么说,不如看他怎么做。很多时候,人们会说这个很重要,但一两个星期下来,也没有投入任何精力,那么这就是个伪痛点。我跟你分享一个简单的方法,就是去观察那些花他时间和精力最多、反复强调却又没很好解决的问题,那些才是真正的痛点
同理心和倾听。
只有你用心倾听,设身处地去理解他人,你才能够准确地感知到他最大的痛点。需要注意的是,抓痛点的过程,并非一蹴而就,你需要多观察多了解,通过非正式的聊天,了解他们对潜在变化的态度,找到合适的契合点。
实际上,在变革的早期,最重要的就是寻找到早期支持者。围绕着你想要引入的变化,击中几个重要干系人的痛点之后,这个时机就到了。由早期支持者形成的变革核心团队,就会成为你在推动变化过程中的重要支撑力量。

地利:学会因地制宜

好了,我们继续往下看故事。
艾文心想,终于等到机会了。于是,她把各角色一起每天开站会的想法,一股脑儿全倒了出来,双方顿时一拍即合。高峰觉得,这的确是个好办法。考虑到人数众多,他们又一起商议了许久,觉得还是有必要分两组来开站会。高峰说,“我们一开始要不还是两天一次,两个组错开进行吧?”艾文知道高峰在顾虑什么,连忙回说:“刚开始的确需要慎重些。”
到这里,我就要讲到引入变化的第二点,所谓的“地利”,也就是你要学会因地制宜。结合团队的实际情况,为团队定制适合的解决方案,而不是照搬理论或所谓的“最佳实践”。
在这个故事中,艾文与高峰决定分成两组开站会,每两天轮一次。实践中,你首先要去理解每个团队现有做法背后的历史原因和必要性,结合每个项目团队的现状,做好本地化的场景适配,这样才能获得好的效果。
因地制宜的适应性调整,并不是向环境妥协,而是创造一个最小阻力的落地方法,快速跑起来,让团队感受到变化带来的闭环成效

人和:找到团队的共识

与高峰统一战线之后,艾文信心大增。于是,她立刻找来了几个测试,想聊聊看测试这边怎么分组好。几个人坐定后,艾文说道,“现在大家都坐得很近,但是团队中的沟通似乎并不是那么顺畅,我跟高峰商量着,考虑引入每日站会。”一句话还没说完,测试巴泰插话说:“我觉得现在的沟通挺顺畅的啊,有什么问题?”
高峰见状,赶紧出来打了个圆场,说:“咱们现在的沟通方式是有事就喊上两嗓子,快是快。可是很多事情喊过之后,经常就没下文了。”艾文接着说:“是啊,就比方说,开发改个 Bug 没改好,测试还等着去测,结果问了一次说在修,几天过去了还没动静,再一看,开发已经忘了这茬,做其他的去了。这个情况我想测试肯定碰到过,但我猜巴泰你也不好意思一次一次去问吧。”其他两个测试点头应和,说确实是有这个麻烦。
艾文继续说:“可是,我们如果每天站会,花 15 分钟互相同步下进展,问题就解决了。测试不需要跟着开发去催,每天站会时开发自己会讲我的进展,如果测试需要开发重新安排开发顺序,也容易多了。”看到巴泰若有所思的点头,艾文就知道测试这边已经 ok 了。接着艾文又找到运维同学,把站会的好处说了一遍,有了高峰和巴泰的支持,进行还算顺利。
这里,就要讲到,引入变化的第三个关键点,也就是“人和”。研究表明,企业变革失败的最常见因素就是人的阻力。面对一个变革,每个人都有与生俱来的情绪反应。这个情绪,是自动触发的,跟变革的大小无关。大到企业战略转型,小到仅仅是改变一个会议的方式,只要是引入变化,就会触发情绪反应,人们总是需要一个接受的过程。
那么,如何在引入变化的过程中,最大程度地创造出“人和”的局面,让大家更容易接受呢?解法就是多聆听彼此,充分理解,找到共同的出发点
现实中,很可能你觉得是对的事情,不同人去看,会产生完全不同的看法。在沟通时,你要因人而异,针对不同的人,你要采用不同的策略
那么,如何选用合适的沟通策略?
答案是,先判断立场!立场,是指人们在认识和处理问题时所站的位置立场不同,看问题的视角就不同。
在具体操作时,你可以把变化涉及到的干系人,按照角色和层级做个初始划分,思考下不同区域的人,会怎么看待这个变化带给他的影响。你要做的就是,找出更多的积极因素,比如测试可以通过站会,更及时地获知和影响开发的进程等。同时,对于变化所带来的消极因素,提前引入相应的工具或方法来规避或改善。
除此之外,就算是立场一致的两个人,也会因为基本假设和价值观的不同,对同一件事有不同的解读,因而呈现出截然不同的态度。在大范围公布并引入变化之前,与关键角色进行一对一的沟通,是更加稳妥的做法。
看到这里,你可能会很好奇,艾文最后进展如何了?别着急,我们接着听故事。
又是一次例行周会,同步完状态之后,近两个小时已经过去了,屋里闷热得很,大家都有些焦躁,有人凑在一块开小会,有人低头玩手机。
艾文感叹道:“现在我们每次周会的时间好长啊,一转眼,两个小时就没了。”大家早已经开会开得有些生厌,经艾文这么一说,纷纷吐起了槽。
艾文示意高峰来说两句,于是,高峰就把早就讨论好的分组开站会的想法,讲了出来。
艾文接着补充说:“我们现在有 15 个人,开一次周会要花费所有人 30 个小时的时间(2 小时 *15=30 小时)。可如果按照刚才高峰的提议,每个人每周开两次站会,也就花 30 分钟,能给每个人节省一个半小时的时间!”
大家显然心有所动,有人笑着问道:“那以后的周会是不是也不要开了?”
艾文说:“以后每周五前,我会收集下大家的议题,如果有需要全员讨论的另行组织,没的话就默认不开啦!”看大家的一脸高兴劲,艾文知道已经大功告成了。
到这里,艾文的故事,就告一段落了。你看,由于经过多次提前沟通和铺垫,整个过程进行得非常顺利。
总体来说,在引入变化的过程中,面向全员的正式公开沟通,一般会放在最后。因为这时,关键问题和主要影响已经处理好了,路障也都清理干净了,变化自然就是水到渠成了。
其实,引入站会只是一个例子,无论你想引入什么变化,你都可以从以上三个要素,也就是天时、地利、人和,来一步步地进行分析和推进。

总结

今天,通过艾文的故事,我为你呈现了新手项目经理在引入变化的过程中,最关键的三个因素:天时、地利、人和。首先,你要选择合适的时机,然后,找到因地制宜的解决方案,最后因人而异,采用不同的策略进行有效沟通。
学了这么多的项目管理方法,如果你想成功引入团队,其实最难的部分,不是那些招数,而是招数背后你的发心。之所以要引入变化,不是因为你觉得这个方法好,解决了你的问题,而是要看团队需要的是什么,干系人的痛点是什么。只有解决了大家的问题,这个变化才能最终被所有人打心底里接纳。
所有这一切的发生,必须建立在信任的基础上。这个信任不仅仅是对你能力的信任,更重要的是,你是否能够站在对方角度设身处地思考问题。当你是在真心为他着想,为他解决问题的时候,对方自然愿意接受你所带来的变化。

畅所欲言

最后,如果你已经在尝试把我之前讲到的方法引入你的团队中,你遇到过什么困难吗?你有哪些需要支持或解答的困惑吗?还未投入实践的同学,有哪些顾虑阻止了你进一步尝试呢?
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章,分享给你的朋友。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 17

提建议

上一篇
16|学会对焦,从头到尾把事做成(下)
下一篇
18 | 小步快跑,小而美的敏捷
unpreview
 写留言

精选留言(17)

  • Raymond吕
    2019-12-24
    我一直觉得作为PM应该自始至终关注人,把自己看成一个服务者、大保姆,放低姿态。 开发转PM的同学往往会比较骄傲吧,总觉得自己什么都懂,看不惯很多事,比较容易下判断、给结论。 另外,一旦涉及到需要PM导入一些实践,变化带来的抵触情绪是必然的。这时候就需要找到一两个关键支持者,先让他们感知到对自己的收益,然后就是各种铺垫,找合适的项目或机会去试试看。 总之呢,除了少数几个场合,比如启动会上,尽量跟成员少谈愿景、理想,不要试图用情怀去感动他们;而是要多帮他们解决解决实际问题,告诉他们达成项目对他们自己的具体收益是什么。 记得,“小鬼”难缠,千万要侍候好关键的“小鬼”。
    展开

    作者回复: 看了这么多留言,赶脚你可以开专栏了,哈哈,加油! 坚持实践,坚持总结自己的心得,尝试输出,教是最好的学。

    共 2 条评论
    24
  • 小文同学
    2019-12-17
    在项目管理上,发现问题的时候不一定是改善问题的最好时机。这个是项目管理思维和技术编程思维非常不同的点,也是可能很多技术同学转管理会踩的坑。

    作者回复: 没错,非线性思维

    共 2 条评论
    19
  • quietwater
    2019-12-17
    帮助别人解决他们的痛点,其实就是项目经理,产品经理,或者团队领导最重要的事儿,没有之一。招聘人才是领导者最重要的事儿,比如招聘好的项目经理😀
    7
  • Cy23
    2019-11-27
    什么时候不会因为人的责任心的问题而苦恼就好了,感觉项目经理就是在哄孩子好好学习似的呢?

    作者回复: 相信我,责任心的事会一直存在。你说的很好,问题在于,什么时候你,不会再因此而苦恼,那就说明,你完成了“右手发球”到“左手发球”的能力跨越。

    共 3 条评论
    6
  • 当你的世界里有风吹过
    2020-12-20
    我觉得管理的核心是,为干系人建立安全感! 让他们毫无顾虑的往前冲!
    3
  • 陈怀哲
    2019-11-27
    引入一个变化,需要找到变化可能影响到的人,各个沟通击破,并根据沟通结果对计划作出一些妥协和调整,最后确认变化是可行的,再统一全员通知,执行。
    共 1 条评论
    3
  • leslie
    2019-11-26
    现在的Team看到了太多的问题,人很多时候都是听好话逆于难进真言难进,这大概是太多二三线企业经常的典型现状吧,之前在一线城市的一线企业这种现状还好,一个好的Team如果不能合理的去协调和管理以及用好团队成员其实是个很典型的问题。 这门课程是未雨绸缪的事情吧或者说为了明年所做的准备:经历过了好的和差的Team差距在哪里问题在哪里,通过理论去强化和补充自己的想法,来年用好在未来的Team里面,让自己的Team做成一个成功的Team。
    展开
    3
  • 磉盘
    2021-07-09
    可能是每个公司不同把,我们公司都是PM先搞定领导,然后领导发一封邮件,就有了变化的引入,在列入KPI里。 引入变化到是很适合研发同学,研发经常会引入新的技术新的框架,都是先有几个拥抱变化的人,几个新的功能先用,等有了理想的效果,自然就普及开了。 不只是引入变化,也可放弃一些,就像高效会议那篇,做“断舍离”,最终保留下来的基本上都是适合团队的。 首先发心要正(有些KPI的制度员工是不喜欢的),适当的时机引入,从解决大多数人的痛点入手,最后公开争取大多数人的支持。
    展开

    作者回复: 你说的是自上而下引入变化的方式,效果短平快,然而如果这个变化没有得到大多数人的支持,落地后很难持久,容易造成“一抓就死,一放就乱”。 而那些能够击中大家痛点的变化,在落地中会得到长期自发地遵循。

    2
  • 王丽莹
    2019-12-06
    我遇到的问题就是我们三四个人就有五六个项目,都做得很草率~😂 现在人都既是管理者又是开发者
    2
  • Geek_c0c829
    2020-03-24
    公司推动使用jira,于是结合经验和其他公司的实践,制定了jira使用规范,但在落地过程中遇到很多问题。多次分析和推动,并没有好的改善。请问关于推动jira规范使用,有什么好的切入点吗?
    共 3 条评论
    1
  • 嗨哒哥
    2022-06-30
    头痛医头 脚痛医脚,这样很容易陷入困境,要从全局出发寻找最优解。
  • 森林木
    2022-03-19
    很多时候PM像是一个小团队的CEO,要想尽一切办法抓住大家的核心利益诉求并保证团队能够达到目标。
  • 问天
    2021-09-02
    “能够站在对方角度设身处地思考问题”,确实这是一个心智模式的问题,如果遇到意见不同的人,就下意识的认为是敌人,就想要以对抗的方式沟通交流,那么结果不会太好的。 确实只有转变思路,才有可能得到更好的结果,至少会有更好结果的可能性。 但是人的劣根性就是非我族类,其心必异,就会下意识的采用对抗的方式,这是人性不好改。 所以项目管理真是和自己的人性对抗的过程。
    展开

    作者回复: 并非对抗,最终其实是与人性和解,承认每个人有不同的视角,就是会看到不同的世界,认清这一点,就不会强加自己的观点给到他人,也就更容易设身处地理解每个人。

  • Stephen
    2021-05-21
    找到大家的利益共同点,而非只是自己受益。找到共同点并让他们同意改变是个技术活
  • 何以慰相思
    2021-05-05
    变革没有支持者,再好的变革都是空谈。现实工作中,有很多人就想得过且过,这样做起来就很难了。
  • 牺牲
    2020-04-15
    团结就是力量的逆向思维。如果刚想引入变化就公开面向全员,反对声音一出,本只是犯嘀咕的可能立马就会跟反对声音拧成一股绳,形成一堵实实在在的墙。事先逐个击破,把反对声音扭转,让它们无法汇集。真正全向全员公开的时候,即使有个别反对声音,也会被改革的大浪压下来,顺应变化。
  • like_jun
    2019-12-01
    因地制宜真的很重要。项目管理不是一层不变的。需要根据项目进行调整。