产品经理核心资料之一，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框架是产品负责人核心的交付物，我更倾向于将它视为产品运作的核心区域，用以记载项目推进、产品规划步骤，或许今后不能称之为产品需求说明，而应称作产品规划文件，以此达成信息整合的目的。
依照我方所言，任何一份文件都折射出个人操作方式、任务范围界定以及集体协作默契，适宜的便是至上的，无需深究。
专栏作家
Kathic是人人都是产品经理专栏的撰稿人。他在B端领域有多年积累，专注于OMSTMSWMS这类供应链相关产品的开发工作。他秉持着察觉、认知、实践、总结的原则。
