补充：PRD是什么？如何去写？

Date：2019年7月21日

补上前几天天遗留的PRD的相关内容整理。

PRD（产品需求文档）

1. 目的

• 将MRD文档中各种理论要求技术化

2. 用户

• 研究人员
• 设计人员
  为了最有效的传达，用最平铺直叙的语言进行阐述

3. 方式

• 文字模式（最常见）
• 原型图模式（Axure 最推荐）
• 图片模式（设计出身偏好）
• 影像模式（费时费力）

4. 内容

1. 文档说明

• 产品版本号（1.26）
  • 版本号（ <u>1</u> .26）
    • 重大调整和升级
    • 产品结构功能等调整
  • 子版本号（1. <u>2</u> 6）
    • 在原有基础上，对局部进行调整
  • 修正版本号（1.2 <u>6</u> ）
    • 局部小范围优化及Bug修复
    • 一般不会对功能性内容进行修改
  • 命名规则
    • 归零规则：前一个数字增加一位，后面归零
    • 收费原则：子版本号和修正版本号变化一般是做版本内升级，不额外收费。若版本号改变，则另外收费。
• 历史修订
  其作用在三方面：方便对修改前后进行比较；有利于维护和管理PRD；方便直接进行查阅修改内容。
  • 编号
  • 版本号
  • 修订章节
  • 修订原因
  • 修订日期
  • 修订人
• 名词术语表
  对一些专业名词及缩写进行说明，帮助用户更好的理解文档的内容。

2. 产品说明

产品说明.png

在构建信息结构图时，要尽量避免出现交互的情况。用户使用流程图方面，可以先梳理主线流程图。

3. 全局功能需求说明

表述每个类与每个子类的功能说明。

4. 详细功能需求描述

可以出狱两个角度来进行描述：功能的逻辑、产品结构。功能逻辑会更偏向于开发的理解方向，产品结构则会更偏向于PM的理解。
存在“ UML>用例文档>用例图 ” 的关系，以下对其进行简单的解释和备注。

• 用例：描述系统功能需求的方法
  • 编号
  • 参与者
  • 目标
  • 说明
  • 条件
  • 界面描述
  • 流程图
• 用例图：系统外部参与者与系统之间的关系图
• 结构
  功能板块1需求（用例文档）
  -XX功能板块1的子功能1
  • XX功能板块1的子功能1的元素1说明（用例）
• 原则：MECE原则（相互独立、完全穷尽）

最后再总结一下一份优秀的PRD的要素：

正确

PRD作为三大文档最后一项，也是产品经理思维不断递进后的最后产物。它的存在是为了保证产品结构本身短期内不会有重大改动。所以对于各种需求的描述等要保证正确，否则会出现反复修改需求等破坏产品进度的情况出现。

无歧义

PRD书写过程中要保证用词的准确无误，相似词汇不可随意替换使用。专业名词和缩写也需要在最开始的文档说明的名词术语表中进行指出。尽可能避免用词带来的理解偏差。

完备

作为产品研发指导，PRD的内容应尽可能考虑完备，以方便开发过程中进行提前预留。假设产品具有社交功能，但是PRD第一版的书写中没有提前进行标注或声明，研发没有因此提前预留接口和数据库结构，待到要正式上线社交功能时，就需要对产品进行重新设计，过于费时费力。

具有优先级

一个完备的产品必然是考虑到方方面面的，既然存在多方面的情况，那么PRD应当对不同的内容和任务要标注不同的“优先级”，保证研发能够针对性的开展任务，而不是将过多的精力耗费在细枝末节上。

可验证

对于功能性的描述，是可以进行验证的，而不是无法验证，无法定性的东西。比如：交互体验完美、效率高等这种词汇是难以进行验证的，在PRD的书写中应尽量避免。

可追踪

每个功能性的需求的来源应该是清楚明白可以追踪的，对于日后产品功能的进一步升级或者删除都有意义。