产品团队的需求获取指南

一个开发项目要想成功，关键在于理解商业需求，并且确定正确的项目需求列表。需求获取就是通过与关键利益相关者（例如，项目经理、开发人员、最终用户等）进行沟通和协作，以获得项目的深入理解并确定项目的需求。

文章将进一步讨论为什么需求获取对产品团队（包括产品经理、开发人员等）如此重要，将探讨不同的需求获取技巧（即采用的方法和工具），并概括需求获取过程涉及的各个步骤（例如从初始的需求搜集，到需求的验证和确认，等等）。

一、什么是需求获取?

需求获取是指在软件开发、产品设计或项目管理过程中，挖掘和获取有关用户、客户或利益相关者需求的信息和数据的过程。它旨在识别和收集有关系统或产品功能、性能、约束和其他需求的详细信息，以满足用户的期望和需求。需求获取的主要目标是获得准确、全面和可理解的需求，为后续的需求分析、系统设计和开发提供基础。需求获取过程做的不好可能会导致系统缺陷甚至返工。

二、需求获取对产品团队的重要性

需求获取对产品团队至关重要，因为这是确定产品需求的主要途径。获取过程可以让我们从关键利益相关者那里揭示需求的内在含义。包括与领域专家深入交谈，精准提出问题，以及详细记录调研结果等专业技巧，来获取推动项目开展的业务需求。

如果未能正确地识别和理解业务需求，可能会导致开发成本超支，以及设计需要修改或者项目返工等问题。用户或客户无法得到他们真正需要的功能，最终可能导致项目失败。

三、需求获取的过程

有效的需求获取过程给产品团队带来的益处：

降低项目成本：通过在开发开始之前发现和解决需求问题，可以避免后期的返工和修正，从而降低项目的成本。通过准确获取需求，团队可以在项目早期就进行合理的规划和资源分配，从而提高效率并节约成本。
增加用户满意度：通过有效的需求获取，团队可以深入了解用户的期望和需求，提高产品与用户期望的匹配度，尽最大可能满足用户需求，从而提升用户体验，增加用户满意度和忠诚度。
降低项目失败的风险：需求获取是识别和理解项目需求的关键过程。通过与利益相关者进行良好的沟通和协作，可以清晰的定义需求，有助于团队在整个项目周期内明确要实现的目标，合理规划工作，并减少不确定问题的出现、降低项目风险。

需求获取过程通常包括以下五个主要步骤：

1.需求收集

可能有人会疑惑：“需求获取和需求收集有什么区别？”这两个术语经常交替使用。虽然这两个词在一定程度上可以互换使用，但在论及需求获取过程具体操作时，需求收集和需求获取之间存在细微的差异。

按照定义，“收集”通常指的是从多个分散的信息来源中整理信息，而“获取”则更倾向于从某个特定的来源中提取信息，这两个操作都必不可少，都需要专业的知识和技能。

在准备阶段，业务分析师要从所有可能的源头收集需求，并对这些需求深入研究。需求收集的技术可能包括：

文档分析，例如研究流程模型或法规要求
分析系统接口和业务规则
查阅现有的用户反馈等

通过需求收集，可以识别出关键利益相关者，以及确定哪些需求获取技术最适合本项目。然后，业务分析师可以根据经验来填补空缺的需求。因此，需求收集是需求获取过程的起点。

2.识别关键利益相关者

如上所述，需求收集有助于识别关键的利益相关者。在项目的初期确定正确的利益相关者至关重要，可以避免在项目进展过程中发现需求缺失，从而影响项目进度。

3.需求获取

头脑风暴

适用场景：当前解决方案缺乏创新，无法达成项目目标。

目标：探索富有创意的思路和解决方案

操作步骤：邀请主要利益相关者一起探讨解决方案。作为引导者，业务分析师需要确保讨论始终围绕主题展开，并对讨论的结果进行记录。

焦点小组

适用场景：当业务分析师需要在有限的时间内获取特定信息时。

目标：帮助利益相关者更加坦诚和清晰地提出解决方案，一次获得大量信息。

操作步骤：组织利益相关者的代表形成焦点小组。主持人提出问题引导小组成员就特定的话题进行讨论，并记录讨论结果。

访谈

适用场景：从特定主题专家处获取深入的观点

目标：通过与利益相关者一对一交谈，获取他们对业务需求的看法或对解决方案的可行性见解。

操作步骤：提出问题让主题专家开放式作答。问题可以提前发给他们，也可以在对话进行时提出。采访者应作会议记录并与主题专家分享，以确保与他们的观点没有出入。

