产品经理如何做好需求收集？6个步骤11种技巧
需求收集是需求管理的第一步，有需求了才能进行需求分析，因此做好需求收集至关重要。
一、什么是需求收集
需求收集（Requirement Gathering）是软件开发、项目管理或产品设计中的一个关键步骤，目的是明确和记录所有相关方（如客户、用户、开发者等）的需求和期望。据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。
二、需求收集的重要性
据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。完善的需求收集流程除了可以明确我们的开发目标，其重要性还包括：
- 大大提高客户和用户能得到他们想要的东西的可能性。利益相关者通常很难用言辞准确地描述他们需要的东西。通过需求收集过程，我们可以帮助他们更深入地挖掘和理解自身的需求。
- 减小了项目失败的风险。在许多项目失败的案例中，一个常见的问题就是"需求定义模糊"。
- 在开发前期发现并解决需求问题，可以降低整个项目的成本。需求表述模糊或者定义错误往往会导致返工问题。许多研究都表明，随着开发过程的推进，修正需求错误的成本会呈指数式增长。
三、需求收集的方法和工具
在大多数情况下，需求提出者（如客户、用户等）可能不完全了解在开发特定产品时所有的可能选择。因为他们深陷于当前的工作状态或环境，他们的视野可能受到限制，难以脱离他们现在的方式，想象出与当前状态完全不同的解决方案或产品特性。
此外，并不存在一劳永逸的需求收集技术。我们不可能使用万能需求收集技术可以保证所收集的需求完整且经得起验证。
因此，采取多角度、多种方法的策略进行需求收集是更有效的做法。这意味着根据需求收集过程的不同阶段和环境，灵活地使用不同的技术和方法。这些可能包括访谈、问卷调查、用户观察、文档分析等等，从而使得收集到的需求更为全面和准确。
1.访谈
通过采访，我们可以收集到许多重要的背景信息，包括商业需求、客户和用户遇到的问题，以及支持人员和其他相关利益相关者的关注点。在进行需求收集的采访时，需要确保采访的对象覆盖了系统利益相关者的多样性和代表性，包括各种类型的客户和用户。采访时应尽量提问开放式问题，这些问题不能仅用“是”或“否”回答，需要被采访者详细阐述他们的想法和理由。这样的问题有助于提取更深层次的信息，并为评估和验证需求提供必要的背景。
2.问卷或调查
组织个人访谈时我们会面临一系列问题，比如：等待排期要花费很多时间；获取的需求太表面；并不是每个人都善于回答所跟进的问题。
问卷调查或调研可以作为一种高效的替代方案，可以同时跟进多个利益相关者。
3.观察法
理解用户真正需求的最好方式之一是观察他们的日常行为。
观察用户可以主动进行，即在观察用户行为的同时，向他们提问以理解他们当前的工作流程；也可以被动进行，如收集用户对设计原型的反馈。
在进行用户观察时，要对他们的行为和活动进行详细记录。注意哪些问题在困扰客户，要关注用户频繁遇到的难题。
通过实地观察用户在真实环境中如何执行任务，可以深入理解他们所面临的挑战和需要改进的地方。只有抓住问题所在，我们才会知道如何改进用户的工作流程，继而提高他们的生产力和效率。
除此以外，还有文档分析、界面分析、头脑风暴、研讨会、角色扮演、用例和场景、焦点小组、原型制作等方法。详细介绍大家可通过我们另外一篇文章查看《11 种需求收集技巧》
四、需求收集的六个步骤
需求收集包括六个步骤通常按顺序进行，但在实际操作中，可能需要重复或者反复“迭代”。因此，最好将其视为子流程而非严格的线性步骤。
完整需求收集六个步骤包括：
- 确定相关利益相关者
- 确立项目目标和目的
- 从利益相关者中提取需求
- 记录需求
- 确认需求
- 优先处理需求
1.确定相关利益相关者
根据项目的不同，我们需要在每个利益相关者群体中寻找合适的代表，可能包括如下群体：
- 客户利益相关者
- 决策者
- 用户
- 系统管理员
- 其他相关的客户部门
- 内部利益相关者
- 行政人员
- 工程团队
- 营销团队
- 销售团队
- 客户支持团队（可包括现场维护团队）
- 主要供应商
- 分销商和其他合作伙伴
也要寻找那些“隐形”的利益相关者。在正式开始需求收集之前，团队也可在早期会议中提出探索性问题。确保所有利益相关者群体都参与其中。理想情况下，要给每一个参与方提出自己观点、表达自己需求的机会。
2.明确项目目标
你希望通过这个新产品或项目达到什么目标？你的客户希望从产品中获得什么总体结果？你公司的业务目标是什么？为了实现这些目标和结果，你需要实现哪些可行的、可衡量的目标？
把它们写下来。清楚地陈述它们，并让你所有的利益相关者对它们签字。你的目标和目的将作为你决策的框架。
你写的每个需求都应该帮助满足项目目标并达成目标。如果没有，你应该放弃它，或者将它作为未来发布的候选者。
3.从利益相关者那里获取需求
需求获取是需求收集子流程的第一个，在实际操作中会有重叠且需要不断迭代。即使在敏捷开发中，在项目开发之前可能也需要经历几轮的需求收集、文档记录以及审查和确认。
需求收集的方式有很多种，可行的方法包括调查、问卷调查以及访谈。在后续的迭代中需要经常组织访谈和跟进会议。
在访谈中要积极倾听受访者。提出探索性问题，并做好笔记。访谈结束后，要整理笔记，并在需要时进一步跟进。
4.记录需求
我们需要将收集到的需求记录下来。可采用任何已经协商达成一致的格式，它们可以是产品需求文档（PRD），政府要求的系统需求规范说明、需求管理工具（如PingCode）、电子表格、数据库或其他方便团队成员查看的数据存储形式。
重点是需求文档，它需要以下要求：
- 易于理解和浏览
- 所有的利益相关者都可以随时访问和查看
- 提供了对其他文档的可追溯性
- 使用标准化的格式和模版
5.确认需求
与所有利益相关者一起审查需求，确保需求准确地反映了预期的目标，并确保所有利益相关者对每一个需求都理解一致。如果发现表述模糊的地方，应及时调整。
如果条件允许，可以利用原型设计和测试来验证需求。使用原型制作工具，能够简单快速地制作出原型，我们利用这个模型来进行可行性、可用性和产品概念的测试。
让利益相关者对需求进行签字确认。在最后的审查阶段，整个规范说明也要签字确认。
6.需求优先级排序
大多数开发项目在途中都会遇到意想不到的挑战，会遇到意想不到的障碍。时间表可能会变化，优先级可能会改变。每个需求将影响你的版本的目标，所以进行优先处理非常关键。
许多产品经理通过给功能打上“必须有”、“迫切想要”和“有也很好”等标签来确定其优先级。这样做主要基于以下两个原因：
首先，项目时间有限。如果团队优先实现相对简单的需求，最后发现没有足够的时间来完成关键需求，就会影响产品的发布时间。
其次，需求在变化。随着项目开展，可能会出现新需求。这些新需求可能非常关键，需要优先处理。我们要权衡新需求在优先级顺序中的位置。否则，我们可能会优先处理相对不太重要的需求。
五、需求收集过程中常见的问题
1.想当然的去理解我们听到的内容
有时候，有些需求简单且宽泛，面对这些需求你需要警惕，不要想当然的以为自己已经完全理解利益相关者所要表达的意思，也不要以为所有利益相关者的表述方式都一样。
例如，像"网站应有博客"这样的需求陈述可能隐藏了很多潜在的假设。应仔细思考这样的需求陈述，并提出相应问题，例如：帖子将以何种方式展示？谁管理这些帖子？是否需要评论功能？是否需要对帖子进行分类或打上标签？等等。
通过提出这些问题并对收到的答案进行交叉核查，我们就可以得出一组更具体，并且可被验证的需求。
2.关注 HOW 而不是WHAT
需求可以分为两大类：一类是产品需要实现的功能需求，即产品需要做什么；另一类是对产品实现功能的方式和形式的约束，即非功能性需求。
在需求管理阶段，我们的重点应该更多地放在产品需要做什么，而不是如何去实现。换句话说，需求描述尽可能不要涉及其实现方式，例如应该使用哪一项新技术，偏好哪种工具，以及对产品的一些个人预设期待。总之，我们需要专注于利益相关者需要什么这个问题。
首先，我们要认真听取利益相关者的意见，然后收集、审查这些意见并提炼出需求。在完成这些步骤之后，再去分析使用哪些技术手段可以满足客户和利益相关者的真正需求。
3.未能充分与利益相关者沟通
在需求收集过程中，充分与利益相关者沟通至关重要。
首先，对每个利益相关者群体的需求都要深入了解。忽视这一点是需求管理失败的主要原因之一。
其次，保持项目透明度。每次访谈、开会或调查后，都要整理并共享笔记。现代需求管理工具，如PingCode，可将注释附加到需求上，保证需求的可追溯性。可帮助我们大幅提高工作效率，同时减轻审核工作量。
第三，给利益相关者充足的时间去审查需求。给他们提供反馈、表达异议，甚至捍卫自己的观点的空间。讨论越深入就越能帮助我们发现并修正需求中存在的问题，同时也有助于所有利益相关者就需求达成一致意见。
最后，确保所有利益相关者确认并签署需求。也要让利益相关者清楚签字确认意味着什么。
推荐阅读：
做好需求分析的4大关键认知 | 盘点国内9款热门需求管理系统 | 构建产品路线图的方法与工具 | 做好需求优先级判断的7种主流模型 | 采用敏捷方法进行需求管理 | 更多