澳门波音赌场注册

您当前位置:首页 >> 人生指南

项目沟通怎么才能不像在吵架?

发布时间:19-11-06

项目沟通并非吵架,看起来却总是剑拔弩张。有效沟通才能真正解决问题,笔者ぷ给出了一些实用的建议,从对象到场↓景,再到方法与技巧,应该在沟通中有针对性地注意这些问题。

沟通是个老话题,在项目管理中有专门讲沟通的σ章节,它是九大知识体系中的重要组成,但是实际工作中你会沟通吗?我结合个人的经验来聊一&聊沟通,希望读后有不一样的感受。

沟通无处不在,在项目管理中是影响项目成败的关键因素,如何有效沟通?一直在学习,一直没长进——我们自己都觉得自︹︺︻己的表述没有问题,你听不懂是你的问题,你不理解你就是笨,这就是沟通双方的矛盾。

一、沟通对象

首先按工作时间来划分沟通对象。

1.初入职场的毕业生

一般情况下由于工作经验不足,在沟通过程中都┖会彬彬有礼听着前辈大哥在那喷,所以表现很真诚。其实90后思考问题的方式与前辈有很大不同,在沟通过程中应该让他们参与进来,你会得到意想不到的效果。

这部分人成长是非常快的,没准哪天就成为你的领导了。

2.3至5年工作经验的人

目前这部分人是产品技术业务ц团队的主力军,干活的是他们■,所以在需求会▣▤▥、评审会宣讲的、讨论最积极的也是他们。他们大胆、╳有想法、有能力敢想敢干,遇到这部分人时要多聆听,多思考后再表达,不要打无把握之仗。

3.5至10年工作经验的人

这些人现在基本是领导了,不是主管就是经理,有♂的可能已经是∏总监了。

在项目需求启动会、例会或总结会上,这部分人会侃侃而谈,会提出各种想法与意见。有能力的靠真才实干上来的人,遇到问题能够快速给出解决方案,需求讨论会中能够一针见血说出关键点,这些人值得佩服。Ⅶ

也有一部分是靠吹牛或在大公司呆过几天混出来的人,沟通能力极强,但是一般只能说说大流程,聊到细节就属于我是领导我不负责细节的人。实话实说这部分人是极少的,这部分人最擅长的就是指手画脚而且无知无谓,脸皮也挺厚,遇上你就只能呵呵了。

实际上,我所接触的人中有很╪多都有自己擅长的领域且能力也很强。前段时间网上有个热贴:《我是技术总监你干嘛总问我细节?》有兴趣的可以搜搜〓。

4.10年以上工作经验的人

有些人无论ↂ从经验还是技术或业务能力上都有些干货,沟通时不推诿,能够很好地进行交流。但也有些人就是给你画大饼,沟通过程中他讲的你听着没错,而且感觉的确是那么回事;但是等沟α通完回来静下来一想,什么也没解决,完全是虚∽的。所以在项目执行中遇到这些人要注意自己的判断。

以上是我瞎掰的,其实我们在互联网公司中,主要涉及产品部(设计、视觉、产品)、技术部(研发、架构、运维、测试)、业务部(采购、销售、市场、运营、仓储、客服、财务)三个大部,按沟通范围又分为内部沟通与外∏部沟通。

二、沟通场景

1. 熟悉的场景

1)业务、产品间

业务会说,我就这么多要求很简单,你们帮忙产品规划设计吧;但我要求XX日前(大促、店庆)必须上线,这是老板要求的,而且我们的优惠宣传册已经印好发出去了。

产品心里第一反应是什么鬼,没确定你发什≈么宣传,又拿老板来压我,自己要的东西都没整明白还和我扯。但表面上会心平气和得说,做肯定没问题就是资源太紧张,你『们看看把这些不确定的再梳理一下,然后我们按优先◣级排期,肯定尽量满足你们。

这就是需求收集阶段,此部分对于业务与产品应该先确立目标,再判断风险,然后分阶段设计规划,好说好商量肯定能解决问题,千万别拍脑袋,拿上线来压人。

2)产品、技术间

到这一轮的沟通,基本上应该是需求已经确∞定,要进行需求评审了。

首先产品要先装孙子找研发(这里描述不恰当,大家别当介意呀),ⓛ描述这个需求业务有多急、我们这已经拼命挡了很多很多功能放在二期实现了;你们先看看PRD,然后给我们一个排期,有问题随时找我们,态⿻度非常好。作为业务技术中间协调人,着实的不容易呀,这里必须要赞一下。

技术这边,心里第一反应就是又做这些不靠谱的需求项目,能不能整点有用的,上次做完的项目上线了也没见啥效果呀!

作为技术咱不能让产品瞧不起。

首先,要大概判断影响到所负责的系统模块,想着实现的技术,对于新接触的技术可能还会上网找些资料研究一下。其次,也会说这功能实现有难度,指出PRD中设计╬不合理的地方,在需求评审会中会指导产品说你应该这样这样改一下。但往往这部分是在沟通过程中最耗时的ё-,也是最吵的阶段,心里互骂是家常便饭(表面还是要量和谐的),在好多的需求评审会上吵起来也不足为奇。

在此阶段,我个人觉得应该按以下流程做:

确定干系人,指定相关需求评审人员,在需求评审前需要把PRD发给相关人员;同时相关人员要提前看,光接收不阅读是没有用的。 提前准备资料,在评审前,关于此需求与项目的产品、技术负责人要提前沟通,沟通主流程,确定大方向无问题。 合理的时间安排,会议室、电话会议设备要准备好,要Ⅳ严格按计划评审,对于不确定细节如果不影响主流程就会后分组讨论。 需求评审后要有会议纪要,这是沟通方式的一种,也是此阶段的一个总结;一个项目经过几次评审能够确定,最终需求都是很不错的;有很多变更都是在项目进行中途或即将上线前调整的,这都是不可避免的。

