项目管理的变革引领者:如何有效地引入变化并带领团队迈向成功?

简介: 项目管理的变革引领者:如何有效地引入变化并带领团队迈向成功?

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

新手想引入变化,需“天时、地利、人和”。

1 天时:找准合适的时机

首先是“天时”,也就是合适的时机。时机或早或晚,都会让引入变化的阻力成倍放大:

  • 早了,大家还没意识到问题
  • 晚了,他们又找到了可以将就的办法,逐渐形成了惯性,并视为理所当然

到底什么时候才合适?

Edge升任项目经理后的第一个项目,距离版本发布只剩两天,任务系统上还显示着有好几项关键任务没完成。之前明明说是这两天就可以弄好的,到现在讨论1h,最后敲定先用加缓存方案。可这么下来,再加测试,两天肯定搞不定,这版本想做完恐怕无望。


整个团队似乎只有她一个人在意,目标是不是能达成。做项目经理的半年里,她经常感觉自己脑门写着“监工”,非常着急,可又无处使力,只能一个个催。这困境怎么破?


一个念头瞬间击中她:“每日站会!”Edge一个鲤鱼打挺从床上蹦了下来,连忙打开电脑,不过很快又陷入沉思。以现在形势,跟团队提每天开会?Edge在想象大家反应,“开啥玩笑?活都干不完,为啥每天开会,安静写会代码不行?”


为啥呢,总不能跟大家说为方便自己跟进问题,那样大家买账才怪!Edge心想这次得讲究“策略”。


很多同学都能看到自己项目组中各种问题,但问题太多,一看到问题就想改变、整治,就觉得这是机会, 其实问题并不等同于时机,你要把问题与痛点关联,才能形成好时机。


怎么关联?


高峰是这部门技术总监,当初是他把Edge提拔到项目经理。又到每周一次周会时间,高峰和Edge的问题总是特别多,不知不觉2h过去。直到预定的会议室到期,他们被撵了出来,状态还没同步完。


会后,Edge叫住高峰,直接跟他谈起对目前境况担忧:“现在我们每周开一次同步会,总感觉信息滞后得很。若我们同步频率更高点,就能提早发现问题,现在也不至于又大费周章。”高峰没直接回应,对Edge的建议也不置可否,在他看来信息同步的问题虽有,但整体还好。


Edge猜到高峰的心思,进一步说:“开发问题倒还好办,可一旦涉及其他角色、其他模块支持,事就难办。我们喊了很久加强测试,加强运维,可喊完就没下文。现在,我们产品基本功能已成型,质量和运维才是重点。”。“没错!”高峰坚定地说。可见,Edge的话一下戳中高峰痛点。


停下来敲黑板。Edge第一次和高峰聊到信息同步滞后问题,对方虽也知道这有问题,可显然并没有什么改进的动力。


有同学说,自己跟老板反馈一堆问题,老板虽认同,但最后没下文。 之所以不能产生改进动力,只说明你还没抓准痛点。


痛点,就是必须及时解决的问题,包含强烈迫切感。 判断是否是痛点的标志,就是看这个问题,若不解决,对方是否会很苦恼、很痛苦。


就像Edge之所以在意这问题,是因为这是她的痛点。作为项目经理,Edge迫切需要抓手,实时跟进项目动态。如果这个问题不解决,Edge就痛苦。但状态更新不及时,是Edge痛点,不是高峰痛点。


真正让高峰苦恼和痛苦,是整体团队的协同效率有很多问题,这是他真正痛点。 要想促发别人的行动,须换位思考,体会和抓住他的痛点,可能一击即中。


怎样才能抓到痛点?

访谈法,直接问

我在第4讲干系人分析,给出针对不同干系人的问题列表,可参考。最重要问题是,“你认为项目组当前最大的风险和问题是什么?从你的角度出发,最迫切需要解决的是啥?”


观察法

与其看别人咋说,不如看他咋做。很多时候,人们说这很重要,但一两星期下来,也没投入任何精力,那这就是伪痛点。


去观察那些花他时间和精力最多、反复强调却又没很好解决的问题,才是真正痛点。

同理心和倾听

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


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

