目录
一、需求收集
需求收集环节是需求提出方和产品经理之间明确产品需求的阶段，是产品研发运营一体化最初始阶段，把产品的需求具体化，形成待办事项列表的过程。
需求收集环节的三个参考步骤如下：
- 明确单个需求点：即以问题驱动为核心，探索问题核心相关事项的过程；应通过协作方式形成适当详细的需求说明。
- 梳理需求全貌：应能列出为了落实产品的愿景而需要完成的所有事项，即待办事项列表；
- 确定待办事项列表：应包括用户需求所涉及的所有事项，并且作为产品研发路线图。
需求应在需求进入迭代开发之前可以进行变更和细化。产品经理应对提出的需求在产品演进过程中持续细化和演进，形成产品路线图。应建立需求快速上线、快速反馈流程，用户反馈应能快速收集。
推荐的需求收集方法：访谈、问卷调查、需求研讨会、竞品分析、文档等。
需求提出方和产品经理应有明确的需求收集流程，制定快速沟通协作机制，例如明确规定计划和需求之间的流转和协作方法及规范。需求提出方和产品经理之间的机制应不限定时间和角色，保证需求随时入和出，例如：建立运营驱动需求的体系，在产品演进的过程中，不断涌现需求，能不断优化和调整待办事项列表的顺序。
二、需求层级划分
产品需求建议按照以下三种层级进行划分：
- Epic Story 史诗故事：简称为史诗。一般定义为一个非常大的用户故事，是产品中的主干任务。
- Feature 特性：特性是能对用户提供价值的完整功能。描述了产品具有的完整功能，特性一般也比较大，可能持续数周，横跨几个迭代。
- User Story 用户故事：从用户的角度来描述用户渴望得到的功能。特性一般可以拆分为多个用户故事，每个用户故事都对用户有价值。但是单个用户故事却有可能不能被用户正常使用或者是整个功能的细分场景。
👉 用户故事三要素：
- 角色：谁要使用这个功能；
- 活动：需要完成什么样的功能；
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
👉 用户故事格式：
作为一个<角色>，我想要<活动>，以便于<商业价值>
举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益”。
三、需求分析
需求分析是产品经理将需求细化和拆解成用户故事的过程。需求分析的三个参考步骤如下：
1. 明确需求内容和形式：需求分析形成用户故事，用户故事描述用户场景。用户故事应符合INVEST标准：
- 独立性（Independent）：故事是独立的；
- 可协商性（Negotiable）：一个用户故事的内容是可以协商的，用户故事不是合同；
- 有价值（Valuable）：故事是有业务价值的；
- 可以估算性（Estimable）：故事是能评估工作量和优先级的；
- 短小（Small）：用户故事在工作量上要短小，一般在1-2日内完成；
- 可测的（Testable）：用户故事是可测试的。只有成功通过测试才能说明该用户故事已经被开发完成。
2. 需求分析协作：用户故事是适度详细并适应变化的，可以在开发过程中对其进行评估不断细化；在软件过程的任何阶段，产品经理、需求提出方及团队成员可对用户故事进行变更和细化。当发生跨团队的产品研发情况，应建立史诗故事、特性故事、用户故事的分层管理，可跨团队进行需求拆解细化。
3. 需求管理：用户故事统一管理，并按照业务价值由高到低排定优先级。应使用产品待办列表和迭代待办列表管理需求。当发生规模型产品研发情况，应建立跨团队的产品待办列表、迭代待办列表。产品待办列表应符合DEEP原则：1）适当细化的，优先级越高越详细明确，2）用故事点估算过大小，3）随着产品演进不断涌现和变化的，4）优先级从高到低排序的。
四、需求与用例管理
需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性，能验收产品功能是否满足用户故事要求的过程。需求与用例管理的三个参考步骤如下：
- 梳理需求用例：编写需求验收标准，形成测试用例的过程。测试用例与用户故事应有关联，测试用例在需求分析结束设计阶段完成。产品的需求应在初始阶段就转化为测试用例，细化需求验收标准过程即编写测试用例的过程。
- 使用需求用例：需求用例指导需求开发，验证产品功能的过程。每次上线前应把编写的测试用例全部验证通过，才可上线。
- 管理需求用例：建立需求与用例的统一管理库，持续的使用和优化。测试用例应作为产品的软件代码资产存在，所有的功能上线都以测试用例能验证通过为目标，每次迭代上线都必须执行产品沉淀下的所有测试用例，直到验证和修复通过才可以上线。当产品进行升级重构时，产品的需求用例库无需重建就能作为升级重构后的验收标准。
五、需求优先级与排期
推荐使用如下四种方法排列需求优先级：
- MoSCoW法则：Must > Should > Could > Would Not；
- 矩阵分析法：重要且紧急 > 重要不紧急 > 紧急不重要 > 不重要也不紧急；
- 二八原则：满足核心用户需求的优先；
- ROI最大化：满足核心业务的投入产出比最大的需求优先。
六、需求验收
需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，应能对需求进行快速测试、快速确认、快速反馈、快速优化。本节的需求验收，仅是指功能验收，非功能验收不在本节的范围内。
需求验收的频率指不同角色对需求功能验收的频率，频率越高效果越好。在每个敏捷迭代，应有验收评审会。在跨团队产品里，应有跨团队的产品验收会，并要求在每个迭代都召开。
需求验收应尽量具备有业务价值的端到端的验收。在验收评审会上，产品经理应对团队的迭代成果进行验收。需求提出者或最终用户应能在每个发布后进行验收。在迭代过程中，应有通过原型确认、AB测试、灰度测试等方法进行验收测试，提升验收效果。
需求验收的反馈效率指需求验收的结果能准确、快速的反馈到开发团队的过程。对验收测试应有快速的反馈和优化流程，能保障反馈能够进入产品待办列表，且根据优先级进入迭代待办列表。建立产品级的业务价值验收反馈流程，在产品推向市场后，能在1-2个迭代就能快速进行响应。针对反馈的情况，能通过反馈发现迭代中的沟通、设计等各类问题，并进行持续改进。