需求是产品工作的核心，产品就是为了解决需求而存在的，不夸张的说，产品对需求的理解处理直接决定了整个项目的成败。而产品的沟通能力直接决定了对需求理解的深度。因此，沟通能力是产品最重要的基础能力。
上一次我浅谈了和开发、设计的沟通方式，感兴趣的可以点击看一下《产品经理如何与程序猿沟通》《产品经理如何与设计和前端沟通》。通过这篇短文，分享一下如何与需求方沟通，希望自己的浅薄经验能对需要的人有所帮助。
一个完整的需求生命周期分为以下六步
第一、收到意向，提前准备
每次有需求的时候，多数时候会先邮件或是其他方式知会产品。接到需求后，第一时间应该去了解相关业务背景，有了这些准备后，在后续需求对称时才能更好的理解
第二、接收需求时，多问几个为什么，分析需求方的真正痛点
与需求方开会时，不能一味的接收需求，而是要多提问，有些需方是拍脑门想出来的，还有些需求方表达的东西和他期望的东西不一致。因此，作为产品经理，要学会引导需求方说出自己的真正意图，进而分解需求。最基础的问题：为什么需要这个功能？遇到了什么问题？这个功能的使用者是谁？了解使用场景，分析需求的真实目的，确定需求的真伪。在沟通中，一个重要的技巧是：提问的时候最好用选择题，尽量避免问答题。
第三、需求调研，竞品分析
和需求方开会讨论完需求后，即表示需求接收完成，进入第二步，需求分析调研。调研使用者的想法，然后寻找同行竞品，从竞品中你可以得到这个功能的常用或是公用规则，然后结合自己项目的特色，融入自己的元素。不要轻易挑战习惯，虽说最成功的产品就是改变用户习惯，生成新的规则，但这个是需要天时地利的外部环境，以及公司和产品本身的实力，功成者寥寥无几。。。
第四、输出方案，与需求方评审
根据项目开发时间，输出相应时间的解决方案，同时把后续扩展方案也要考虑进来。常用的是思维导图、业务流程图和功能流程图。先给需求方看思维导图，简单直观的让对方确认是否有遗漏。然后是业务流程图，一般的需求方对业务是比较了解的，甚至比产品还熟悉，因此这个对他们来说是重点，从这里，需求方就可以大致了解到你的方案是否符合他的需求；最后是功能流程图，其实与业务流程图有点相似，甚至有些产品工作很久之后，对业务流程和功能流程还傻傻分不清楚。在业务流程没有问题的情况下，产品就需要和需求方确认逆向流程及不太确定的功能点。到此，和需求方的对称基本完成一半了。这里有一个重点，需要产品提前去做，就是和需求方评审前，如果条件允许的话，最好先和技术沟通，确保这些功能是技术可以实现的，如果技术能大概给个时间，那就更好了。
第五、功能列表和原型输出，需求方和技术评审
功能列表和原型输出后，先给需求方评审，通过后，即可进入技术评审了，包括设计，前端、后台及测试，预估开发时间，反馈给需求方，需求方确认后，根据优先级和技术安排开发排期，然后输出需求文档。
第六、项目跟进并向需求方汇报，验收宣导
进入开发阶段后，产品的工作量就小了很多，只需负责跟进，实时解决开发中遇到的一些需求不明确问题，并定时向需求方汇报项目进度。当项目进入测试阶段，输出操作手册，并开会宣讲。最后需求方验收，功能正式上线。
总结：沟通贯通了整个产品周期，与需求方的沟通又是重中之重。在产品工作中，应该要主动积极的和需求方沟通，而不是被动接收需求。
在其他文章里我分享了与设计和开发沟通的内容，感兴趣的可以看一下
