PRD 书写推理依据(提炼自 PRD 教程原文)
本文件把 PRD 教程原文的方法论提炼为可执行的推理依据。写 PRD 的每一个判断都回到这里,不得偏离。
0. 什么是 PRD 与前置依赖
- PRD = Product Requirement Description(产品需求描述),本质是「定义这个产品是干什么的、解决什么问题」。
- 必须能用一句话把产品定义清楚;写不出来或定义不清 = 产品本身没想清楚。
- PRD 必须依照 BRD 来写,一定在 BRD 确定之后;没有需求支撑,做不出好产品。
1. 一句话定位:宏观统一
- 一句话定位的核心作用是「统一所有人在开发过程中对产品的看法」——在大的宏观层面统一。
- 后续所有产品定义都从这一句话逐渐提炼,而不是另起炉灶。
2. 用户 Person 与干系人:按产品定人,不套固定模板
- 干系人不是固定清单——不同产品的用户不一样,不能照抄某个项目的角色。
- 动手前先联网搜索「现在都有谁想要这个产品、谁在使用、谁受交付影响」(目标用户、采购/决策方、集成/运维方、验证/监管方等),再结合用户上下文落到具体角色。
- 教程里「集成工程师 / 验证工程师 / 算法工程师 / 项目交付负责人」只是某个嵌入式产品的示例,不是通用模板。
- 每个角色都要写清「关注结果」和「参与方式」。
3. 场景与关键任务:咬文嚼字式拆解
- 做产品(写 PRD)和描述需求不是一回事:模糊需求必须拆成具体、可测的子项。
- 例:模糊的「精度」→ 拆成「血氧 + 血压」两件事 → 每件再拆成「测量精度 + 测量时间 + 测量范围」。
- 不拆 → 执行时必然被钻空子;人和人配合复杂,大方向统一 + 小细节统一 = 管理难点。
- 干系人「用什么样的方式去验证」也要一并定义清楚。
4. 指标三要素:可观察指标 / 通过口径 / 用户可见证据
- 每个指标必须同时具备「可观察指标」+「通过口径」+「用户可见证据」。
- 用户不关心内部指标,只关心可对比、可复现的结果(买西瓜:不研究含水量,只看重量/声音/口感)。
- 证据应是「用户人手可对比」的那种(如测量值与真实值偏差在正负 X 内)。
5. P0/P1 拆解
- 拆出来的需求很多,必须拆清「一定实现」(P0)与「优先实现」(P1),以及非目标。
6. 验收场景与里程碑
- 验收场景含选型冻结、方案冻结、开发资源协调冻结等固定关卡。
- 第一版一定先找 M1(第一个里程碑)去完成,再往后迭代。
7. Owner 链接:每个需求有负责人
- 每个具体功能都沉淀并链接到具体 Owner;安排完后,他对着需求去分析。
8. 拆解到 SyRS 与任务
- PRD 拆解到 SyRS 作为系统定义;系统定义逐条展开到每个人完成的具体任务。