需求采集的多种方法，包括访谈法、竞品对比法、体验法、观察法、问卷调研法和数据分析法，并强调了需求池管理的重要性，包括需求来源、类型、描述、价值、解决方案、优先级、状态及辅助信息的记录，旨在提高需求管理的效率和准确性。
需求采集的常用方法或来源
- 访谈法，通过交谈，沟通的方式获得需求，效率最高，信息密度最大
- 竞品对比法，通过对竞品功能的研究和理解，从发发掘当前产品还欠缺的功能
- 体验法，通过实际的接触对应的业务或者短暂的从事某个岗位，去收集需求
- 观察法，通过观察业务的实际发生情况来收集需求
- 问卷调研法，通过编写问卷、发放问卷等方式来收集用户的需求
- 数据分析法，通过对上线了的功能进行数据分析，从而得出还需改进的需求等
在需求采集的记录中要切记下述原则：
- 访谈记录，一定要保持原始记录的内容、表达方式；（录音）
- 哪些是访谈者的原话，哪些是记录者翻译之后的内容最好要作区分；
- 调研访谈之前最好做好对应的底稿，有目的地提问才能创造高质量的对话；
需求池管理必备字段
需求池是需求管理中非常重要的环节，需求池是需求的输出源，所有进入开发的需求都应该是从需求池筛选出来的。需求池还确保了需求不会遗漏以及后续追溯需求。需求的信息、类目繁杂，需要有一定的记录方式，才能够使得庞大的需求池多而不乱。不然到后期肯定乱。需求池需要记录的核心信息如下(但需要注意的是，需求池也并无模板，可以根据实际情况自行增减)：
需求来源
需求来源记录的是需求方是谁。常用的需求来源划分：产品规划、内部人员、业务部门反馈、用户反馈、产品数据表现、竞品分析、行业动态
1. 来自产品规划
作为产品经理，对产品需要有明确性的规划，清晰自己产品定位所在。并且依靠产品规划，制定不同阶段的产品目标，从而延伸出相对应的需求。
2. 来自产品内部人员
产品内部人员包括产品经理、研发、交互、设计、老板等，主要代指产研线上的角色。
产品经理：在日常迭代当中，产品经理有自己对于业务模块的思考，同时经过一系列的调研、数据等，能够发现自身产品的问题，提出需求。
研发、设计、测试等偏研发/设计侧的人员：站在自身对于产品的理解所提出的需求，更多的是单独模块，单独功能的优化。如调整主题色、调整客户端接口，优化页面交互方式等。
老板：一般是提出战略性、大方向的议题，不一定是具体的需求。如确定产品的发展方向，在与产品经理经过论证确保可行后，会分析拆解成具体的需求。
3. 来自业务部门反馈
业务部门通常包括运营、售前、售后、商务、市场、客服等。这些岗位都是离用户最近的岗位，也是产品经理“倾听用户声音”的重要途径之一。因此也会这些岗位也会结合用户的需求，以及产品可优化的部分去提出需求。
4. 来自用户反馈
用户反馈包括应用意见反馈、用户访谈、社区论坛、主动联系反馈等。倾听用户的声音对于产品，是很重要的。由此产品经理对内需要建立完善的用户反馈机制，对外需要搭建用户调研/访谈流程。
其中用户调研包括两种，定性调研和定量调研。
定性调研，主要调研文化背景与生活环境、用户的经验和习惯、探索用户行为背后的原因。最具代表性的是用户访谈。
定量调研，主要调研各个变量之间的关系，是通过各种数据呈现的客观事实。最具代表性的是问卷调查。
在倾听用户声音、用户访谈的过程中，需要注意的是进行信息的解析，也就是根据用户传递的内容，过滤掉失真的那部分，从而得出有效的结果，进而才能够转化成产品需求。
5. 来自产品数据表现
用户是会骗人的。但是他们的行为数据不会骗人，最大化的还原了用户的心态，选择。
作为产品经理，我们需要根据产品/业务本身的数据表现，发掘问题。从用户层面上来说，在产品当中进行数据埋点，通过用户在产品当中的行为，最大化地了解用户所遇到的问题。
通过宏观数据，查看用户在产品当中的行为；比如渗透率、留存、页面转化、人均次数等行为数据的变化，可以了解并分析用户在产品当中遇到的问题，从而形成需求并解决。
同时，用户的行为表现在数据上，通过这些，能够清楚用户的行为方式，用户的关注内容，当看得多了之后，会抽象出这个群体用户的行为特征，从而帮助产品经理更深入了解不同的用户群体。
要注意的是，产品的数据表现，并不能够单独来评判一个需求的启动与否，容易有失偏颇；往往需要结合用户调研，用户访谈，产品内部分析等方式加以评估。
6. 来自竞品分析
《孙子兵法》中提到“知己知彼，百战不殆”。这其中，“知彼”便是了解竞争对手。竞品做的不一定是对的，但是一定是“行出有因”。
作为产品经理，需要尽量多地汲取外部相关信息、行业信息，以辅助各种判断和决策。为了跟踪竞品动向，以他山之石鉴己之发展，同时也能够与竞争对手进行抗衡，通过竞争分析来提升产品的竞争力。
从产品的战略层面来看，竞品分析能够为产品提供战略、布局规划的参考，同时，在产品设计上取长补短，也能够预警避险。
通过竞品分析，了解到竞品的动向后，也可形成具体的产品需求，从而为产品的后续发展做好提前准备。
一般对于竞品分析，有两个方面可以收集。
a) 平时进行竞品的更新检测，了解竞品动向，收集产品需求。
b) 针对于个别业务/功能，对竞品进行针对性分析，输出竞品报告，抽象出需求点。
7. 来自行业动态、政策方向
根据行业的政策动向，也会延伸出相应的政策性需求。
通常政策性需求的优先级及紧急程度都是最高的，否则产品就会面临下架风险。
需求类型
不同团队对需求类型的划分维度不同，一般会按“新增、优化、缺陷”进行需求的划分。 新增：需从0到1进行开发的新功能；
优化：对已有功能进行优化
缺陷：由于业务或设计原因导致的问题
这样划分可以在后续进行需求规划时清晰地看到这个版本的重心到底是侧重新功能开发、还是优化已有功能和修复缺陷。
需求描述
需求描述是需求池最重要的元素，我们需要将之前收集的信息转化成清晰直观的文字进行记录。如果不能很好地对信息进行抽象，最好的方式就是将最原始的需求记录下来，而不要自己进行加工。与该需求相关的资料文档，可以单独建档进行保存，并将链接记录在对应的需求描述里面。
绝大多数用户无法分清楚事实、观点、需求、问题、解决方案……很多时候我给到的都是综合维度的信息，我们需要自己从中提炼出有价值的信息。
用户、需求、场景，吾日三省吾身。
需求描述中一个非常重要的点，就是一定要了解用户是谁、所处的场景，以及了解背后的问题到底是什么。刚开始和很多业务方沟通时，他们都很喜欢直接给我提功能需求，也就是跨过对需求的描述而自己预设一个解决方案。
进行需求描述时，一定要完整地了解用户、场景和需求，然后再对需求进行抽象并记录。缺乏场景的描述会让我们在进行后续产品设计时遗漏掉关键的细节和无法捕捉到更深层次的需求。
脱离角色谈需求，适用用户则不明确；脱离场景谈需求，则需求适用业务范围不明确；脱离路径谈需求，则业务流程不明确，因此PSP方法可以很好的帮助分析人员明确具体的需求。
在我构建的团队需求池里，会用“问题描述”代替“需求描述”，因为需求最终也是以解决问题为导向。“问题描述”会让团队成员有意识地去挖掘需求背后的问题，而不是当一个忠实的“需求记录者”。发现需求背后更深层次的问题、精准地定位问题、并提出行之有效的解决方案，这才是产品经理最大的价值。
比如客服同事会提出“我们需要一个备忘录的功能”，如果停步于此，记录下的就是“新增备忘录功能”。但我们并没有了解到客服同事到底遇到了什么问题，需要通过该功能解决什么问题。
再进一步沟通，才了解到客服同事希望通过备忘录解决以下问题：
在和电话沟通时，客户因为时间紧张没有这么多时间留给客服同事创建预约，需要临时记录下关键信息等通话结束后再给客户创建预约。
沟通过程中需要，对于一些提出了特殊要求的客户需要单独记录下来，以防自己忘记这些客户。
我们将需求进行抽象：
客服在与用户电话沟通时可以快速记录关键信息
客服在与用户电话沟通时可以单独对有特殊要求的客户进行备注
通过挖掘需求背后的问题以及场景，会发现客服同事还存在潜在的需求。客服同事使用备忘录时在与用户进行通话，所以要确保在通话界面能够快速调起备忘录，且不能影响正常通话。而第二个问题重点是对客户打标和备注，所以全局的备忘录并不是最优解决方案，单独对客户打上标签和备注能够更好地解决这个问题。
需求价值
很多时候因为模板的存在，反而会为了填写而填写。需求价值并不是所有功能都需进行填写。尤其是B端产品，很多功能都是为了支撑业务运转。而B端产品的功能价值无非是降本、增效、创收。对于孤立的功能点而言，很难说有多大的价值。
需求价值一般会在以下时候才会填写：
大的新功能，通过需求价值的描述评定该功能是否值得开发
对需求犹豫不决时，通过评定需求价值做决策
解决方案
一般会在对需求进行分析后进行填写。但在实际工作中，很多时候会下意识地在第一时间给到需求方解决方案，甚至需求方会直接提出解决方案。
对于比较简单和清晰明了的需求，快速给到解决方案并没有什么不可，在需求收集的同时给到解决方案反而节省了后续沟通的时间。所以需求池并没有严格地填写顺序，而是根据实际需求判断哪些需要后置填写，哪些可以即时填写。
产品是为了解决问题，但不是所有问题的解决方案都是通过产品解决。给到的解决方案也不一定是软件产品，也有可能是线下的业务流程调整或业务规则的变更。
需求优先级
要记住，需求优先级的本质是“性价比”
四象限原则
重要：以核心业务、核心用户、商业价值、竞争优势等方面去评估。这里总结了一个B端产品需求优先级中判断重要性的公式：重要性=人数×频率×节约时间×影响力
紧急：以严重程度、时间对比、需求频率等方面去评估。
那么按照时间管理四象限原则，就可以分为四个方向：重要且紧急、重要不紧急、不重要但紧急、不重要不紧急
重要且紧急：短期内一定要做的需求。通常是产品重大bug，政策需求，重点是“快且好”。
重要不紧急：重要但可以长期做的需求。比如某功能模块的规划等，重点是“有计划”。
不重要但紧急：对产品、用户的作用可能不大，但短时间内一定要完成的需求。
不重要不紧急：时间维度不敏感，且评估后重要性也低的需求。
当然，从四象限模型并不能够完全地解决现实中评估需求优先级的情况，需求优先级的评估需要结合更多的维度来判断是否紧急和重要。
需求状态
需求大的状态分为待处理、处理中、已处理、已搁置。
待处理是仅仅记录下来，还没有针对需求进行进一步处理的需求；处理中是进入到需求分析、设计中和开发中的需求；已处理是已经完成的需求；已搁置是指经过沟通评估后不做的需求。
结合团队的协作方式可以对状态进行细分，比如在之前团队需求池里我将“处理中”拆分为“需求梳理中、方案设计中、项目开发中”。当并行处理的需求比较多的时候，状态的进一步细分可以更直观清晰地管理需求。
提出人、提出日期、记录人
提出人、提出日期、记录人这些都是辅助信息，用于记录需求的最初提出方和记录方。当我们想要再次对需求进行深度了解时，可以通过这三个信息找到相关的需求方和跟进方。如果没有记录这些信息，当想针对某一个需求进行详细沟通时很可能几经波折才能找到最初始的需求方。
备注
备注当中一般描述字段以外的自由内容。可以添加相应与需求有关的材料，比如竞品调研、用户调研、当前业务数据等等，目的是为了更好的给这个需求做决策。
没有回复内容