编辑导语：PRD文档撰写恐怕是产品经理必备技能之一。那么，产品小白在入手撰写PRD文档时可能会有哪些混淆之处？如何撰写才可以做到完整且便于梳理呢？本篇文章里，作者就列出了撰写PRD文档的几点注意事项，相信会对初入行的你有所帮助。
都说产品经理有3大文档：BRD、MRD、PRD。日常工作中很多产品早已由领导层定好了方向，所以BRD和MRD的编写机会较少，更常用的是在产品细化阶段所用到的PRD。
PRD在项目中起什么作用？什么才是好的PRD？PRD要如何编写？本文将依次回答相应问题，如有错漏还请指教。
一、PRD作用：要你有什么用？PRD是将产品需求和对应需求解决方案一起呈现的文档。文档面向项目相关的多方角色，在项目推进中承担了重要作用，比如：
- 产品：根据PRD进行方案宣讲，并作为最终检验产品实现程度的依据；
- 设计：根据PRD的原型作为UI设计参考；
- 开发：根据PRD的系统规则等内容作为研发依据；
- 测试：根据PRD的规则来编写用例及测试。
根据需求的覆盖情况也会有其他角色参与，如运营、商务、财务等。不管面向谁，最终目的都是为了让团队成员能够理解业务，在产品研发过程中得到更好地执行。
二、PRD要求：想要我怎样？为了PRD更好地发挥作用，编写文档时需要清晰、完整且容易阅读的方式将复杂抽象的解决方案呈现出来。怎么才能达到这样的效果呢？文档起码需要符合以下要求：
- 场景完整：需要考虑需求相关的各业务场景，尤其是特殊场景的应对机制。避免场景缺失造成方案漏洞。
- 框架清晰：提供系统架构、业务模型、功能结构、系统流程等系列框架，帮助成员从全局层面了解系统概况。
- 逻辑自洽：系统操作涵盖业务的正向和逆向流程、主流程和分支流程，形成系统操作闭环且不冲突。
- 规则简明：对系统全局说明、功能模块、非功能需求等各项规则进行描述，编写需通俗且完整。
- 设计友好：系统页面的布局、导航、交互、文案等交互动作，设计需要符合尼尔森可用性原则。
结合具体情况，PRD编写时也会存在其他要求。比如非功能性要求（数据指标需求、运营需求……），也要做到对要求的定义明确无异议。
三、PRD编写：注意你的尺度！知道了PRD的要求，编写时可以向要求靠拢。但是要求只能作为指导思想，却没有告诉我们具体怎么编写，你可能还有这些疑问。
1. PRD要用什么形式呈现？PRD常见形式有2种——word和原型。2种形式各有优劣，比如word版的目录让人更容易总览全局；原型版在功能需求描述时表现更灵活。
采用那种方式要先看公司制度，如有相应规范直接执行即可（规范也可以调整），如果公司没有要求，则产品经理经过和团队沟通，采用大家认可的、更方便表达和阅读的方式即可。
2. PRD要写到什么颗粒度？写过PRD的同学应该都有过这个疑问。尤其是对规则的描述，写粗了怕有遗漏，写细了怕没人看。除了描述上精简用词，还能从规则提炼和原型设计上进行把控。
- 规则提炼：对约定俗成的规则、可复用的规则的通过“全局说明”进行描述。如手势操作、输入框定义及限制等。
- 原型设计：输出的原型不要有高保真原型，耗时且影响UI发挥；不要有复杂交互，不利于快速识别，可在备注中说明；不要过度设计……
对过往项目的PRD常用组成部分进行总结，从通用、概要、详细等部分来拆解，仅供参考。每份PRD的具体组成需要项目结合实际情况进行增删。
- 通用部分：名称、目录、更新记录；
- 概要部分：项目背景、预期收益、方案概述、项目范围、项目风险；
- 详细部分：产品框架、全局说明、原型页面、功能需求、非功能需求 。
终于到了编写环节！PRD制作是产品经理的基础工作之一，能够直观反映产品经理的底层专业能力是否扎实。现在知道了PRD的组成，接下来以原型版为例具体说说各部分如何编写。
1. 通用部分1）文档名称
文档名称是为了能区分不同产品和版本。常规命名方式是产品名称+版本号。这里“版本号”的命名每个公司都不一样，可以用V1.0或日期作为版本号。能识别并快速区分即可。
如：XX车辆租赁管理系统V1.0；XX车辆租赁管理系统-210504。
2）文档目录
一般word形式的PRD会配有文档目录，让阅读者更直观的了解全局。使用原型版本也可以做到类似的效果，可以单独用页面定义为“目录”，将word版本的内容放进去，也可以通过对原型页面的规则命名达到此效果。如下图（部分页面做了隐藏）。
3）更新记录
每次PRD的更新一定要进行记录，帮助阅读者了解每次更新的内容。更新记录一般以表格形式呈现，主要字段包含：更新时间、变更属性（新增、删除、修改）、更新内容、更新人员。
1）项目背景
背景描述是为了让阅读者了解项目或需求的来源和具体情景。
背景包含了业务概况、业务流程、当前问题、整体解决思路等相关内容。相应内容在用户调研和编写整体解决方案时都会涉及，可直接使用。编写方法详见《B端产品设计：整体方案长这样？》。
2）预期收益
产品研发是公司商业行为的延伸，一定会有商业目标（预期收益）。定制化产品是为了实现客户对项目的目标期望（从乙方角度，客户验收通过即可），自研产品的预期收益则不能简单粗暴的直接用业务收益来定。
对于B端自研产品的预期收益制定需要符合SMRAT原则，可以考量功能使用率、客户满意度等。
3）方案概述
方案概述是为了让阅读者从全局层面了解方案设计的思路，不至于直接陷入细节中。
什么是方案概述呢？基于整体解决思路进行拓展，针对痛点问题描述产品的核心功能模块、技术实现方案、运营支持方案等内容。
4）项目范围
系统不可能解决所有问题，所以会有边界。
项目范围是指产品所涉及的业务范围、所关联的系统等。
项目实施前需要及时和项目相关方（干系人）确定项目的范围、实施时间、消耗资源（成本），避免关键信息沟通不畅导致的项目风险。
5）项目风险
风险是任何事项都不能忽视的问题。提前预设风险项及解决方案，从而降低失控概率。项目中存在哪些风险项呢？
- 流程：没有明确的规范流程；进度更新不及时；任务汇报占用资源过多（人员、时间）……
- 计划：重要事项遗漏；用时评估不合理；任务分配不合理；计划没有预留缓冲时间……
- 人员：人员不足；新人员的适应成本；任务和人员技能的不匹配……
- 沟通：信息传递机制不到位导致沟通效率低（传递方式、触发传递条件、指定对接人）……
- 需求：需求变更；变更导致的工作调整（项目计划、设计、开发、测试）……
- 技术：开发环境不稳定；技术难点评估不足；开发和测试用时评估不准；三方系统对接进度延期……
- 其他：服务器没到位；市场及政策问题……
1）产品框架
产品框架是系列组成图表组成，为了阅读者更深刻的理解产品在组成和结构。包含以下：
- 系统架构图：通过不同层级开展现系统的功能模块，表达功能层面的概况。
- 功能结构图：系统结构的拆解，是一级菜单>二级菜单>具体页面>操作项的细化。再细化到字段，就成了信息架构图。
- 操作流程图：用户使用系统时如何通过系列操作完成对应任务的过程。
- 状态机图：描述各关键节点的状态如何触发和流转。如订单状态的变化。
以下是过往项目的示例，部分内容做了简化。如下图。
图：系统架构图
图：功能结构图
图：系统操作流程图
图：状态机图
2）全局说明
针对全局通用的术语、缩略语、交互、系统规则、异常情况等相关内容，可以在全局说明中统一说明。避免在文档中反复出现，导致文档臃肿，造成阅读困难。
比如：输入框定义、类型、数字限制等，分页规则，各类型弹窗交互说明等。
异常情况则包含了断网、误操作、数据丢失等情况，需要描述对应情况下如何处理，也可以写在具体功能需求描述中。
3）原型页面
原型是对最终产品各页面上内容的呈现，阐述了用户与产品之间交互过程。通过产品架构可以得出需要设计的页面和页面元素。关于原型工具选择、配色选择、页面类型、交互注意事项等内容详见上一篇《B端产品设计：拆个“详细设计”给你看》。
原型页面通常和规则一起进行呈现，页面旁边是规则备注。
4）功能需求
针对每个页面、弹窗进行详细的功能描述，将功能逻辑、字段规则等信息描述清楚。同时尽量采用分段的陈述式描述，避免大段论述型描述。更详细的内容新开文章介绍。
图：原型页面+规则备注
5）非功能需求
除了功能需求的描述，千万不要忘了非功能性需求。非功能性需求有很多种，也会涉及多个相关方，要结合具体项目具体需要进行设计。常规比如性能需求、运营需求、数据统计需求等。
- 性能需求：性能需求需要考虑用户体验和资源投入成本，比如响应时间、最大并发量、兼容性需求……
- 运营计划：产品配套的运营推广计划，设计运营方，产品设计时需要确认并记录。
- 数据统计：可根据产品需求进行数据埋点要求设计，进行埋点监控，如按钮、页面、事件等。可以自己埋点，可以使用市场成熟的数据采集软件。
以上。
本文由 @耳目不染 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议