观察法

适用场景：当开发的项目是现有工作流程的扩展时。

目标：直接观察利益相关者如何执行特定流程。

操作步骤：观察可以被动地进行，也就是说在不打扰利益相关者的情况下观察他们的工作; 或者主动地进行，即在观摩利益相关者工作时进行提问。在两种情况下，都应记笔记，并让利益相关者对所收集到信息进行反馈。

原型设计

适用场景：当利益相关者无法理解书面形式的的技术需求，必须要通过产品的一个版本来演示时。

目标：通过观察利益相关者与产品示例的互动，来收集他们的反馈。

操作步骤：可以采用故事板、交互式屏幕、虚拟模型、导航流程等方式进行原型制作。根据项目不同来选择适合的展示方式，通常都是通过迭代流程进行制作。随着更多需求的提出，为了满足客户期望，在原型的基础上会加入更多细节。

需求研讨会

适用场景：时间紧迫且业务需求不明确时。

目标：在特定时间内，将利益相关者集中起来，以引出、提炼和编辑需求内容。利益相关者可以针对已确定的业务需求进行讨论，并立即给出反馈。

操作步骤：为研讨会设定清晰的时间框架和议程，包括头脑风暴、焦点小组和原型制作（如适用）等内容。利用这些机会来引导利益相关者讨论并记录他们的观点。

调查

适用场景：当业务分析师需要从大量参与者那里收集数据时。

目的：从大量客户或终端用户中收集客观的反馈。

操作步骤：根据标准选择参与者，创建清晰、无导向的问题。问题可以是多项选择题或开放式问题。为保证效果，需要根据提问的目的以及受访者的数量来决定分析结构。

在实际操作中，业务分析师通常会采用多种需求收集技术来深入挖掘项目的业务需求。例如，业务分析师可能会在焦点小组上、头脑风暴会议中或观察期间提出关于需求的问题，也可以在需求研讨会前进行调查，或者在观察期间展示产品原型。要凭借我们的经验和判断力来决定哪些方式最适合特定项目的需求收集。

4.记录需求

下一步是记录已收集到的需求。需求记录的形式多样，包括但不限于产品需求文档（PRD）、政府规定的系统需求规范、需求管理工具（如PingCode）或电子表格。记录需求的方式取决于需求类型。

在利益相关者数目庞大、开发流程复杂、合规性要求繁琐或功能安全标准严格的项目中，建议使用需求管理工具，例如PingCode等。这些工具可以降低由于系统复杂和合规性要求严格所带来的相关风险。

5.确认发现结果

记录需求后，业务分析师需要确认对需求的理解没有出入。这些需求文档应发送给所有利益相关者进行审查，以确保所有人所要开发的内容理解一致。利益相关者可能会提出修改建议，从而启发新的需求，那么我们在批准前就需要对文档进行修改。

需求获取过程从项目启动时开始，一直贯穿整个开发过程。因为变更不可避免，我们不可能提前预知所有问题和所有正确答案。

四、获取需求面临的挑战

在需求获取过程中，可能会遇到的挑战有：

找到正确的利益相关者：有时会我们并不能顺利的确定正确的领域专家。“隐藏”的利益相关者可为是我们提供宝贵的信息，例如面向客户的销售/支持代表和维技术维护人员。

挖掘真正的需求：利益相关者有时候并不知道他们想要什么。在需求获取过程中，需要使用多种方法来识别真正的业务需求。需要使用适合特定项目的最佳技术组合。

记录需求：使用不适合的工具记录需求可能会影响工作流程。从审查和批准再到变更管理，所有环节都可能出现问题。小型项目或不受监管的项目可用电子表格或定制的产品需求文档（PRD）。然而，对于复杂的产品或受严格监管的产品，需求管理软件（如PingCode）则可以提供实时追踪和合规性管理等功能，从而简化需求获取的整个流程。

为变更做好准备：需求会发生变更，需求优先级也可能会发生变化。最好提前为变更做好准备。确保有既定流程、足够的时间来解决问题、记录变更、添加新需求，以及进行额外审查。

在需求变动较少或规模较小的项目中，使用电子表格或产品需求文档（PRD）来管理需求变更或许可行，但是这种方式可能需要花费大量时间，有可能导致项目预算超支或延期。

对于复杂产品或受到严格监管的产品项目，需求管理不善可能会造成时间和资金浪费。在这种情况下，我们就必须使用功能强大的需求管理工具，如PingCode，这类工具可以在需求发生变化时，可帮助我们更高效地管理需求，节省宝贵时间和预算。