产品经理如何做好需求收集？

收集需求是产品经理的基本工作；对初入行的产品经理来说，收集需求甚至是核心工作。那么，怎样才能把收集需求这项工作做好呢？

实际工作中，如果放任需求方提需求，则提上来的需求有时是一句话，有时是一张图，有时是一段录音，信息缺失常常特别严重。

若将这些信息作为需求收集起来，没有任何意义。信息严重不足的需求，产品经理无法进行需求分析，从而对需求做出判断。产品经理还得一个一个重新跟需求方沟通，不如不做。

因此，想做好需求收集工作，就需对提交的信息有一定的要求，来确保核心信息的完整性。有了这个要求，即使由于一些原因，需求提交者无法按要求提交（比如老板安排，就可能无法要求对方填个表），产品经理自己也可以通过沟通了解清楚相应的信息。

那么，一个提交上来的需求，需要包含哪些核心信息呢？

个人认为，一个需求至少要有这些核心信息。

每个信息项都有其相应的作用，下面是简单的解释。

• 需求简称：给每个需求起一个简单的名字，可以方便大家沟通。
• 需求提交者：知道是谁提交的，在需求不清楚的时候，能找到对应的人进行深入沟通。
• 提交日期：便于产品经理进行统计。同时，与期望完成日期对照，也便于产品经理了解需求的紧急性。
• 期望完成日期：可以帮助产品经理了解提交者的心理预期。
• 所在部门：需求提交者所在部门不同，对需求描述的倾向性会有所不同。了解提交者的部门，对后续需求判断会很有帮助。
• 优先级：优先级可以帮助产品了解此需求在提交者心中的重要程度。简单地分为高中低就好。更细致的划分，多数人区分不出来。
• 用户：每个需求一定有其用户。可以是某类用户，也可以是某个具体用户。若是某个具体用户或代表性用户，最好能够获取到对方的联系方式，以便于有需要时进行更深入的沟通。
• 场景：在场景中，需要告知用户在什么时候、什么地方、因为什么、做了什么事儿。可以说，这是需求的核心。描述的越细致越好。
• 问题：在上述场景下，用户遇到了什么困难/问题？是想做某事发现做不了，还是能做发现操作不便，还是做了但是没成功？描述的越详细越好。
• 当前解决方案：遇到问题/困难后，用户是怎么解决的？有可能，需求的解决方案就蕴藏在用户的解决思路或方案中。
• 希望解决方案：虽然，多数时候，用户给不出很好的解决方案，但了解对方的想法，能给产品经理提供不同的思路。
• 覆盖范围：有这个需求的人有多少？需求覆盖的用户范围不同，优先级会有不同。影响10个人和影响10万人，优先级绝对不是一个档次。
• 发生频次：这个需求发生的频次是多少？低频需求和高频需求，解决方案上会有很大的不同。高频需求要尽可能地提升效率和体验，低频需求可能就可以适当放宽。
• 当前方案耗时：如果当前解决方案可行，完成一次任务要花多少时间？对于提升效率的需求来说，当前方案的完成时间至关重要，是后续判断新方案是否有效的重要参照。
• 备注：若有需要补充信息，则可填写到备注中。

一个负责收集需求的产品经理，若其收集的需求的核心信息都能如上所述，整个产品团队在后续的需求分析上会非常高效。

本文素材来自互联网

（编辑：ASP站长网）