项目沟通并非吵架，看起来却总是剑拔弩张。有效沟通才能真正解决问题，笔者给出了一些实用的建议，从对象到场景，再到方法与技巧，应该在沟通中有针对性地注意这些问题。
沟通是个老话题，在项目管理中有专门讲沟通的章节，它是九大知识体系中的重要组成，但是实际工作中你会沟通吗？我结合个人的经验来聊一聊沟通，希望读后有不一样的感受。
沟通无处不在，在项目管理中是影响项目成败的关键因素，如何有效沟通？一直在学习，一直没长进——我们自己都觉得自己的表述没有问题，你听不懂是你的问题，你不理解你就是笨，这就是沟通双方的矛盾。
一、沟通对象
首先按工作时间来划分沟通对象。
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）接纳
需要有一颗包容的心，对的、错的，都接纳。
为了争论而反对，那是诡辩。我接纳了你的观点，对的入我心；不对的，我们就协调、继续寻求好的方案或方法。我说出自己的观点，我只是说出我的观点，我不批驳你。论学，是为了辩明白，不是为了争个你高我低。
四、总结
沟通就是为了设定一个目标，把信息、思想和情感在个人与群体间传递和反馈，并且达成共同协议的过程。
虽然经历了多家公司，接触了很多人，但是如何沟通仍然是萦绕在我脑子中的一件重要的事，不善于表达，个人技能的不足都是造成沟通不畅的绊脚石。
在沟通中应该不断的提升个人技能，要学会换位思考，站在对方的角度去思考，你可能见到整片森林，最后感谢您的阅读！
