产品经理如何与需求方沟通

需求是产品工作的核心，产品就是为了解决需求而存在的，不夸张的说，产品对需求的理解处理直接决定了整个项目的成败。而产品的沟通能力直接决定了对需求的，因此，沟通能力是产品的最重要的基础能力。

上一次我浅谈了和开发的沟通方式，感兴趣的可以点击看一下《产品经理如何与程序猿沟通》通过这篇短文，分享一下如何与需求方沟通。

第一、收到意向，提前准备

每次有需求的时候，多数时候会先邮件或是其他方式知会产品。接到需求后，第一时间去做了解相关业务背景，有了这些准备后，在后续需求对称时才能更好的理解

第二、接收需求时，多问几个问什么，分析需求方的真正痛点

与需求方开会时，不能一味的接收需求，而是要多提问，有些需方是拍脑门想出来的，还有些需求方表达的东西和他期望的东西不一致。因此，作为产品经理，要学会引导需求方说出自己的真正意图，进而分解需求。最基础的问题：为什么需要这个功能？遇到了什么问题？这个功能的使用者是谁？了解使用场景，分析需求的真实目的，确定需求的真伪。在沟通中，一个重要的技巧是：提问的时候最好用选择题，尽量避免问答题。

第三、需求调研，竞品分析

和需求方开会讨论完需求后，即表示需求接收完成，进入第二步，需求分析调研。调研使用者的想法，然后寻找同行竞品，从竞品中你可以得到这个功能的常用或是公用规则，然后结合自己项目的特色，融入自己的元素。不要轻易挑战习惯，虽说最成功的产品就是改变用户习惯，生成新的规则，但这个是需要天时地利的外部环境，及公司和产品本身的实力，功成者寥寥无几。。。

第四、输出方案，与需求方评审

根据项目开发时间，输出相应时间的解决方案，同时把后续扩展方案也要考虑进来。常用的是思维导图、业务流程图和功能流程图。先给需求方看你 的思维导图，简单直观的让对方确认是否有遗漏。然后是业务流程图，一般的需求方对业务是比较了解的，甚至比产品还熟悉，因此这个对他们来说是重点，从这里，需求方就可以大致了解到你的方案是否符合他的需求；最后是功能流程图，其实与业务流程图有点相近了，甚至有些产品工作很久之后，对业务流程和功能流程图傻傻分不清楚。在业务流程里没有问题的情况下，产品就需要和需求方确认逆向流程及不太确定的功能点。到此，和需求方的对称基本完成一半了。这里有一个重要点，需要产品提前去做，就是和需求方评审前，如果条件允许的话，最好先和技术沟通，确保这些功能是技术可以实现的，如果技术能大概给个时间，那就太好了。

第五、功能列表和原型输出，需求方和技术评审

功能列表和原型输出后，先给需求方评审，通过后，即可进入技术评审了，包括设计，前端、后台及测试，预估开发时间，反馈给需求方，需求方确认后，根据优先级通技术安排排期，输出需求文档。

第六、项目跟进并向需求方汇报，验收宣导

进入开发阶段后，产品的工作量就小了很多，只是负责跟进，实时解决开发中遇到的需求清晰的问题，并定时向需求方汇报项目进度。当项目进入测试阶段，输出操作手册，并开会宣讲。最后需求方验收，功能正式上线，

总结：沟通贯通了整个产品周期，与需求方的沟通又是重中之重。在产品工作中，一定要主动积极的去和需求方沟通。