作为一名产品经理，你是如何收集需求的？当然每个人都会有自己独特的方法，而我也学习了自己的产品需求收集方法，帮助我更好的和用户对话，同时获取用户真正的需求。

在我以往读过的产品相关书籍中，了解了需求收集相关的名词，“引出”和“捕捉”，这样的术语似乎暗示着我们：需求就在某个地方，我们需要做的就是让客户向我们解释，然后我们按照用户讲述的进行归纳整理，生成软件需要开发的需求，但是用户作为非互联网专业人士，也不会已经知道所有的需求，单纯只是依靠“引出”也是不够的。

之后我们引入“拖网”这个需求收集术语，用来描述收集需求的过程，类比为海上渔民捕鱼，首先：网格大小尺寸不同的拖网可以用来捕捉大小不同的需求，第一遍在需求池里用最大尺寸网格的拖网来捕捉所有最大规模尺寸的需求，继而在这些大规模的需求中总结生成要开发产品的大致结构图。然后：用较小尺寸网格的拖网进行后续的捕捉，并获得中等规模尺寸的需求，最后：就是使用最小规模尺寸的需求，这里面网格捕捉大小的需求规模，大多由商业价值和公司业务方向大致筛选。

因为需求收集是贯穿在产品开发的整个过程，所以我们需要一套可以反复使用且轻量级的方法来收集他们。具体的需求收集方法大致可以分为以下几种：

1、用户访谈

2、问卷调查

3、观察

4、场景法

用户访谈

用户访谈是许多团队用来收集用户需求的默认方法，可能你在收集需求时会不假思索的想着深入用户群体，和他们打成一片，和他们通过更多的言语交流，收集用户关于产品功能等的需求，但是访谈成功的关键之一是选择正确的受访者，且将受访者覆盖不同的用户角色。

然而，在用户访谈的方法中，获得用户需求本质的技巧就是提问，我曾经看到提个案例：他们在将应用程序开发成Web端或者移动端之间徘徊不前。基于浏览器的版本易于部署，功能更方便的移动端在操作方面会受限于设备降低用户体验，项目团队在二者之间难以取舍，他们预测用户会喜欢浏览器的优势，但是他们也看中移动端的便捷，然后就和用户取得联系，询问：你想在浏览器中使用我们的新应用程序吗？

这个问题本身就存在问题，因为他是封闭式的，用户除了简单的“是”或“否“之外，没有任何其他的选择余地。所以在和用户直接对话过程中提出能让用户表达自己意见的开放式问题要比之前者要好很多，例如：”为了让我们新一代产品能够在浏览器中运行，您愿意放弃什么？“。回答这个问题的用户可以从多方面多角度来回答，无论用户怎么回答，都将对我们提供更有意义的答案。

所以我们在用户访谈环节中进行产品需求的调研，需要把握好主要的两点：选择正确的受访者、提问题偏向开放式问题。

问卷调查

问卷调查时一种有效的方法，有助于收集已有的故事信息。如果用户人数众多，那么调查问卷可以成为获取产品需求优先级的好方法，当需要大量用户针对特定问题的答案时，温泉调查同样可以用到。

但是问卷调查 的问题毕竟是静态的，不适合跟踪问题，同时也本可能让用户沿着有兴趣的方向深入探讨。

同时问卷调查有可能会因为里面的问题等原因，拉低获提升不同需求的优先级，造成开发进度不能根据最刚需的需求线路开发项目。

观察法

观察用户实际使用软件能够深入洞悉用户。但是在符合场景的情况下，我们要带着问题去观察，例如：关于如何改进用户的体验、生产率、或者两者兼顾的想法。

之前看到一则观察法相关的案例，大致内容为：一家公司的用户在呼叫中心工作的客户，客服在回答来电者提出的问题时表示，他们需要一个大的文本字段，用于在通话结束时记录通话结果，该软件的第一个版本在通话结束后屏幕上会显示一个完整的文本。但是，在最初的发布之后，开发团队的成员花费数天的时间来观察客服，发现用户真正的需求时需要徐彤跟踪记录客服在使用软件时做出的决定。之后对软件进行了迭代，文本相关的内容被日志记录客服选择的所有搜索项和建议项所取代。跟踪记录来电者的所有说明，这个真正的需求被客服的需求描述所掩盖，而这一点事需要通过观察才能发现出来的。

场景法

场景法是基于用户画像为基础，通过观察，访谈等方法筛选确定产品的目标用户在使用产品时的真实场景，然后在根据不同的用户使用场景来规划产品的具体功能、用户使用路径等信息，但是在编写完善场景时，第一：很容易会带入自己的思维，行为等情况，第二：可能会有许多用户场景的细节没有考虑到位。这个时候就需要进行基于用户使用场景进行开会研讨，聚集大家的想法，客观的分析用户使用场景，完善用户使用场景。

以上为比较灵活且常见的产品需求调研收集方法，如有不足，谢谢补充，本人也会在不断的学习积累中不断更新。