地利:学会因地制宜

Edge心想,终于等到机会。于是,她把各角色一起每天开站会的想法,一股脑倒出来,双方一拍即合。高峰觉得,这的确好法。考虑人数众多,他们又一起商议许久,觉得有必要分两组开站会。高峰说,“我们一开始要不还是两天一次,两组错开进行?”Edge知道高峰在顾虑什么,连忙回说:“刚开始的确需要慎重。”


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


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


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

人和:找到团队共识

与高峰统一战线后,Edge信心大增。于是,立刻找来几个测试,想聊看测试这边咋分组。Edge说“现在大家都坐得很近,但团队中的沟通似乎不顺畅,我跟高峰商量,考虑引入每日站会。”一句话还没说完,测试插话说:“我觉得现在沟通挺顺畅,有啥问题?”


高峰见状,赶紧打圆场:“咱们现在沟通方式是有事就喊两嗓,快是快。可很多事情喊过后,经常没下文。”Edge接着说:“是啊,就比方说,开发改个Bug没改好,测试还等着去测,结果问了一次说在修,几天过去了还没动静,再一看,开发已经忘了这茬,做其他的去了。这个情况我想测试肯定碰到过,但我猜测试你也不好意思一次一次去问吧。”其他两个测试点头应和,说确实是有这个麻烦。


Edge继续说:“可我们若每天站会,花15分钟互相同步下进展,问题就解决。测试不需跟开发催,每天站会开发自己会讲我的进展,如果测试需要开发重新安排开发顺序,也容易多。”看到巴泰若有所思点头,Edge就知道测试这边已ok。接着Edge又找运维,把站会好处说一遍,有高峰和巴泰支持,进行还顺利。


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

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


很可能你觉对的事,不同人看,会产生不同看法。 沟通时,要因人而异,针对不同人,你要采用不同策略

如何选用合适沟通策略?


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


在具体操作时,你可以 把变化涉及到的干系人,按照角色和层级做个初始划分,思考下不同区域的人,会怎么看待这个变化带给他的影响。你要做的就是,找出更多的积极因素,比如测试可以通过站会,更及时地获知和影响开发的进程等。同时,对于变化所带来的消极因素,提前引入相应的工具或方法来规避或改善。


除此之外,就算是立场一致的两个人,也会因为基本假设和价值观的不同,对同一件事有不同的解读,因而呈现出截然不同的态度。在大范围公布并引入变化之前,与关键角色进行一对一的沟通,是更加稳妥的做法。


又一次周会,同步完状态后,近2h已过,屋里闷热,大家有些焦躁,有人凑在一块开小会,有人玩手机。


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


Edge示意高峰说两句,于是,高峰就把早就讨论好的分组开站会的想法,讲出来。


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


大家显然心有所动,有人笑着问道:“那以后的周会是不是也不要开了?”


Edge说:“以后每周五前,我收集大家议题,如有需要全员讨论的另行组织,没就默认不开”看大家的一脸高兴劲,Edge知道已经大功告成了。


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


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


无论引入什么变化,都可从以上三个要素步步进行分析和推进。


总结

本文呈现了新手项目经理在引入变化过程中,最关键因素:天时、地利、人和:

  • 选择合适时机
  • 找到因地制宜的解决方案
  • 因人而异,采用不同策略进行有效沟通

若你想成功引入团队,最难的不是那些招数,而是招数背后你的发心。引入变化,不是因为你觉得这方法好,解决了你的问题,而是看团队需要啥,干系人痛点是啥。只有解决大家的问题,这变化才能最终被所有人真正接纳。

所有这一切须建立在信任基础,这信任

  • 不仅是对你能力的信任
  • 更重要是, 你是否能够站在对方角度设身处地思考问题。当你是在真心为他着想,为他解决问题的时候,对方自然愿意接受你所带来的变化

FAQ

如你已经在尝试把我之前讲到的方法引入你的团队中,你遇到过什么困难吗?你有哪些需要支持或解答的困惑吗?哪些顾虑阻止了你进步尝试?

