产品经理效率工具之《产品需求文档-PRD实战篇》
问自己：我，幸福吗？
幸福本来就是一本流水账。感谢老天让我遇到一个叫“老毛”的人，和你在一起，再苦再难，心里都是甜的。
你就是我的幸福。
产品经理效率工具之《产品需求文档-PRD实战篇》
上一篇，产品效率工具之《产品需求文档-PRD前瞻篇》，从不同的维度解读了：PRD是什么？
这一篇，将以实例还原产品需求文档（PRD)的完整设计过程，尝试定义一个实用、高效、价值的文档设计过程。
设计文档之前，看一看产品需求文档/PRD的目标用户（阅读者）。事实上，产品需求文档的受众极为宽泛，核心阅读对象包括：产品经理、技术研发、UI设计师、技术测试、项目经理，甚至包括非技术的运营及业务人员。
- 技术研发阅读PRD，熟悉了解产品功能逻辑
- UI设计师阅读PRD，设计视觉、交互的细节
- 技术测试阅读PRD，设计用例控制产品质量
- 项目经理阅读PRD，分拆功能协调分工协作
产品生命周期的前半生——技术研发阶段，PRD是每个协作者达成的共识，共同认知的产物，一切决策的指导手册。
鉴于我个人当前的工作需要，给出我设计的一个文档形式，仅供学习之用。
- PRD载体：有道云笔记+AXURE原型，云同步+图文配合，帮助阅读者最大程度的理解。
- MVP元文档：以1个需求为基本单位，独立需求描述，独立管理，适配团队的分布式协作。
基于需求基础粒度和团队协作方式，给出我当前工作的PRD内容基础结构：
MVP元文档-白苇原创
以实例呈现《产品需求文档/PRD》核心要素：
1. 文档内容
1.1 文档名称
- 能够让阅读者一眼就知道文档的核心内容
- 能够体现和记录文档本身的版本迭代变化
- 案例：【PRD】2688-商品详情页支持领红包-181009
a. PRD为文档类型
b. 2688为需求编号，来自需求管理工具
c. 商品详情页支持领红包，为该文档的内容概括
d. 181009，为最新的文档最新变动时间
1.2 编写人员
- 方便阅读者找到最初的文档编写者，解答需求的疑问
1.3 编写时间
- 记录文档的创建时间，方便后期项目复盘、文档管理
1.4 变更记录
- 记录文档的每一次变动，便于阅读者了解文档迭代过程
- 方便阅读者第一时间查阅变化内容，保持信息的畅通性
- 案例：编号、类型、文档版本、章节、修改内容/原因、日期、修改人。
a. 编号是为了记录修改的顺序
b. 类型是为了表示修改的类别
c. 文档版本显示的当前修改内容所属的文档版本
d. 章节是具体到修改内容属于的功能模块
e. 修改内容/原因说明修改的内容及原因
f. 日期是指文档被修改的时间
g. 修改人是指谁修改了需求
—— 案例图-变更记录 ——变更记录
2. 项目管理
2.1 需求编号
- 来自团队需求管理工具，给需求进行编号，便于交流、管理；
- 常使用的需求管理工具，比如：teambition、redmine等；
2.2 需求优先级
- 源于需求管理阶段的优先级评估
- 综合了需求方、产品等上游部门
2.3 预期版本
- 业务部门给出的自预期版本
- 供技术研发部门的排期参考
2.4 当前状态
- 当前的需求状态，标识需求
2.5 需求干系人
- 解决该需求的关键节点，协作人员
- 案例：序号、姓名、分工职责、所属部门、联系方式
—— 案例图-需求干系人清单——需求干系人
2.6 关键里程碑
- 记录关键里程碑时间节点
- 控制需求迭代的周期节奏
- 案例：需求评审通过、评估上线时间、评估工作量（PD）、技术开发完成、技术测通过、产品验收通过、正式上线时间
—— 案例图-项目管理 ——关键里程碑
2.7 风险评估
- 评估该需求对周边功能的影响
- 列出需求的可能风险前置提醒
3. 需求内容
3.1 需求概述
- 需求背景：讲清楚为什么要做这个需求，即使是boss的需求，那更应该讲明白，好让一干人等心中有数；
- 产品名称：需求所属平台的产品名称
- 关联平台：
a. 牵涉到的终端
b. 一般包括，WEB、H5、APP、小程序
- 功能路径：指引阅读者找到该需求的作用点
- 功能特性：列出该需求的核心功能点
3.2 产品目标
- 做需求可以达到什么目的，完成什么样的产品目标
- 必须告知每一个产品干系人，统一认知、建立默契
- 必不可少的模块，绝不可以缺省
3.3 业务流程
- 在整条业务流程上，该需求处于一个什么样的位置，前后是什么
- 该需求对应本身的业务流是怎样的流转的，与外部是如何交互的
3.4 需求详情
3.4.1 简要说明
- 介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
3.4.2 用户场景/用户故事
- 什么人，在哪里，做什么。时间、地点、人物、事件
- 本质上，是一个从用户的角度来描述用户渴望得到的功能的用户故事（User story）。
3.4.3 业务规则
- 业务规则是《产品需求文档》的篇幅最大的内容，描述清楚规则，让协作者（UI、开发、测试）易阅读、易理解。
- 业务规则的描述内容很宽泛，涉及页面交互、视觉样式、功能结构、逻辑关系、信息架构等，建议图文结合的方式呈现。
- 业务规则是产品需求文档中最为耗时、最核心的内容表达模块，需要穷尽产品的一切细节和可能性。
—— 案例图01-状态图 ——秒杀时间栏状态-多状态梳理 —— 案例图02-状态时序图 ——
定金预售-商品状态时间线
3.4.4 产品原型
- 交互设计、界面布局、信息架构都是以原型的形式对外呈现的，产品经理需要设计页面原型或者协作设计。
- 不同产品生命周期，对原型的详略要求不一。产品经理需要审时度势，选择设计符合工作场景的最佳方案。
- 描述业务规则时，将原型穿插到文字描述中，将增强产品需求内容的可阅读性，将提高阅读者的理解速度。
- 可以合并到业务规则描述模块中，亦可以独立文档的形式提供。
3.4.5 前/后置条件/副作用
- 前置条件/precondition：该需求实现依赖的前提条件，或者所处的状态。
- 后置条件/postcondition：该需求执行后引发的结果或状态，或者后续的处理。
- 副作用/side effects：该需求执行后，可能引发的其他问题（异常状态）。
3.4.7 补充说明
- 将副作用/异常流程剥离出来，以单独的模块详细说明，尤其是一些副作用明显后者异常状态较多的场景
- 特殊说明
3.4.8 主流程
- 统观需求详情的内容，将需求置于主流程中建立连接
- 将每个功能点的全部流程走向分点罗列逐一描述说明
4. 数据分析
4.1 数据指标
4.2 数据埋点
该模块细节就不展开了，一般都以独立文档形式提供。
读过很多PRD，全文只有一个主流程，既没有前置条件、后置条件，也没有描述主流程中多场景的不同走向。其实，这是产品的另一个输出《产品使用手册》，Product Maual。一个标准的PRD除了要描述主流程，同时对子流程/异常情况所出现的各个场景都要说清楚并给出解决方案。
唯一的不变的就是变化。产品经理给人的第一印象是善变的。坦白讲，在需求上，我讨厌变化，尤其是已进入版本的需求。产品需求文档是需求/功能/特性的现实化还原，那么一份合格的PRD必须是：
- 明确的
- 全面的
即使PRD不可能100%覆盖所有的可能，但最大化的思考全面是撰写PRD必须遵守产品原则。产品需求文档中，绝对不会允许出现"可能"“或许”等模凌两可的用语。一定是明确的，唯一的描述。
设计一款符合实际工作需要的PRD，将成为一款产品效率工具，是对产品实现的品质追求，是对产品线上协作者的负责，因为不给别人添麻烦，是对别人最好的尊重。
产品需求文档（PRD）是一款产品的全生命周期的记录，知晓每产品的每一个细节变化的原委。
产品需求文档（PRD）是一款专业的产品管理的效率工具，产品经理的必须掌握的专业产品工具。
——《产品需求文档》PRD案例，点击文字链接，开始阅读 ——
【产品效率工具】系类将以主题形式呈现：
上一篇，产品效率工具之《产品需求文档-PRD前瞻篇》，现已分享；
下一篇，产品效率工具之《产品需求文档/PRD思想篇》，即将分享；
陪你一起，还原设计一个产品需求文档的本来用意，所谓的初心，敬请期待。
生如白溪，一苇以航。
我是白苇，很开心在产品世界遇见你。
Date：2018年10月10日 10:00pm
