沟通对于产品经理来说算是老生常谈的话题了，无非是IM、邮件、需求文档、会议等。
为什么需要沟通？产品经理做为需求发起人，从需求收集、分析到最终形成方案，运营、开发、测试同学只是部分参与，大家不知道需求最终要做成什么样子，因此，产品经理需要将自己的想法讲给大家听。
搞清楚本质就好办了，在我刚入行的时候，以为需求文档就是产品工作的全部了，其实需求文档更多是一种类似档案的东西，主要用于记录，毕竟人的记忆是有限的，便于以后需要时回溯。还有就是，在需求评审会议前，通过文档跟开发及测试同学先进行一轮纸面上沟通，让他们对需求有个比较全面的了解，并指出需求中不合（sha）理（bi）的地方或形成疑问，带着这些问题参与随后的需求评审。
需求评审是个好东西，开发、测试及其他需求相关人员大家齐聚一堂，一起欢乐讨（tu）论（cao）需求方案。产品经理做为主讲人，结合原型对方案进行说明，如果其他同学准备充分（当然，一般都不太充分），会提出一些不合理或存在疑点的地方，这时候产品绝对不能抱着老子是最聪明的，质疑我的人都是傻X。开发、测试总是能想到一些你考虑不到的点，在整个沟通中对方案进行了完善，最终根据会议内容对需求文档进行修改。需求评审一定要充分沟通，记住是沟通，不是吵架，并且产品经理要控制会议话题，不要跑偏从而浪费时间。在会上，只讨论需求方案，如果与会人员都没有异议，会议就可以继续了，不要去讨论实现细节了，我经常面对客户端和服务端同事开始愉快的讨论接口，囧。如果开发提出来实现比较复杂，产品经理记录下来，会后根据需求的目的，重新思考是否有其他方式实现。
我一直提出需求评审要进行三遍，第一遍是产品主讲，第二遍是开发主讲，第三遍是测试主讲。这么做的原因主要是为了大家对需求的理解达到一致，前期对需求沟通的越充分，后期出现的bug越少。
最近接了一个急活，年前接二月底就要上线，需求是对核心业务进行调整，由于我们团队是半路接手，加上基本无任何文档，因此对之前业务的了解只有询问需求方及读代码两条路。我们先提出需求方要对需求有个比较详细的描述文档，其次，我们同时安排开发同时读代码，了解之前业务流程。对方将需求描述发来后，我们根据读代码了解的旧业务流程，根据需求，找出最小实现代价的方案，毕竟时间紧迫。几轮讨论下来，方案基本敲定，我将方案文档化，接下来的一个礼拜，基本天天跟开发、测试在会议室泡着沟通需求。结果，自然效果比较明显，开发用了十来天，测试及bug修复用了不到一个礼拜，我们按时完成了任务。
沟通无所谓形式，达到目的就好。
