第2章 PRD结构总览与模块划分

一份可落地、可追溯的PRD，不是填满字段的文档，而是需求从“业务问题”到“交付物”的结构化表达。本章拆解标准PRD的骨架、各模块职责，并给出推荐的阅读顺序，让你拿到任一PRD模板都能快速定位关键信息。

2.1 标准PRD骨架

经过大量B端/C端产品验证，标准PRD由5个核心模块构成，每个模块对应需求生命中的关键决策点：

2.2 各模块职责详解

2.2.1 业务背景与目标

本模块回答三个问题：为谁解决什么问题？现在是什么状况？期望达到什么效果？

• 用户场景：描述目标用户在什么时间、地点、触发条件下需要该功能。
• 业务问题：说明当前流程的数据/体验/效率痛点，最好附带用户访谈原话或截图。
• 业务目标：用可量化的指标定义成功，如“将用户从A到B的转化率提升20%”。

2.2.2 需求范围

本模块是PRD中最容易产生分歧的部分，需明确：

• 功能清单：按 Epic → Feature → User Story 层级拆分。
• 边界说明：明确“本版本不做”的功能，避免需求蔓延。
• 依赖关系：列出依赖的外部系统、第三方服务或前置功能。

2.2.3 功能方案

这是PRD篇幅最大的模块，需包含：

• 流程图：主流程、异常流程、分支流程。
• 界面交互：原型图 + 页面跳转关系 + 交互规则（如加载态、空态、错误态）。
• 业务规则：算法逻辑、权限控制、数据校验规则等。
• 非功能性需求：性能要求（响应时间<300ms）、兼容性要求（支持IE11以上）等。

2.2.4 数据指标

完成功能方案后，必须定义如何验证方案是否有效：

• 核心指标：与业务目标对应的KPI，如日活、转化率、留存率。
• 埋点需求：需要采集的事件、属性、上报时机。
• 指标基线：当前数值 vs 目标数值，如“当前转化率3.2%，目标6%”。

2.2.5 交付验收

本模块是PRD移交测试和开发的信令：

• 验收标准（Acceptance Criteria）：每条User Story对应1~3条可测试的条件，格式为“Given... When... Then...”。
• 交付物清单：PRD正文、原型文件、流程图、埋点文档、视觉稿。
• 风险与备选：已识别的风险（如第三方接口不稳定）和备选方案。

2.3 阅读顺序设计

不同角色阅读PRD的顺序不同，标准推荐如下：

2.4 成文要点

• 先骨架后血肉：在写正文前，先用5个模块搭建框架，确定每节的重点内容。
• 不同角色分屏阅读：PRD不是给一个人看的，在定稿前分别找开发、测试、运营按推荐顺序阅读，验证信息完整性。
• 版本变更只影响“方案”和“范围”：背景、指标、验收一旦定稿，仅在版本迭代时修正；不要让每次变更都重写整份文档。