3)业务、技术间

如果有产品部,那♯♮么就不要有此环节,这个是原则问题。

有的业务可能想绕开产品,直接找技术解决一些问题需求,有的技术觉得就是顺手的事。有些所谓的管理者又奉行自己了解的敏捷开发模式,自认为简化了流程,提升了交付能力,在那自以为是。

其实后续有些坑就已经埋在那里了,最终出了问题就开始收拾烂摊子了。公司初创时没有专门的产品,一般领导就是产品,沟通尽量要叫上双方的领导,共同商讨,共同解决。

2. 外部与内部沟通过程

上面说的业务δ、产品、技术间的沟通对于各个部门来说都是属于外部沟通。公司间都会有部门墙,都会有竞争,都会有各自的KPI。所以对于外部沟通还是要确定一些必要的规则。

我认为最重要的一点是该说的说,不该说的别瞎说。有些人自认为关系很好,无论什么都和盘托出,尤其是没有与自己的⊙上级●领导沟通前就承诺这、承诺那的。

我个人的分析:

研发人员都自认为技术牛,都觉得没有技术不能实现↹的(有┗些难但可以变相解决); 技术思维,0就〡是0,1就是1——诚实,遇到一些会说的产品和业务就妥协了;如果再给点糖衣炮弹就彻底交待了,碰上美女给∩个微笑就更不好意思了。

内部沟通一般指部门或组内的沟通,但这也是相对的。

从业务、产品、技术来分,每个内部都应该提前进行内部沟通,保证后续项目需求的顺利进行╣。部门间有障碍,内部也同样存在这样的问题,但是如果大家目标一致,所有的问题都能迎刃而解。

我们在沟通过程中是采用“攘外必先安内”的政策还是“枪口一致对外后,再解决人民内部矛盾”的方法呢?具体问题具体分析吧,两者有效结合,敌中有我,我中有敌才是最佳组合。

三、沟通方法与技巧

1. 沟通方法

瞎白话这么多,▌具体的沟通方法是啥,项目管理课程中都有过很多介绍,但下面只是我个人的理解和总结。

1)要选择合适的沟通渠道

我认为能当面沟通的就不要电话或微信,能电话的就不要邮件或微信。现在每个人手机∪中如果没有几个微信群或钉钉群,你都不好意思说你是职场人员。但实际上有大部分都是些扯淡群,刷屏的,拍马屁的信息居多,沟通效率不高。

2)选择合ζ适的人沟通

尽可能少的人参加,参加沟通的人一定是要能拍板的人。我参加★过很多项目需求会,有的参会人员有十几或几十人,如果是项目启动会我觉得还可以;但是一个需求评审或研发、测试用例评审会就真的没有必要的。

3)选择合适的时间

在周末前、节假日前就不要为了完成工作而完成工作了,这时无论业务还是产品、研发我都觉得适合于总结,而不适合进行相关的项目需求评审了;但对于现在执行996工作时间的公司来说,这点可以忽略。

4)真诚、直接,避免小会

我曾接触过总习惯于拉小群、┊┋开小会的人。有问题就摆在会上说出来,不应该总是各个击破▕,这样的人反正我是不喜欢的。项目干系щ人了解了相关内容,有助于互相配合调整,避免猜疑。

2. 沟通技巧

前段时间看了《王阳明全集》这本书,里面讲到关于探讨问题的6字真决,即:聆听、欣赏、接纳。

学会聆听,聆听你过去不耐烦听的;学会欣赏,欣赏你过去不欣赏的;学会接纳,接纳你过去不愿意接纳的——你包容了整个世界,你就拥有了整个世界。

1)聆听

先放下自己的见解,清空自己的心з脑。不能像武术对打一样,自己先摆个防守架势。

各种需求项目及技术的讨论评审不是打架,没必要先摆个防守架子;$不防守,不能像街头泼¤妇吵架,两个人各吵各的,只用嘴,不用耳朵。

2)欣赏

对方讲的无论是PRD还是技术实现方案,还是业务流程,必定是经过整理的,而且有的形成文档了。我们应该先接受。为什么?

每个人的视野有限,都是只能看清自己前面,看不到后面。有的人被沙子迷住眼,甚至连前面也看不清。对方对,我欣赏;对方错,我也欣赏。知道他对在哪里,是提高;知道他错在哪Ц里,也是提高。

3)接纳

需要有一颗包容∮的心,对的、错的,都接纳。

为了争论而反对,那是诡辩。我接纳了你的观点,对的入我心;不对的,我们就协调、继续寻求好的方案或方法。我说出自己的观点,我只是说出我的观点,我不批驳你。论学,是为了辩明白,不是为了争个你高我低。

四、总结

记得我在10年项目管理师的软考中的论文就是关于沟通的,沟通就是为了设定一个目标,把信息、思想和情感在个人与群体间传递和反馈,并且达成共同协议的过程。

虽然经历了多家公司,接触了很多人,但是如何沟通仍然是萦绕在我脑子中的一件重要的事,不善于表达,个人技能∣的不足都是造成沟通不畅的绊脚石。

在沟通中应该不断的提升个人技能,要学会换位思考,站在对方的角度去思考,你可能见到整片森林,最后感谢您的阅读!

 

作者:倔强的大萝卜;公众号:倔强的大萝卜

本文由 @倔强的大萝卜 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

{{wanzhanqun_analysis}} {{website_analysis}} {{website_copyright }}