产品经理效率工具之《产品需求文档-PRD实战篇》

问自己:我,幸福吗?
幸福本来就是一本流水账。感谢老天让我遇到一个叫“老毛”的人,和你在一起,再苦再难,心里都是甜的。
你就是我的幸福。

产品经理效率工具之《产品需求文档-PRD实战篇》

上一篇,产品效率工具之《产品需求文档-PRD前瞻篇》,从不同的维度解读了:PRD是什么?

这一篇,将以实例还原产品需求文档(PRD)的完整设计过程,尝试定义一个实用、高效、价值的文档设计过程。

设计文档之前,看一看产品需求文档/PRD的目标用户(阅读者)。事实上,产品需求文档的受众极为宽泛,核心阅读对象包括:产品经理、技术研发、UI设计师、技术测试、项目经理,甚至包括非技术的运营及业务人员。

  • 技术研发阅读PRD,熟悉了解产品功能逻辑
  • UI设计师阅读PRD,设计视觉、交互的细节
  • 技术测试阅读PRD,设计用例控制产品质量
  • 项目经理阅读PRD,分拆功能协调分工协作

产品生命周期的前半生——技术研发阶段,PRD是每个协作者达成的共识,共同认知的产物,一切决策的指导手册。

鉴于我个人当前的工作需要,给出我设计的一个文档形式,仅供学习之用。

  1. PRD载体:有道云笔记+AXURE原型,云同步+图文配合,帮助阅读者最大程度的理解。
  2. 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案例,点击文字链接,开始阅读 ——

【开发中】2674-商品详情页领取双十一红包-181010

【产品效率工具】系类将以主题形式呈现:
上一篇,产品效率工具之《产品需求文档-PRD前瞻篇》,现已分享;
下一篇,产品效率工具之《产品需求文档/PRD思想篇》,即将分享;
陪你一起,还原设计一个产品需求文档的本来用意,所谓的初心,敬请期待。


生如白溪,一苇以航。
我是白苇,很开心在产品世界遇见你。
Date:2018年10月10日 10:00pm

推荐阅读更多精彩内容