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

　　收集需求是产品经理的基本工作；对初入行的产品经理来说，收集需求甚至是核心工作。那么，怎样才能把收集需求这项工作做好呢？
　　实际工作中，如果放任需求方提需求，则提上来的需求有时是一句话，有时是一张图，有时是一段录音，信息缺失常常特别严重。
　　若将这些信息作为需求收集起来，没有任何意义。信息严重不足的需求，产品经理无法进行需求分析，从而对需求做出判断。产品经理还得一个一个重新跟需求方沟通，不如不做。
　　因此，想做好需求收集工作，就需对提交的信息有一定的要求，来确保核心信息的完整性。有了这个要求，即使由于一些原因，需求提交者无法按要求提交（比如老板安排，就可能无法要求对方填个表），产品经理自己也可以通过沟通了解清楚相应的信息。
　　那么，一个提交上来的需求，需要包含哪些核心信息呢？
　　个人认为，一个需求至少要有这些核心信息。
　　每个信息项都有其相应的作用，下面是简单的解释。
　　需求简称：给每个需求起一个简单的名字，可以方便大家沟通。
　　需求提交者：知道是谁提交的，在需求不清楚的时候，能找到对应的人进行深入沟通。
　　提交日期：便于产品经理进行统计。同时，与期望完成日期对照，也便于产品经理了解需求的紧急性。
　　期望完成日期：可以帮助产品经理了解提交者的心理预期。
　　所在部门：需求提交者所在部门不同，对需求描述的倾向性会有所不同。了解提交者的部门，对后续需求判断会很有帮助。
　　优先级：优先级可以帮助产品了解此需求在提交者心中的重要程度。简单地分为高中低就好。更细致的划分，多数人区分不出来。
　　用户：每个需求一定有其用户。可以是某类用户，也可以是某个具体用户。若是某个具体用户或代表性用户，最好能够获取到对方的联系方式，以便于有需要时进行更深入的沟通。
　　场景：在场景中，需要告知用户在什么时候、什么地方、因为什么、做了什么事儿。可以说，这是需求的核心。描述的越细致越好。
　　问题：在上述场景下，用户遇到了什么困难问题？是想做某事发现做不了，还是能做发现操作不便，还是做了但是没成功？描述的越详细越好。
　　当前解决方案：遇到问题困难后，用户是怎么解决的？有可能，需求的解决方案就蕴藏在用户的解决思路或方案中。
　　希望解决方案：虽然，多数时候，用户给不出很好的解决方案，但了解对方的想法，能给产品经理提供不同的思路。
　　覆盖范围：有这个需求的人有多少？需求覆盖的用户范围不同，优先级会有不同。影响10个人和影响10万人，优先级绝对不是一个档次。
　　发生频次：这个需求发生的频次是多少？低频需求和高频需求，解决方案上会有很大的不同。高频需求要尽可能地提升效率和体验，低频需求可能就可以适当放宽。
　　当前方案耗时：如果当前解决方案可行，完成一次任务要花多少时间？对于提升效率的需求来说，当前方案的完成时间至关重要，是后续判断新方案是否有效的重要参照。
　　备注：若有需要补充信息，则可填写到备注中。
　　一个负责收集需求的产品经理，若其收集的需求的核心信息都能如上所述，整个产品团队在后续的需求分析上会非常高效。