如何做好需求收集？方法和步骤

需求收集是理解你想要构建什么以及为什么要构建它的过程。需求收集通常被视为开发软件应用，或开发硬件产品的一部分。其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。

一、需求收集为什么会困难？

困扰项目组需求收集活动的原因可能如下：

1.遗漏了正确的利益相关者：在项目中，常常存在一些“隐藏”的利益相关者。除了明显的决策人员，也应包括那些与客户直接交互的角色，例如客户服务代表和维护工程师，他们实际上也是产品的使用者。除此以外，在需求收集过程中，我们可能会遗漏掉需要提问的问题，或者有些信息利益相关者忘记告诉我们。这就导致需求的优先级可能会发生变化。

2.用户往往不清楚自己的真实需求是什么：利益相关者可能并不了解自己的需求。他们可能无法将自己的需求完全表述出来，还有一些需求有待我们发掘。我们要尽可能提出更多试探性的问题，并对不同的回答进行对比。往往需要通过多轮“迭代”，才能最终达成共识。

3.需求记录不规范：收集的需求没有规范记录下来，造成原始信息丢失或失真，且无法回溯等等。

除此以外，还有比如：需求收集人员只关注用户反映的表面问题；需求收集人员考虑的问题时“以产品为中心”，而不是“以客户为中心”等等

二、一个好的需求收集的重要性

完善的需求收集流程除了可以明确我们的开发目标，其重要性还包括：大大提高客户和用户能得到他们想要的东西的可能性。因为利益相关者通常很难用言辞准确地描述他们需要的东西。通过需求收集过程，我们可以帮助他们更深入地挖掘和理解自身的需求。减小了项目失败的风险。在许多项目失败的案例中，一个常见的问题就是”需求定义模糊”。在开发前期发现并解决需求问题，可以降低整个项目的成本。需求表述模糊或者定义错误往往会导致返工问题。许多研究都表明，随着开发过程的推进，修正需求错误的成本会呈指数式增长。

三、做好需求收集的六个步骤

需求收集过程中的关键部分可以分为三个交叠的子过程：需求获取、需求文档编写和需求确认。

需求获取：这是需求收集过程的首要步骤，通过与利益相关者进行沟通，了解他们对于产品或服务的需求和预期，形式包括：会议、访谈、问卷调查等。你应尽力考虑客户、他们的用户、你自己公司内部的利益相关者以及你的关键供应商的需求。

需求文档编写：将需求收集过程的输入内容组织成适合你的组织的任何格式。这种格式可能包括：

用户故事
功能分解
功能说明

这些将被收集在一个需求规范中，比如产品需求文档（PRD）或系统规范。这个规范的目的是让项目团队的所有成员都能查阅到这些故事和描述。

需求确认：是确认所记录的需求如实反映了利益相关者的需求和预期的过程。通常要从利益相关者那里得到反馈，以确保团队正确理解了他们的需求。

需求收集六个步骤往往包含上面三个子过程，并且在实际操作中，可能需要重复或者反复“迭代”。因此，最好将其视为子流程而非严格的线性步骤。

完整需求收集六个步骤包括：

1.确定相关利益相关者

根据项目的不同，我们需要在每个利益相关者群体中寻找合适的代表，可能包括如下群体：

客户利益相关者
决策者
用户
系统管理员
其他相关的客户部门
内部利益相关者
行政人员
工程团队
营销团队
销售团队
客户支持团队（可包括现场维护团队）
主要供应商
分销商和其他合作伙伴

也要寻找那些“隐形”的利益相关者。在正式开始需求收集之前，团队也可在早期会议中提出探索性问题。确保所有利益相关者群体都参与其中。理想情况下，要给每一个参与方提出自己观点、表达自己需求的机会。

2.明确项目目标

你希望通过这个新产品或项目达到什么目标？你的客户希望从产品中获得什么总体结果？你公司的业务目标是什么？为了实现这些目标和结果，你需要实现哪些可行的、可衡量的目标？

把它们写下来。清楚地陈述它们，并让你所有的利益相关者对它们签字。你的目标和目的将作为你决策的框架。

你写的每个需求都应该帮助满足项目目标并达成目标。如果没有，你应该放弃它，或者将它作为未来发布的候选者。

3.从利益相关者那里获取需求

需求获取是需求收集子流程的第一个，在实际操作中会有重叠且需要不断迭代。即使在敏捷开发中，在项目开发之前可能也需要经历几轮的需求收集、文档记录以及审查和确认。

需求收集的方式有很多种，可行的方法包括调查、问卷调查以及访谈。在后续的迭代中需要经常组织访谈和跟进会议。

