PRD文档制作

PRD
作用：一种沟通工具，帮助干系人快速理解，保持信息一致
包含：需要传递给研发团队的各种需求信息

客户 (原型图)<- 产品经理 ->(PRD文档)研发团队 

word格式：以文档结构为中心，生成word/在线文档为主

优点：文档结构清晰，文字易于阅读，便于技术文档制作
缺点：产品设计展示较弱，文档过长，上下文难关联

Axure格式：HTML文档格式，原型图为描述重点，方便原型图展示

优点：易于展示产品设计，便于展示功能之间的关联
缺点：文档结构差，文字信息偏少需要产品经理多跟进沟通

PRD中包括的内容

PRD 1.功能描述：本期需要研发功能的 原型图+文字说明  
    2.业务描述：与“本期研发功能”相关的需求背景，业务流程，业务知识等
    3.其他信息：文档结构信息，修订记录，计划排期等

PRD在FeatureList做成原型图后开始做PRD文档

PRD的功能数量划分
建议需求分类：
1.新功能型：根据公司的产品战略，以一个“可验证的新功能”作为一个PRD制作
2.优化型：将一定周期内“体验、性能、问题”等优化需求汇总作为一个PRD制作

PRD误区
1. 格式固定：根据产品类型、团队、产品阶段重新调整
2. 持续更新：需求变更后要及时更新
3. 文档过长：过长的文档影响团队阅读

参考文章
1.Product Templates
2.人人都是产品经理--产品小白如何写PRD

PRD文档结构
1.标题 -- 分为主标题和副标题
主标题：XXX版本号产品需求文档
副标题：功能模块
大公司会有编号：产品代号，平台类型，文档类型，功能编号，版本编号

2.修改文档要添加修订记录（修订时间以及修订了什么内容）加上修订人、审核人

3.项目背景：为什么做这个功能，也可分为大背景和小背景，大背景描述产品战略，小背景描述
产品目的

4.实现目标：可量化的产品目标，便于前期评估投入，后期跟踪结果
例如：1、图文内容社区功能1.0版本上线
      2、社区功能的使用率>30%
      3、产品日留存率>25%
      4、每周图文发布量>500篇

5、相关术语（可选）：一些术语的定义说明，帮助项目组成员快速理解业务，团队同频交流
例如：专业名词解释

6、用户角色（可选）：描述系统用户与角色（B端产品居多），把用户分类开，对应用户

7、功能列表/结构 FL：明确本期作业范围

8、业务流程图：明确业务范围 （B端产品百分百需要）

9、功能详情描述
9-1、xxx功能
9-2、功能描述
9-3、数据结构
9-4、功能界面

10、原型图演示连接

11、数据统计埋点（可选）：C端产品，用来改进用户体验，确定功能上线效果，基础数据一般有
独立的平台不需要统计

12、上线计划（可选） ：其实个人理解这个是项目经理做总体，TMP管控部分功能，输出功能FO负责表

13、参考文档

个人小总结：产品设计的过程很有趣，可以大胆的进行头脑风暴，输出自己想要完成的东西，当然
要符合合理性。这种创新带来的成就感是无可比拟的，可能这就是我喜欢产品经理的原因吧。压力
也是和有趣并存的，继续努力，希望各位对产品经理感兴趣的各位也一起努力。