[沟通管理] 学会这四招,你也是项目沟通达人

[复制链接]
查看5867 | 回复0 | 2018-2-1 15:55:03 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册 |

x
沟通自始至终贯穿了项目从0到1的完整生命路线。在各种项目问题的解决、进度的推进背后,都凝结了大量的沟通协调。今天,我们就来聊聊项目沟通中的四个原则。其实,这四个原则的核心是内在的心态修炼。然而兵无常势,水无常形,不局限于形式,有强大而积极的心态才是取胜之道。
原则一:主动尽早
案例场景1
项目4月20日就要发布了,项目总监早就把这个信息通告给了几个重要客户。但这边,项目经理小A和团队在4月上旬就发现越来越多计划外的任务不断地塞进了任务列表,比如测试服务器搭建等。大家从第一个任务加入的时候,就在暗自忍耐并企图自行通过加班方式进行消化。虽然大家都看到了任务列表越来越长,但没有人愿意去触碰4月20日能否发布这个问题,小A也是如此,更是祈祷团队能在计划内吃掉新增任务,而不必惊动总监。终于,到了4月19日,大家不得不面对第二天无法发布的现实了,项目经理硬着头皮告诉了项目总监这个不幸的消息。
案例场景2
项目5月20日的发布目标,预留了一周测试时间。项目经理小B对测试预留时间反复思考后,判断测试时间不足,有延期风险,第一时间向项目总监报告了这一风险。在第二天的站会上,小B向团队提出了这一风险,项目总监和团队一同讨论后,对整体计划进行了调整,测试提前一周开始。最终,项目5月20日按期发布。
小A希望把问题扛下来解决,而给总监报告好消息,结果项目无法发布;小B尽早向总监和团队沟通了可能的问题,结果项目成功交付。
怕什么来什么,躲什么来什么。爸妈从小教育我们:“要敢于面对问题。”直面是种勇气,也是种意识和态度。项目沟通中,第一条原则就是要敢于尽早暴露问题。只有把问题摆出来了,才可能调动大家的力量来尽早解决问题。
对重要相关方的沟通也是如此。虽然他们非常希望听到产品能顺利交付的好消息,但尽早了解可能存在的问题,一方面可以避免他们向客户传递潜在有误的信息,另一方面可以为团队争取到最及时有力的帮助来解决问题。而这也一定好过发布前一天才得知一切落空吧!
有人总结说:“项目经理,就是要悲观面对项目,乐观面对团队。”话虽不尽然,但项目经理的确就是项目背后的那一双眼,要纵观全局,发现潜在问题;项目经理也是项目身后那一张嘴,不时提醒大家需要注意的问题或者需要做出的调整。一路报喜,只能粉饰太平;只有对问题的主动和及早沟通协调,才能真正收获最后的喜报!
原则二:抓住本质
案例场景3
测试主管在泡泡群里呼唤项目经理小C:“小C,有个小意见!”
“哦?”
“现在开发任务都记录到白板中,完成这个版本以后收走了那些任务便笺,我们报Bug的时候都不知道谁做哪个任务了。如果后面来了新人,每次发现Bug都过来问应该报给谁开发,这个代价有点大。”
接着小C拉着测试主管到会议室私聊。原来,新来的测试发现了回归Bug,每一个都得询问测试主管应该报给哪个开发,测试主管正愁着呢!原来测试团队一直都非常了解模块开发归属,哪怕遇到模糊地带,也会查询JIRA关键词来找到对应的任务和开发者。那为啥不直接报给开发负责人,让他来分配呢?开发负责人可以帮忙解决小部分问题,但如果是全部,那工作量就太大了。
小C似乎看到了测试主管的痛苦所在:“是啊,的确需要有个地方让测试很明确地了解模块的开发归属。”(将问题引向本质而不是具体解决方式)
“就是啊!否则我真不用干活了,整天都在帮新人指定Bug的归属!”测试主管很头疼。
看到了一致的问题,最终,小C和测试主管商量决定建一个维基页面,列明主要模块和对应的前后端开发,这样还解决了JIRA中原开发者离职变更这样的问题,可以根据团队情况保持维基页面更新。
测试主管以质疑白板作为沟通的开始,这是他所遇到的直接问题。如果小C作为白板方式发起人,以自卫的心态进行沟通的话,很容易将视点聚焦于白板本身的矛盾,从而将沟通变成攻守关系,可能很难有双赢结局。在上面的例子中,一方面小C及时避免了在泡泡群中公开讨论矛盾问题,另一方面把视点聚焦在测试主管的“需求”而不是“需要”上,这就把双方都放在了更高的、容易达成一致的目标上,而不是具体的解决方式上。这样,在相同的出发点前提下,沟通就容易顺利进行了,解决方案也就更水到渠成了。
生活工作中,有无数类似的场景,讨论由具体的某个“需要”开始。如果纠结于“需要”,沟通就容易陷于泥沼;而如果聚焦“需求”,那就容易达成求同存异。
产品经理和开发者争执于某一个临近发布时提出的需求变更,如果着眼于为什么那么晚才提变更或者进度太紧张,那么结果无论如何总会有人内心郁闷不堪。但如果先一起来看看为什么要做这个变更,对产品、对用户的作用如何,也许结果就变成我们如何去做的讨论了,而不是做不做或者分清责任的问题了。
只有透过现象看本质,才能在沟通中真正求同存异。
原则三:共情引导
说到共情,最深刻的案例来源于育儿界。咱们一起看一个案例,是一位妈妈和女儿之间的对话,相信几乎所有的家长都会有这样的对话。
案例场景4
“妈妈,我明天不想上学了!”
“哦?”(敞开对话大门)
“上周的考试,我才得了30分。”
“是你说过的那个数学考试吗?没想到只得了30分哦。”
女儿立马放声大哭:“我已经非常努力了!可才考了30分!”
“很努力了才得30分,的确令人沮丧。”(共情,并且中立)
女儿梨花带雨:“我要原来的中文老师!”
“要是她在,你就不会考这么惨了。”(说出女儿的心声)
女儿使劲儿点头,认可老妈的诠释——说到她心窝窝里啦。
“你是因为看不懂题而没考好吗?”(女儿中文阅读不太好,应用题不一定能理解。)
这下子女儿的防卫又自动脱落了好大一层:“老师说话太快了!我根本听不懂!谁都听不懂他说什么!”
然后女儿又抱怨了一堆老师的不是,老妈表示理解。
女儿:“我不上学了行不行?等到下周一再去,行吗?”
老妈:“嗯,这件事于你来说是非常严肃沉重的,一直压在你心口,你一直在纠结,你想停止思考它,却发现自己做不到。”(终极洞察)
女儿“是”了一声后沉默。老妈知道这一箭射中了靶心,曙光在望了。
女儿:“我是不是非上学不可呢?”
老妈:“当你特别不想做一件事,可又必须去做的时候,是挺困难的。”(没有直接给判断)
女儿:“我也不是特别不想去,明天有体育课和艺术课。”
老妈:“你最喜欢的两门课,如果不去就可惜了。”(说出感受)
女儿:“我不想错过体育和艺术课。”
老妈:“你感觉很矛盾。”(说出感受)
女儿再次陷入沉默。
沉默良久之后,女儿声音颤抖着,带着哭腔,说:“那好吧,我明天还是上学吧,因为我想上体育课和艺术课。如果中文老师还不好,我星期四和星期五就不去学校了。”
随后,她小哭了两声,表示她提出的这个解决方案是多么令她忍辱负重、委曲求全,她是多么可怜啊!
妈妈自始至终没有直接给女儿任何判断或者指令,取而代之的是共情和引导。很多时候我们的立场是随着情绪而微妙变化的,所以沟通时的情绪基调很可能会导致沟通结果的迥异。理解和接纳对方的情绪,充分引导对方把问题和情绪表达出来,也就开启了沟通的大门。相反,如果开门见山就给出自己的判断和见解,不仅会把对方的倾诉欲望堵回去,更可能让双方站在情绪对立面上。
当然,仅仅共情,还是不够的。沟通,尤其是项目沟通,大都希望达成一定的目标,如果仅做了倾诉,是无法解决问题的。因此,以共情为基调,需要在陪伴的情绪中洞察问题根源和解决突破口,并适时加以引导。如上例中妈妈所说的“这件事于你来说是非常严肃沉重的,一直压在你心口,你一直在纠结,你想停止思考它,却发现自己做不到”,把女儿的情绪从负面发泄引导到问题解决的思路上。最后,女儿自己能够找到解决问题的方法,妈妈所做的,只是陪伴和顺势引流而已。
原则四:完整解决
和普通的个人沟通不同,项目沟通往往是为了解决项目问题,所以,往往不是一次性的沟通或者和单人沟通就能解决问题的。项目沟通需要在时间维度和沟通对象维度有计划地做拓展,来为解决问题服务。
案例场景5
随着产品的发布和不断取得进展,项目经理小D和测试主管小E都看到回归测试工作压力越来越大,产品的质量风险也一天天升高,持续集成和单元测试的强化要求迫切。如何来引导团队开始在这方面起步呢?
小D和开发团队负责人沟通,获得了加强持续集成的认可,但开发负责人觉得可能还不到开始推行的时机,不过赞同下个版本从最基本的持续编译开始尝试。小E和质量保障部门沟通获得了基础工具和专业指导方面的支持。
在迈出了持续编译的第一步(大约1个月)之后,小D和产品总监沟通了持续集成和单元测试对于产品目前和未来的重要性,得到了总监的基本认可。同时也获知需要充分平衡产品交付节奏和额外的持续集成精力付出。小E给开发团队做了持续集成方面的基础分享式培训,让大家对为什么要做持续集成以及可以如何做形成了初步概念。小D和小E又多次和开发团队及其负责人进行了沟通,确认了逐步引入和保障单元测试的方式。随后,基本的持续集成框架和集成状态广告牌开始使用了,持续集成状态也被包括进了项目日常状态公告中……
完整解决,并不是具体的沟通技巧,而是如何完整地安排沟通以及使用不同的沟通方式来解决问题。项目中,很少有仅凭一人之力就可以解决的问题,尤其是策略性、方向性的问题。这就需要我们有目标、有计划、有耐心,以积极的心态去面对整个沟通和推进过程。
要做到完整解决,首先要有强大的愿力和内心。愿力是根本驱动力,是对目标的期待强度。完整解决的过程往往漫长,坚定的决心可以陪伴我们坚持到底。强大的内心,是耐心,是韧性。项目沟通过程中一定有挫折,一定有起伏,强大的内心可以给我们积极的心态和越挫越勇的精神。
其次,要有敏锐的洞察力和审时度势的能力。问题的解决方式有很多种,需要看清问题的根源和不同角色对问题的影响力及作用,也要看到不同时期不同人对于问题的态度和需求。为什么开发负责人一开始表示认同但无力推进尝试?产品阶段、团队规模、团队状态都是他考虑的因素。为什么会同意从持续编译开始?毕竟不需要团队本身的额外付出,但又可以为未来搭建基本框架。为什么要先给团队做分享?因为团队成员年轻、经验不足,甚至有人完全不了解持续集成是什么。
完整解决,已经不仅仅是沟通的问题了,而是项目过程中持续改进的典型实例。有愿景、有策略、有坚持、有反馈,成为真正的闭环,这样才能使项目和团队在改进中成长。 
结束语
沟通的过程,技巧其次,关键在沟通的心态和心境。无论是主动尽早、抓住本质、共情引导,还是完整解决,真正起作用的都是沟通者的内在修炼和积极心态。
我们经常说换位思考,确实,沟通本是为了解决问题,关键就在于走出小我,从对方和全局的角度来思考问题。当我们“忘我”时,就不会再害怕、再遮掩,也不会纠缠于表面利益是非,这时才可以和对方同探讨、共进退,进而完整圆满地解决项目问题。
沟通,可以修炼吗?不,因为它不仅仅是技巧。沟通,可以修炼吗?可以,因为它正是我们人生修炼的过程!

转自《项目管理评论》微信公众号,2018.1.22,作者曹智清
本文作者供职于网易杭州研究院项目管理部。该机构成立于2011年,是一支专业而充满活力的项目管理服务团队,为杭研院各类互联网项目与产品提供专职项目经理、项目管理顾问,以及敏捷教练等服务,并著有畅销书《网易一千零一夜》, 分享互联网巨头一线项目管理实战经验。

"您的鼓励,是我前进的动力"
还没有人打赏,支持一下
车研会员,开心每一天!
您需要登录后才可以回帖 登录 | 立即注册 |

本版积分规则