需求来源有多方面，除了用户的、竞品的、产品经理YY的、还有领导的、其它部门的，等等。大部分情况，需求的发起方是产品经理，但有时其他团队也会提起需求。

这时候，沟通是一件非常关键的事情，产品经理务必确保需求的提出方、研发、测试等干系人对需求的理解一致，否则，会直接影响后续一系列的工作，犯下劳民伤财的罪过。

1. 沟通模型

所谓沟通的过程，就是一个人要在信息发出来时开始编码，这叫做用一种方法讲给别人听。然后，经过一个渠道以后，到另外一个耳朵里面开始解码，即人家的话我是否听得懂。

日常生活的沟通，人们很少出现歧义。原因是沟通信息简单，大家生活背景类似，而人类擅长于从上下文去解读这类信息。

假设A给B送礼，寒暄过后，

A：意思一下……

B：你这是什么意思？

A：没什么意思，就是意思意思。

B：我是那样的人吗？真不够意思。

尽管有那么多意思，但A和B都知道对方在说什么，如果说给外国人听，估计就要一头雾水。他们缺少了编码解码的思维背景。

实际工作中，沟通涉及到专业性，而沟通的人具有不同的思维背景，大家都倾向于从固有的认知里去理解事情。这样，在信息沟通的编码和解码方面，就很容易出现偏差。

产品经理在沟通上要做的事情是，搞清楚需求的目的是什么，从目的出发去理解需求方的描述是什么，梳理需求信息，跟需求方达成共识，最后给出解决方案。

2. 一次需求沟通经历

笔者经历过临时被拉进公司一个跨国、跨部门小项目的需求沟通，就遇到了由于专业背景的不同，导致对需求理解不一致的麻烦。

一开始海外营销的同事想升级公司的产品，增加一些功能，并采用指定的样式，以便更好地进行营销推广。

他们了解到产品是在购买授权的代码基础上二次开发的，从授权的官网有他们需要的功能和样式，这些是可以直接从后台安装的，只需要做一些调整。

他们不太懂技术，属于营销部门，于是找了公司国内部门的营销同事反馈这事情（这期间，海外、国内的同事在没有研发、没有产品人员介入情况下来来回回沟通，仍然没有什么进展）。

后来邮件转到了我和一位项目经理，考虑到他们之前的沟通基本上是纯文字，甚少截图，而且，海外同事用英文写，国内这边理解后又用英文表达，信息理解的一致性存在隐患。

果然，我将需求具象化后，画了线框图，跟他们逐一确认需求点，就发现了三个比较大的问题。

一是，存在双方理解的不一致，纯文字的表达方式，双方都以为对方明白他们的意思；

二是，由于思维模式和专业背景的不同，需求方有时没法将需求确切地表达清楚；

三，需求方对实现的评估往往只看到表面，不清楚内在的逻辑，导致大家对时间的评估存在分歧。

需求确认清楚后，产品经理要进一步想想需要是否合理，用各种维度去评估需求。通常，如果需求来自产品经理自己，要问问为什么？想要的目的是啥？是意淫的需求还是有数据支撑的需求？用户真的需要？一定要进入开发阶段才能解决？现有的方案能不能变通？等等。

如果来自其他人的需求，最直接的就是问问这种需求的目的是什么。因为有些时候，需求就一个，但解决方案可以多种多样。一旦到了出解决方案这一步，意味着人力和时间的投入。

产品经理要综合评估，寻找性价比最高的那种。这种把握很难，因为选择就意味着放弃，你永远不知道，当初不选择这个而用另一个的效果是怎么样的。说句皮一点的话，这完全靠产品经理的自我修养了。

3. 沟通链条

如果把需求从提出到实现的整个流传以产业链的角度看，产品经理的上游就是跟第三方对接用户需求，下游就是跟工程师沟通产品需求了。

从用户需求到产品需求，处于中游位置的产品经理就像一个输入输出设备的处理器，上游输入，中游处理，下游输出。

产品需求一般以产品需求文档（PRD）展现，载体嘛，有Word的、Axure的、Confluence的，具体看公司规范。形式是次要的，关键是文档的内容要写得细致无歧义，需要考虑逻辑完备、交互跳转、异常处理、初始状态等等。

需求到了这一步，产品经理就要直面传说中的程序员了。

网上经常有段子或者不着边际的视频，调侃产品经理和程序员的各种撕逼，大家当玩笑看就好了。实际工作中，产品经理和程序员大多相处愉快，没那么多狗血剧。

分工合作下，产品经理作为需求提出方，程序员作为需求实现方，天然存在沟通的必要。这里，产品经理又一次面临信息传递的编码解码过程。

和程序员的需求沟通会非常频繁，从需求评审到开发过程中的细节确认，从需求变动到技术实现的可能性，所有可能的环节都需要沟通，这部分，将在写需求管理的时候叙述。