产品经理必读：敏捷开发中的需求管理过程全解

产品的源头是需求。一切伟大产品的实现都是从需求管理开始的。敏捷开发中的需求管理大致分为三个阶段： 需求调研，需求分析和需求确认 。

需求调研阶段

产品立项后，产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量，会直接影响到后续产品设计的工作。产品经理可以从以下渠道来调研需求：

1. 从产品定位出发

从产品定位出发指的是，产品经理应当对自己的产品有足够认知和把控。简单来说，就是我的产品是为了满足哪些人的哪些需求而做的。每款产品必定有其核心价值，基于此考虑往往能得到一些核心需求，摒除价值不大的需求。

2. 用户反馈

用户反馈包括用户直接的反馈和间接的反馈。直接反馈指的是用户直接提出需求，如在产品的交流论坛，官方 QQ 群等用户提出的建议和需求。另外，用户访谈、调查问卷等方式也是比较常用的搜集用户需求的方法。间接反馈指的是通过对用户行为习惯（如习惯、偏好、使用流程等）的分析来获取用户的需求信息。

3. 竞争对手情况

知己知彼百战不殆。竞争对手的产品优势及不足也是产品经理需求来源的重要渠道。竞争对手好的功能我们如何借鉴优化，不足如何规避，在反复探讨中也能获得好的灵感。

4. 相关人反馈

这里的相关人包括任何对产品需求有贡献的人。主要有运营人员、客服人员、市场人员和开发人员的反馈。

产品经理在收集需求的过程中需要注意的一点是，尽量保证需求的精准性，一是用户意图的准确，一是语言描述的精炼，否则接下来的需求整理工作必然变得非常吃力。用户需求在敏捷开发中称之为用户故事 (user story) 。通常的格式为：作为一个 < 角色 >， 我想要 < 功能 >， 以便于 < 商业价值 > 。这也是产品研发中用户需求描述的最标准格式。

需求分析阶段

通过需求调研，此时产品经理已经掌握了很多用户需求，但这并不代表所有的需求都会为产品所用。产品经理需要对这些需求进行整理、分析与设计。需求分析主要有两个目的，一是挖掘用户的真正需求，二是评估可行性。

在做需求分析时，产品经理可以从以下几个角度着手：

1. 定位分析

产品定位就是满足什么样的用户在什么条件下的什么需求。如，购物网站是为了满足购物需求，社交软件是为了满足社交的需要。购物网站的社交需求，社交产品的购物需求一定是与产品的核心服务不统一的。在做需求分析时一定要多问一问是不是符合产品定位？好需求但不一定是适合的需求，说的就是这个道理。

2. 场景分析

场景分析指的是要考虑什么环境（时间、地点、情境）下什么类型的用户基于什么动机，希望达到什么目的而采取的一系列行为。比如：

基于什么环境：办公室 / 家里 / 公共场合 / 上下班途中 / 户外 / 室内 / 白天 / 夜晚……

基于什么用户：老人 / 小孩 / 男士 / 女士 / 上班族 / 学生 / 家庭主妇……

基于什么动机：省钱 / 省时 / 省力 / 打发时间……

想达到什么目的：彰显个性 / 炫耀 / 获得认可 / 变美 / 变瘦……

3. 深层挖掘

挖掘每个需求产生的原因：用户基于什么原因才提出这个需求？

挖掘每个需求背后隐含的需求：用户提出这个需求，是为了达到什么目的 ？

挖掘每个需求的重要性：这个需求是必须的吗？如果没有这个需求会怎样？

通过深层挖掘往往会发现比原始用户需求更加合理的方案，也能发现那些用户没有说出口和没有想到的需求，而往往这些需求才是用户的真正需求。

4. 价值评估

价值评估是指这个需求需要多少开发资源或运营能力，技术难度如何，时间花费如何等。可以从四个维度考虑：

广度：该需求能覆盖多少目标用户？

频率：该需求的使用频率是怎样的？

强度：该需求对用户来说有多强烈？

时机：该需求是否符合产品目前的规划？在当前的资源情况下能否具备可行性？

需求确认阶段

经过分析整理，产品经理已经获得了初步的需求列表，接下来需要对这些需求设计用例场景，并进行用例描述、流程分析、角色分析等。如，模块如何划分、流程如何设计、业务如何转换等，一般通过绘制行动图、状态图、用例说明来配合呈现，并最终形成《产品需求说明书》。

很多时候，用例分析工作是产品经理、架构师、设计师等共同协作完成的，因为除了要考虑技术能否实现，还需要考虑产品性能、响应时间、设计风格等非功能性的需求。

最后才是需求确认工作，确认工作一般通过需求评审会议来实现，由于是最终确认，参会人员可能包括运营、开发、设计、测试等成员，共同对需求说明书中描述的需求的正确性、一致性、完整性、可行性、必要性、可测试性进行确认。

在正式需求评审之前，产品经理可以提前与项目负责人做需求初评，目的是提前收集问题，沟通是否有技术难点，确认开发成本及是否有考虑不全的逻辑漏洞等。

由于敏捷开发是快速迭代的开发模式，敏捷开发中一般由产品经理根据需求优先级整理近期待做需求，进行需求评审。评审会议叫做发布计划会议，在会上，由产品经理或产品负责人负责讲解需求，并对其进行估算和排序，制定出这一期迭代要完成的需求列表。

需要提的一点是 ，在需求确认中一定要考虑到需求变更的确认。当需要进行需求变更的时候，一定要有书面的文档和签字手续。由于流程复杂，现在很多研发团队直接通过在项目管理软件中来记录需求的变更。如，禅道中凡是对需求 标题、描述、验证标准和附件的修改，都应该走变更流程。

至此，需求管理工作基本完成，接下来便步入产品设计环节。但这并不代表产品经理工作的结束，需求评审完成后，还需要进一步和开发、设计了解实现细节以完善产品方案并跟踪需求的实现。

需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性和完整性。在整个开发过程中，确保所有的实现是以用户需求为基础的。

需求跟踪有两种方式，正向跟踪与逆向跟踪：

正向跟踪：以用户需求为切入点，检查《产品需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。

逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。

需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。需求管理的过程，其实是从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合。

资料借鉴：

需求管理-百度百科

禅道项目管理—产品经理篇