目录
相关文章
|
7月前
|
敏捷开发 运维 Devops
拥抱变化:软件开发中的敏捷思维
在快速变化的技术世界中,传统的瀑布式开发模式已不再适应市场的需求。本文探讨了敏捷软件开发的理念与实践,以及它如何帮助开发团队更灵活地应对变化,提升产品质量和客户满意度。通过分析敏捷的核心原则、实施策略以及面临的挑战,揭示了敏捷思维在现代软件开发过程中的重要性。
|
7月前
|
开发框架 运维
项目中的技术债
项目中的技术债
|
2月前
|
项目管理
NPDP|产品经理的沟通协调能力:塑造产品成功的核心力量
产品经理的沟通协调能力对于产品的成功和团队的高效运作至关重要。只有具备了强大的沟通和协调能力,产品经理才能更好地履行职责,推动产品的发展和公司的业务创新。
|
4月前
|
人工智能 供应链 测试技术
CIO们在运营、创新、IT和业务的关系及如何利用GenAI方面的九大经验教训
CIO们在运营、创新、IT和业务的关系及如何利用GenAI方面的九大经验教训
|
7月前
|
机器学习/深度学习 设计模式 人工智能
拥抱变化:我的软件开发适应之旅
【5月更文挑战第30天】 在快速迭代的软件开发世界里,适应变化不仅是一种能力,更是一门艺术。本文以个人视角切入,探讨了如何在技术不断进步、工具日新月异的环境中保持自我更新与成长。从初识编程的困惑到成为一位能够灵活应对变化的开发者,文章回顾了学习历程中的挑战、实践和反思,提炼出适应变化的关键策略,并分享了在技术演变浪潮中保持个人竞争力的心得体会。
|
7月前
|
机器学习/深度学习 设计模式 敏捷开发
拥抱变革:我的软件开发演化之旅
【5月更文挑战第7天】 在快速迭代的技术领域,我的成长之路映射了软件工程的演变。本文将通过个人视角,探讨从初学者到资深开发者过程中遭遇的挑战、学习的关键技术和对行业趋势的适应。不同于常规摘要的总结性质,此部分将作为引子,展现技术成长旅程中的思考和感悟。
38 2
|
7月前
|
敏捷开发 持续交付 开发者
拥抱变化:软件开发中的敏捷思维与持续学习
【4月更文挑战第30天】 在快速迭代的软件开发领域,"敏捷"不仅是一套方法论,更是一种哲学。本文将深入探讨敏捷软件开发背后的核心原则及其对开发者心态的影响,特别强调持续学习的重要性。我们将剖析如何在不断变化的技术环境中保持适应性和竞争力,并提出策略以促进个人和团队的成长。文章旨在为读者揭示那些成功适应行业变革、不断提升技术栈并保持职业生涯活力的专业开发者所遵循的实践方法。
|
7月前
|
人工智能 物联网 量子技术
【专栏】培养适应性思维需终身学习、跨学科思维、创新接受失败及开放合作。拥抱技术变革,以适应性思维迎接未来
【4月更文挑战第27天】在快速迭代的技术时代,适应性思维成为个人和企业成功的关键。技术演进带来挑战,如知识更新、产业结构变化及伦理问题。适应性思维能应对不确定性,把握机会,企业需快速调整战略。培养适应性思维需终身学习、跨学科思维、创新接受失败及开放合作。拥抱技术变革,以适应性思维迎接未来。
75 5
|
人工智能 大数据 云计算
《激发活力,打造数智化高效敏捷组织》电子版地址
当今时代,随着互联网、大数据、云计算、人工智能等数字技术加速创新,经济社会正在全面 数字化、网络化、智能化,全球正在加速进入数智化时代。在新一轮的时代浪潮下,数智化新 动力将为组织带来全新的发展机遇,重构组织的管理模式、商业模式和创新模式,驱动组织不 断变革、升级与重构,不断释放组织的增长潜力。 那么,在数智化时代,面对未来的不确定性,组织应该如何适应变化并保持敏捷呢?
134 0
《激发活力,打造数智化高效敏捷组织》电子版地址
|
架构师 项目管理
项目管理修炼之道札记:创造出色团队
项目管理修炼之道札记:创造出色团队
132 0