在访谈中要积极倾听受访者。提出探索性问题，并做好笔记。访谈结束后，要整理笔记，并在需要时进一步跟进。

4.记录需求

我们需要将收集到的需求记录下来。可采用任何已经协商达成一致的格式，它们可以是产品需求文档（PRD），需求管理工具，电子表格、数据库或其他方便团队成员查看的数据存储形式。

比如我们是在PingCode进行需求的记录和梳理、建立需求池等工作。

重点是需求文档，它需要以下要求：

易于理解和浏览
所有的利益相关者都可以随时访问和查看
提供了对其他文档的可追溯性
使用标准化的格式和模版

5.确认需求

与所有利益相关者一起审查需求，确保需求准确地反映了预期的目标，并确保所有利益相关者对每一个需求都理解一致。如果发现表述模糊的地方，应及时调整。

如果条件允许，可以利用原型设计和测试来验证需求。使用原型制作工具，能够简单快速地制作出原型，我们利用这个模型来进行可行性、可用性和产品概念的测试。

让利益相关者对需求进行签字确认。在最后的审查阶段，整个规范说明也要签字确认。

6.需求优先级排序

大多数开发项目在途中都会遇到意想不到的挑战，会遇到意想不到的障碍。时间表可能会变化，优先级可能会改变。每个需求将影响你的版本的目标，所以进行优先处理非常关键。比如我们自己借助PingCode的产品管理构建标准的优先级框架，通过需求价值、工作量、客户权重、竞品、团队目标支持度维度衡量需求的优先级。

许多产品经理通过给功能打上“必须有”、“迫切想要”和“有也很好”等标签来确定其优先级。这样做主要基于以下两个原因：

首先，项目时间有限。如果团队优先实现相对简单的需求，最后发现没有足够的时间来完成关键需求，就会影响产品的发布时间。
其次，需求在变化。随着项目开展，可能会出现新需求。这些新需求可能非常关键，需要优先处理。我们要权衡新需求在优先级顺序中的位置。否则，我们可能会优先处理相对不太重要的需求。

以上只是需求收集流程的6个核心步骤，很多细节受限于篇幅并不能提及。并且到这里也并不是需求收集机制建设的终点，你需要将不断重复以上步骤，并不断的根据自身业务的特点，迭代需求收集的机制。

五、需求收集过程中常见的问题

1.想当然的去理解我们听到的内容

有时候，有些需求简单且宽泛，面对这些需求你需要警惕，不要想当然的以为自己已经完全理解利益相关者所要表达的意思，也不要以为所有利益相关者的表述方式都一样。

例如，像”网站应有博客”这样的需求陈述可能隐藏了很多潜在的假设。应仔细思考这样的需求陈述，并提出相应问题，例如：帖子将以何种方式展示？谁管理这些帖子？是否需要评论功能？是否需要对帖子进行分类或打上标签？等等。

通过提出这些问题并对收到的答案进行交叉核查，我们就可以得出一组更具体，并且可被验证的需求。

2.关注 HOW 而不是WHAT

需求可以分为两大类：一类是产品需要实现的功能需求，即产品需要做什么；另一类是对产品实现功能的方式和形式的约束，即非功能性需求。

在需求管理阶段，我们的重点应该更多地放在产品需要做什么，而不是如何去实现。换句话说，需求描述尽可能不要涉及其实现方式，例如应该使用哪一项新技术，偏好哪种工具，以及对产品的一些个人预设期待。总之，我们需要专注于利益相关者需要什么这个问题。

首先，我们要认真听取利益相关者的意见，然后收集、审查这些意见并提炼出需求。在完成这些步骤之后，再去分析使用哪些技术手段可以满足客户和利益相关者的真正需求。

3.未能充分与利益相关者沟通

在需求收集过程中，充分与利益相关者沟通至关重要。

首先，对每个利益相关者群体的需求都要深入了解。忽视这一点是需求管理失败的主要原因之一。

其次，保持项目透明度。每次访谈、开会或调查后，都要整理并共享笔记。现代需求管理工具，如PingCode，可将注释附加到需求上，保证需求的可追溯性。可帮助我们大幅提高工作效率，同时减轻审核工作量。

第三，给利益相关者充足的时间去审查需求。给他们提供反馈、表达异议，甚至捍卫自己的观点的空间。讨论越深入就越能帮助我们发现并修正需求中存在的问题，同时也有助于所有利益相关者就需求达成一致意见。

最后，确保所有利益相关者确认需求并签字，当然也要让利益相关者清楚签字确认意味着什么。

推荐阅读：