作为产品经理三大文档之一，PRD在我们的日常工作中使用频率最高，对其细节的要求也就越高。本文作者分享了自己数年经验的一份B端产品的模版，供大家参考学习。

网络上PRD模板非常多，工作多年的产品经理对于PRD如何撰写也基本能达成一个共识。任何一个模板都是产品经理个人工作经验的体现，也是一个组织管理方式的抽象，道以术显。

所以我仍然想分享一下我的PRD模板，明晰PRD中每个模块的作用和要求，在这个过程中，读者可以一窥第三方的产品全生产要素及全生产过程管理的方式，可能会对你后续的工作提供一些清晰的思路。读者也可以根据团队共识的沟通方式、项目管理方式、产品形态特征等灵活裁剪使用。

一、基础信息

1.1 填写逻辑说明

1.2 应用实例

OMS341_订单管理系统_异常监控策略调整_王KA_240911

1、版本记录

2、需求背景

3、评审记录

4、项目计划

// 明确里程碑节点，说明事项负责人，压实责任。明确风险及应对措施。明确前置依赖条件及输出物。

5、附录链接

// xxxxxx.doc

// xxxxxx.doc

二、需要分析

2.1 填写逻辑

2.2 应用实例

6、涉众分析

7、产品路线图

三、业务建模

3.1 填写逻辑

3.2 应用实例

8、关键术语

9、业务概念分析

// 类图是对需求中的业务概念、角色等的抽象

// 类图包含类名、属性、操作

// 类之前的关系有：关联、依赖、强包含、弱包含、继承等

// 类之间可以有1对1，1对N等关系

10、业务流程分析

// 应区分业务流程图与系统流程图，业务流程图中泳道表示角色，用来梳理当前及优化后的业务流程。系统流程图更偏向于区分系统边界及系统间交互方式。

// 状态机图以圆角矩形代表一个业务的状态，状态刻画了业务的节点。

// 使用箭头表示状态的转换，刻画了业务动作与判定逻辑。

// 通信图刻画了多个系统间的信息传递机制，在涉及多系统协同时，梳理系统通信图有助于从信息流的维度暴露设计问题，也有助于研发理解需求。

// 使用用例图分析角色之间的继承关系，系统功能的边界、功能的包含或拓展关系

12、产品架构图

// 明确产品蓝图，也可标记出当前哪些是已有功能，哪些是需要改造、新增的，哪些是后续迭代的，注意做好图示。

13、页面走查

四、产品规格说明

用于定义软件产品的功能、特性、性能和约束条件。其目的是为开发团队、质量保证人员、项目经理以及其他相关人员提供一份清晰、统一的技术蓝图。

4.1 应用实例

1、功能性需求

// 页面跳转逻辑说明（写明触发条件，操作手势，跳转逻辑判断，反馈）

// 字段取值逻辑说明（使用表格方式罗列）

// 数据加工逻辑说明（复杂逻辑可以用思维导图、表格、伪代码方式进行说明，并罗列实例补充说明）

2、非功能需求

// 权限需求

// 性能需求

// 埋点需求

// 历史数据处理需求

另外，大家常常混淆产品需求文档PRD、产品规格说明书，一般来说，PRD 更侧重于从用户和市场的角度定义产品的需求和目标，而产品规格书则是对这些需求进行技术层面的详细说明，确保开发团队能够有效地实现这些需求。但是我的模板并不想辨析这些概念，PRD模板作为产品经理的主要输出物，我更多把它当作产品工作的主阵地，来记录项目管理、产品管理进程（可能已经不能叫产品需求文档了，而叫做产品管理文档），实现信息的all in one。

就像我说的，任何一个文档都是个人工作习惯、岗位职责边界和团队工作共识的体现，合适的就是最好的，不要纠结。

专栏作家

Kathic，专栏作家。深耕B端多年，致力于OMSTMSWMS等供应链相关产品设计。“发现、洞见、行动、反思”是我的信条。

本文原创发布于，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议