産品经理必读：敏捷开发中的需求管理过程全解
産品的源头是需求。一切伟大産品的实现都是从需求管理开始的。敏捷开发中的需求管理大致分为三个阶段： 需求調研，需求分析和需求確認。
需求調研階段
産品立项后，産品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量，会直接影响到后续産品设计的工作。産品经理可以从以下渠道来调研需求：
（需求的來源）
1. 从産品定位出发
从産品定位出发指的是，産品经理应当对自己的産品有足够认知和把控。简单来说，就是我的産品是为了满足哪些人的哪些需求而做的。每款産品必定有其核心价值，基于此考虑往往能得到一些核心需求，摒除价值不大的需求。
2. 用戶反饋
用戶反饋包括用户直接的反馈和间接的反馈。直接反馈指的是用户直接提出需求，如在産品的交流论坛，官方QQ 群等用戶提出的建議和需求。另外，用戶訪談、調查問卷等方式也是比較常用的搜集用戶需求的方法。間接反饋指的是通過對用戶行爲習慣（如習慣、偏好、使用流程等）的分析來獲取用戶的需求信息。
3. 競爭對手情況
知己知彼百战不殆。竞争对手的産品优势及不足也是産品经理需求来源的重要渠道。竞争对手好的功能我们如何借鉴优化，不足如何规避，在反复探讨中也能获得好的灵感。
4. 相關人反饋
这里的相关人包括任何对産品需求有贡献的人。主要有运营人员、客服人员、市场人员和开发人员的反馈。
産品经理在收集需求的过程中需要注意的一点是，尽量保证需求的精准性，一是用户意图的准确，一是语言描述的精炼，否则接下来的需求整理工作必然变得非常吃力。用户需求在敏捷开发中称之为用户故事(user story) 。通常的格式爲：作爲一個 < 角色 >， 我想要 < 功能 >， 以便于 < 商業價值 > 。这也是産品研发中用户需求描述的最标准格式。
（禅道項目管理软件中的用户需求界面）
需求分析階段
通过需求调研，此时産品经理已经掌握了很多用户需求，但这并不代表所有的需求都会为産品所用。産品经理需要对这些需求进行整理、分析与设计。需求分析主要有两个目的，一是挖掘用户的真正需求，二是评估可行性。
在做需求分析时，産品经理可以从以下几个角度着手：
1. 定位分析
産品定位就是满足什么样的用户在什么条件下的什么需求。如，购物网站是为了满足购物需求，社交软件是为了满足社交的需要。购物网站的社交需求，社交産品的购物需求一定是与産品的核心服务不统一的。在做需求分析时一定要多问一问是不是符合産品定位？好需求但不一定是适合的需求，说的就是这个道理。
2.場景分析
場景分析指的是要考虑什么环境（时间、地点、情境）下什么类型的用户基于什么动机，希望达到什么目的而采取的一系列行为。比如：
基于什麽環境：辦公室/ 家裏 / 公共場合 / 上下班途中 / 戶外 / 室內 / 白天 / 夜晚……
基于什麽用戶：老人/ 小孩 / 男士 / 女士 / 上班族 / 學生 / 家庭主婦……
基于什麽動機：省錢/ 省時 / 省力 / 打發時間……
想達到什麽目的：彰顯個性/ 炫耀 / 獲得認可 / 變美 / 變瘦……
3.深層挖掘
挖掘每個需求産生的原因：用戶基于什麽原因才提出這個需求？
挖掘每個需求背後隱含的需求：用戶提出這個需求，是爲了達到什麽目的？
挖掘每個需求的重要性：這個需求是必須的嗎？如果沒有這個需求會怎樣？
通过深層挖掘往往会发现比原始用户需求更加合理的方案，也能发现那些用户没有说出口和没有想到的需求，而往往这些需求才是用户的真正需求。
4. 價值評估
價值評估是指这个需求需要多少开发资源或运营能力，技术难度如何，时间花费如何等。可以从四个维度考虑：
廣度：該需求能覆蓋多少目標用戶？
頻率：該需求的使用頻率是怎樣的？
強度：該需求對用戶來說有多強烈？
时机：该需求是否符合産品目前的规划？在当前的资源情况下能否具备可行性？
（産品经理需要不断提出这样的疑问）
需求確認階段
经过分析整理，産品经理已经获得了初步的需求列表，接下来需要对这些需求设计用例场景，并进行用例描述、流程分析、角色分析等。如，模块如何划分、流程如何设计、业务如何转换等，一般通过绘制行动图、状态图、用例说明来配合呈现，并最终形成《産品需求说明书》。
很多时候，用例分析工作是産品经理、架构师、设计师等共同协作完成的，因为除了要考虑技术能否实现，还需要考虑産品性能、响应时间、设计风格等非功能性的需求。
最後才是需求確認工作，確認工作一般通過需求評審會議來實現，由于是最終確認，參會人員可能包括運營、開發、設計、測試等成員，共同對需求說明書中描述的需求的正確性、一致性、完整性、可行性、必要性、可測試性進行確認。
（用戶需求的特性）
在正式需求评审之前，産品经理可以提前与项目负责人做需求初评，目的是提前收集问题，沟通是否有技术难点，确认开发成本及是否有考虑不全的逻辑漏洞等。
由于敏捷开发是快速迭代的开发模式，敏捷开发中一般由産品经理根据需求优先级整理近期待做需求，进行需求评审。评审会议叫做发布计划会议，在会上，由産品经理或産品负责人负责讲解需求，并对其进行估算和排序，制定出这一期迭代要完成的需求列表。
需要提的一點是 ，在需求确认中一定要考虑到需求变更的确认。当需要进行需求变更的时候，一定要有书面的文档和签字手续。由于流程复杂，现在很多研发团队直接通过在項目管理软件中来记录需求的变更。如，禅道中凡是对需求 標題、描述、驗證標准和附件的修改，都應該走變更流程。
（禅道中的需求變更流程）
至此，需求管理工作基本完成，接下来便步入産品设计环节。但这并不代表産品经理工作的结束，需求评审完成后，还需要进一步和开发、设计了解实现细节以完善産品方案并跟踪需求的实现。
需求跟蹤的目的是爲了建立和維護從用戶需求開始到測試之間的一致性和完整性。在整個開發過程中，確保所有的實現是以用戶需求爲基礎的。
逆向跟踪：检查设计文档、代码、测试用例等工作産品是否都能在《需求规格说明书》中找到出处。
（需求管理流程）
需求管理恰如裁缝的量体裁衣，它直接关系到最终産品的成型。需求管理的过程，其实是从需求分析开始贯穿整个项目始终，力图实现最终産品同需求性的最佳结合。
資料借鑒：
需求管理-百度百科
禅道項目管理—産品经理篇
