如何与设计师和程度员有效沟通?实施起来无非是多观察、多咨询、多表达，加一个自我学习和自我尝试的过程。
多观察、多咨询就是要多观察程序员、设计师的工作，在闲时多咨询程序员、设计师工作具体在做什么、技术方案考虑了哪些方面、设计稿为什么会拖延交付日期、为什么这种方案实现起来比较复杂而那个做法简单得多。
多表达就是要将自己在做什么表达给其他人，让他们知道你不是真的在打酱油。表达方式有很多种，不要做得太突兀，自然一些，这种表达，其实也可帮助你将情绪、负能量抒发出来。
自我学习和自我尝试对于没有技术背景、没有设计背景的PM来说尤其重要，为了更好地合作，你必须通过自己的学习和尝试，了解别人的工作。这样基本上已能让其他角色对PM包容、吐槽得少了。但这还不够，可以做得更好，便是互相理解。
互相理解就是了解对方的痛点和难处，尽量不让对方为难。这对于很多人是很难的，很多人只了解自己的痛和难，相对无法感受别人的痛苦和难处，这类性格大致不太适合做PM了。PM需要快速把握其他角色，真正在意和痛苦的是什么，需求方案中真正的难点在哪里，为什么会被PK和挑战。
举个例子，假设一个需求方案，由A、B、C三个关键逻辑，和D、E、F三个细节逻辑或设计点组成。对于ABC为什么很关键，它们影响了什么，涉及多大比例的访问、或者是什么级别的老板已经拍板决策无法变更，PM有义务表达清楚，让其他角色(程序员和设计师)理解，实际上也有利于双方理解方案的本质和产生更好的自发驱动力。这是让程序员和设计师理解PM。产品经理也要理解程序员和设计师，比如DEF三个细节中，设计师提出来说D不符合一贯设计规范，而你硬是认为D这样设计用户体验最好，寸步不让，说不定便令人厌恶，实际上D这样的细节对于用户体验的影响实际又微乎其微或者用户完全不在意。又或是，EF这2个点，程序员希望可以换种做法，因为原方案的技术难度很高、时间成本较久，带来的影响是譬如产品界面略有变更、在某些极端流程和场景下会产生略微的不便。这时，要理解程序员和设计师的难处，理解对方的辛苦，对不重要的细节适当退让。切记不要在任何时候进入了“我怎么总是被PK下去了，不行我要赢一次”的心态，记住，你不是为了输赢，你就是做事。
做到了互相了解和互相理解，基本上你已经是一个受其他角色欢迎，备受好评的PM了。但你如果还愿意深入，便继续来互相谅解。
很多时候产品和功能上线后，经常会发现产品方面没考虑清楚，或技术方案扛不住压力down了，或视觉设计很难看，或重大BUG没被测试发现。这时需要互相谅解。在遇事时，双方互相谅解对方的失误和错漏，优先解决问题，而不是立马站出来撇责任。所以理想情况当然是大家和和气气，解决问题，谁也不喷谁。当然所谓“理想情况”就是很难每次都达到的状态。这时候PM要敢于站出来直接承认错误，承担责任，不要什么都推给“这是老板要求的做法”、“技术方案顶不住我有什么办法”诸如此类，殊不知PM就是负责人，必须为一切错误负责，需对老板的方案提出可能影响大局的疑虑，毕竟老板不会深入想细节，你有责任告诉他，也需对产品和功能的性能有预期，告诉开发这个功能大约的消耗，也需要做半个测试人员。PM每天就动动嘴皮子写写文档(至少很多开发是会这样认为)，如果遇事不扛下来，还有个屁用。
互相谅解的另一个角度是需要夸奖，在没出问题时夸奖，比如邮件总结时夸奖、在会议上夸奖、在对方领导面前夸奖等。夸奖是有方法的，空乏的夸奖没有意义，并且惹人厌烦。有一个常用的夸奖的方法，叫FFC原则，即Feeling感受，Fact事实，Compare对比。
举个例子，设计师做出来的稿子不错，你想夸奖她，不要说“做得好，真好”，说“我去这个稿子肯定妥了，我一看就心里踏实了，你看流程从之前的5步一下到了3步，还每一步都很易懂”。这便是FFC，基于这个技巧，能让人觉得靠谱，成为“不改需求的PM，有人会问，项目中不改需求么，其实当然会改，但是即使这样，你也可以成为一个程序员感觉你不怎么改需求的好PM。
沟通中利用好内部交流工具也至关重要。像我们公司，主要的项目文件，备忘，设计图，重点结论，会议记录等，都会放在trello项目卡片里，以便每个人需要时查询。平时的项目的细节沟通，及时交流，一开始使用的是Slack，但由于网络原因不是很稳定，而频繁的切换VPN着实让人头痛（我们工作的国内服务器有时候开着VPN会报错或页面响应缓慢），之后也转到了钉钉上，体验也还算不错，至少信息是多平台同步的，不会有遗漏。所以保持畅通的沟通渠道，确保信息的准确性、及时性，能大大提高产出质量和效率。
另外，在项目中，很多人也知道去沟通，可效果却不明显，似乎总是不到位，由此引起的问题也层出不穷。其实想达到有效的沟通就要掌握，尽早沟通、主动沟通这两个原则，实践证明它们非常关键。
曾经我也是菜鸟新手，管理项目团队成员的工作时松时紧，工期快到了和大家一沟通才发现进度比想象慢得多，以后的工作自然很被动。尽早沟通要求项目经理要有前瞻性，定期和项目成员建立沟通，不仅容易发现当前存在的问题，很多潜在问题也能暴露出来。在项目中出现问题并不可怕，可怕的是问题没被发现。沟通得越晚，暴露得越迟，带来的损失越大。
沟通是人与人之间交流的方式。主动沟通说到底是对沟通的一种态度。在项目中，我们极力提倡主动沟通，尤其是当已经明确了必须要去沟通的时候。当沟通是PM面对客户或上级、团队成员面对项目经理时，主动沟通不仅能建立紧密的联系，更能表明你对项目的重视和参与，会使沟通的另一方满意度大大提高，对整个项目非常有利。
关于作者
