课程库 › 产品设计 › PRD 写作 · 从决策到文档 › 第 4 课
依赖、验收标准、成功指标 —— PRD 的工程接口
普通课约 35 分钟
本课导读
PRD 的最后三个部分，各自对接一个下游环节：依赖对接排期（什么必须先就位）、验收标准对接测试（怎么算做完）、成功指标对接复盘（怎么算做对）。它们是新手最常整段跳过的三部分——也因此是延期、扯皮和"上线即失忆"三大惨案的直接责任人。本课把三个都补成肌肉记忆。预计 35 分钟。
说明
前置工具箱：上一课的需求编号（FR-x，验收标准要挂在它上面）；战略层的成功指标（本课的成功指标是它在功能粒度的落地）；用户角色清单里的"系统角色"（依赖的线索藏在那里）。
依赖：这个功能不是孤岛
依赖（Dependencies）的职责：指出集成关系、先后次序、系统间关系。翻译成排期语言就是：哪些东西不就位，这个功能就动不了工。三类常见依赖：
- 系统依赖：要调用/集成的服务与接口。"导出功能依赖笔记服务的批量读取接口"——上一课埋的伏笔：角色清单里的系统角色，逐个检查就是依赖清单的初稿
- 时序依赖：什么必须先发生。"批量读取接口月底上线，本功能开发可并行、联调必须在其后"——写清先后，排期才排得出关键路径
- 团队/外部依赖：需要别人配合的事。第三方审核、法务合规、其他团队的人力——跨团队依赖是延期概率最高的一类，越早写出来越早能去排队
写法上每条依赖标三样：依赖什么、影响哪些需求条目（FR-x）、不就位的后果。评审时这部分是工程师的主场——把他们的补充原样记进来，这正是 PRD 作为协作文档的用法。
说明
不写依赖的 PRD 有个经典死法：开发进行到 70% 才发现要等一个别的团队的接口，而那个团队的排期在下季度。依赖部分的本质是把"惊吓"提前变成"计划"——惊吓的成本按周计，计划的成本按行计。
验收标准：把"做完了"变成可判定命题
验收标准（Acceptance criteria）的职责：确立验证功能就绪的条件。它和功能需求的分工经常被混淆，一句话切开：需求说系统该有什么行为，验收标准说怎么证明这个行为真的对。推荐格式是三段式 Given-When-Then：
Given（前置状态）用户有 47 篇笔记且已登录 When（动作）在笔记页点击"全部导出"并等待完成 Then(可判定结果) 浏览器下载一个 zip；解压后恰有 47 个 .md 文件；文件名与笔记标题一致，非法字符已替换为下划线
三条纪律：
- 每条 Then 必须可判定——是/否一眼定，不许出现"正常""合理""较快"这类要开会解释的词
- 覆盖边界，不只主流程——上一课六问挖出的每个重要边界情况，至少配一条 AC（"Given 导出进行中断网，Then 提示重试且本地无残缺文件"）。AC 数量的经验感觉：边界的条数常超过主流程
- 挂在需求编号上——AC-2.1、AC-2.2 挂在 FR-2 下面。测试拿它直接变测试用例，验收会上逐条打勾，没有任何"我以为"的空间
提示
类比记忆：需求和验收标准的关系是菜谱和试菜标准——菜谱说"糖醋排骨要收汁"，试菜标准说"筷子夹起时酱汁挂壁不滴落"。只有菜谱没有试菜标准，厨房和前厅会为"算不算收汁"吵到打烊。
成功指标：上线不是终点，是实验开始
成功指标（Success metrics）的职责：定义上线后评估功能影响的指标。它回答的不是"功能可用吗"（那是验收标准的事），而是"当初概述里承诺的价值，兑现了吗"——所以第一步永远是回翻概述的"挂钩"句，让指标与承诺对齐。写一条合格的成功指标要四件套：
- 指标：量什么（导出功能使用率、导出后 30 天留存差异）
- 基线：现在是多少（没有基线的指标无法判断变化——上线前就得埋点或取数）
- 目标：期望变成多少（写下数字就是立靶子，不敢写数字常说明战略层没想清）
- 时间窗：看多久（两周？一个月？没有截止的观察等于没有观察）
再配一个反指标（guardrail）：这个功能不应该弄坏什么。"导出高峰不得拖慢正常页面响应"——防止局部优化伤害全局。
最后是闭环动作：在 PRD 里预约复盘——写明"上线后第 X 周，对照本节指标出一页复盘"。没有这行字，90% 的功能上线即失忆，团队永远在凭感觉迭代;有了它，每个功能都变成一次校准判断力的实验。这正是第一单元战略层"可证伪"原则在文档里的最终着陆。
✍️ 练习
练习 1：给边界情况配 AC
上一课练习里"上传头像"的两个边界：① 上传中断网；② 连点三次上传。给它们各写一条 Given-When-Then，确保每个 Then 可判定。
✅ 参考答案
- AC-①：Given 用户已选择 5MB 图片且上传进行中，When 网络中断超过超时阈值，Then 页面提示"上传失败，点击重试"；用户头像保持原图不变；服务器无残缺文件
- AC-②：Given 上传请求已发出且未完成，When 用户再次点击上传按钮，Then 按钮处于禁用态，点击不产生新请求（可用请求日志判定）
自查：每个 Then 是否"是/否一眼定"？"提示友好的错误信息"就不合格——"友好"要开会解释；"提示文案为'上传失败，点击重试'"才可判定。
练习 2：四件套 + 反指标
给"Quiz 错题本"功能（上一课练习 1）写成功指标：一个主指标（四件套齐全）+ 一个反指标。假设的基线数据可以虚构，但要标注"假设"。
✅ 参考答案
- 主指标：错题重做率——答错的题在 14 天内被重做的比例。基线：0%（当前无此功能，错题散落无法重做——假设）。目标：上线一个月后达到 40%。时间窗：上线后第 2、4 周各取一次数
- 辅指标（可选）：重做后的答对率是否高于首次（验证"重做真的带来掌握"，而不是机械刷题）
- 反指标：Quiz 整体完成率不下降——防止"错题压力"让用户干脆不做 Quiz 了（这正是试点单元的核心观测指标，不能被新功能误伤）
- 预约复盘：上线后第 4 周，对照本节出一页复盘，决定错题本是否进入下一轮迭代
📝 随堂测验
1. PRD 最后三部分各自对接的下游环节是？
2. 排查系统依赖最顺手的线索来自 PRD 的哪个部分？
3. 功能需求和验收标准的分工是？
4. “Then 系统给出合理的错误提示”这条验收标准的毛病是？
5. 成功指标的“四件套 + 反指标”是？
本课小结
- 依赖三类：系统/时序/团队；每条标"依赖什么 + 影响哪些 FR + 不就位的后果"——把惊吓提前变成计划
- 验收标准用 Given-When-Then：Then 可判定、覆盖边界、挂在 FR 编号上——测试直接变用例
- 成功指标四件套：指标/基线/目标/时间窗 + 反指标 + 预约复盘——上线是实验的开始
- 三部分共同点：都是把"以后会吵的架"提前用一行字摆平
下一课收官项目课：8 个部分全部就位，拿你自己的真实需求写一份完整 PRD——第一单元的五层文档将在那里升级成能开工的正式文档。
划选正文任意文字可高亮、批注或加入复习卡
讨论
载入中…