photo from Pexels

面对瞬息万变的市场需求以及需求实现的不确定，相比于按部就班的瀑布流开发方法，敏捷开发的方法更适用于范围不确定和时间固定的产品背景之下进行产品研发。从计划驱动到价值驱动，敏捷如何应用到产品规划的过程中呢？以下从团队和流程2个角度来诠释产品规划的敏捷。

首先，产品规划是多个部门协作的结果

产品规划流程

1.产品立项会

2.愿景、目标用户讨论、商业模型讨论

3.创建用户画像、用户流程图

4.创建用户故事、讨论可行性

5.用户故事汇报会（若不通过返回到第3步）

6.功能和内容确定会

涉及部门和人员

产品部门

全程参与

制定沟通计划

组织会议和活动

整理沟通结构，汇集就信息，形成报告

制作原型并和相关部门讨论可行性

创建用户流程图

创建“大”用户故事

项目干系人

部门参与（1、2、5、6）

参与关键会议，并在会议中行使否决权

对项目提供资金支持

帮助项目团队获取管理层的关注

开发部门

部分参与（1、2、4、5、6）

针对产品的功能提出建议，并与产品经理讨论功能的可行性，提出更好的解决方案

设计部门

部分参与（1、2、4、5、6）

针对产品的功能和内容提出建议，与产品经理讨论用户的体验流程，并针对产品的关键点给出体验优化方案

运营部门

部分参与（1、2、6）

需要时刻了解进度以及讨论结论用于提前制定运营策略

明确不同部门之间的参与程度，一方面可以同步进度，另一方面节约时间，提高效率。清晰的流程将每个部门的权责理清，保证产品产品规划高效进行。

如何进行产品规划？

1.确定产品的范围（什么该做，什么不做）

2.产出用户故事（做什么）

1.确定产品的范围

产品范围的三个角度：业务角度、用户角度、内容角度

业务角度：分析产品的信息架构

1.用户研究和分析

2.信息分类

3.创建信息架构地图

4.创建信息架构标签

5.提取、创建元数据

6.数据建模

用户角度：

1.哪些群体使用？他们是什么角色？他们会怎么用？

2.先分析用户群体的需求，然后分析该群体中某角色的需求

内容角度

产品的内容在一定程度上会反过来影响产品的功能

识别子系统

1.为什么要识别子系统

子系统是粗粒度的产品范围的体现

项目干系人和项目小组了解子系统后，会对整体系统有高层次的认识

2.识别子系统的方法

使用功能结构图和流程图

2.产出用户故事

1.制作用户流程图

使用泳道图产出跨子系统的用户流程图，随后分别制作各子系统的用户流程图

泳道图可以快速得知不同对象的功能以及功能之间的前后关系

涉及到外部跳转的时候，至少需要一个步骤（功能点）

当涉及到转折点，或者信息状态发生变化，需要一个步骤（功能点）

2.制作MVP

根据主流程识别MVP，将功能做删减

采用MoSCoW法则将功能点分类：

•Must Have：指一定要有的功能

• Should Have：指应该有的功能

• Could Have：指可以有的功能

• Won't Have：指（此版本）不会有的功能

在实际应用中，Must Have比较好识别，对于Should Have和Could Have可以采用“价值和实现难度”矩阵识别和归类：

用户价值高，难度低，优先制作；

用户价值低，难度高，延后制作甚至不做；

用户价值高、难度高和用户价值低和难度低：延后制作；

注意：开发部门可能出于识别、规避风险的考虑，会先做“难度高，价值高”的功能

3.制作线框流图

制作线框图，并组合到MVP流程中，得到“线框流程图”

线框流图的意义在于：

• 既能够展示出用户使用流程；

• 又能够将用户体验的元素展现出来；

4.编写“大”用户故事

根据MVP地图和线框图，产出“大”用户故事，随后组织会议讨论并达成一致

5.拆分“大”用户故事

拆分“大”用户故事为“可开发”的用户故事，并配合研发部门进行开发

用户故事验收会议

为什么要组织用户故事验收会议？

 “大”用户故事将被拆分为数个小故事，在拆分以前，必须确认他们是必要的

验收会议能够确保不会有“大”用户故事被遗漏

谁主持？谁参加？

• 产品经理主持会议

• 项目团队、相关团队、项目干系人都需要参加

会议后的产出物是什么？

• 经过集体确认的“大”用户故事

• 项目干系人确定其必要性

• 相关团队确定其合理性

• 开发团队确定其可行性

• 会议后，产品团队即将其拆分为“可开发”、“小”的用户故事

拆分方法

方法一、按照流程进行拆分

方法二、从简单到复杂的拆分

方法三、按照操作边界拆分

方法四、按照数据边界拆分

方法五、按照个性、共性拆分

共性的需求可能包括：

• 安全处理

• 错误处理

• 日志处理