第07章 需求文档化

第06章解决了「这个需求值不值得做」，但验证通过不等于可以开工。你还需要把口头需求、访谈记录和零散判断压成一份可执行契约。本章解决的是：怎么把模糊变成范围，把范围变成验收。 第08章会继续处理需求阶段最常见的失败边界。

7.1 结论先行：需求文档不是写给别人看的，是写给交付闭环看的

需求文档的本质不是 PRD，不是漂亮排版，也不是会议纪要。它是交付闭环的入口文件。

需求文档 = 背景 + 用户 + 场景 + 范围 + 非目标 + 验收标准

呼应第01章的公式二：交付闭环 = 范围 → 实现 → 验证 → 验收。需求文档负责把第一环「范围」钉死。如果范围没有被钉死，后面的实现越快，返工越快；验证越认真，发现错得越彻底；验收越正式，扯皮越严重。

铁律：没有需求文档的项目，不是敏捷，是裸奔。

7.2 需求文档是什么：定位、能力与边界

形式	作用	风险
聊天记录	保存上下文	噪音多、无结构、无法验收
脑图	梳理想法	边界不清、容易发散
传统 PRD	适合团队协作	对一人公司过重
一页纸需求文档	锁范围、定验收	需要强制取舍

一人公司需要的不是大公司式 PRD，而是一页纸需求契约。它只回答六个问题：为什么做、给谁做、在什么场景用、做哪些、不做哪些、怎么验收。

7.3 一页纸需求文档模板

# 需求名称：

## 1. 背景
用户现在遇到什么问题？这个问题来自哪条证据？

## 2. 目标用户
谁会使用？谁会付费？谁会验收？三者是否一致？

## 3. 核心场景
用户在什么时间、什么地点、带着什么任务使用？

## 4. 本次范围
- 必须有：
- 可以没有：
- 明确不做：

## 5. 验收标准
- [ ] 标准1：
- [ ] 标准2：
- [ ] 标准3：

## 6. 风险与假设
- 最大假设：
- 最大风险：
- 下一步验证：

这个模板的关键不是完整，而是能阻止范围漂移。尤其是「明确不做」和「验收标准」，它们是需求文档里最值钱的部分。

7.4 从访谈记录到需求文档

访谈原话 → 行为证据 → 底层任务 → 本次范围 → 验收标准

访谈原话	行为证据	文档写法
“我想要自动生成报告”	每周手工整理 3 小时	目标：减少报告整理时间
“最好能一键导出”	需要发给领导审批	验收：导出 PDF 可直接发送
“功能越多越好”	实际只反复用 2 个字段	非目标：暂不做复杂报表

你不能把用户原话直接写进需求文档。 用户说的是表层诉求，你要翻译成任务、范围和验收。

7.5 实战：把一个需求写成可执行契约

操作步骤：

1. 把第05章访谈记录中的高频行为摘出来。
2. 用第06章验证结果筛掉没有付费意愿的诉求。
3. 写一页纸需求文档。
4. 把文档发给对方确认，要求对方只回答：范围是否正确、验收是否接受。

验证标准：

合格需求文档的四个判断：
- 陌生人读完知道要做什么。
- 开发前知道什么不做。
- 交付前知道怎么测。
- 验收时不用重新解释。

7.6 需求文档 vs 任务清单 vs 合同

维度	需求文档	任务清单	合同
解决问题	做什么	怎么做	权责与付款
粒度	中	细	粗
变更方式	需求变更	任务调整	补充协议
谁确认	需求方/客户	执行者	双方

决策树：

还没确认做什么 → 写需求文档
已经确认做什么 → 拆任务清单
涉及付款/权责 → 写合同或确认单

7.7 失败边界：三种文档死法

死法一：文档过重

写成几十页 PRD，结果没人读。对抗策略：一人公司默认一页纸，除非项目金额和团队规模足以支撑重文档。

死法二：只写功能，不写验收

功能清单很多，但没有「怎样算完成」。对抗策略：每个功能后面必须跟至少一条可验证标准。

死法三：没有非目标

没有明确不做什么，客户会默认什么都包括。对抗策略：每份文档必须有「明确不做」。

红线边界

• 涉及付款、版权、数据安全、生产环境的范围，不能只靠聊天记录确认。
• 涉及客户数据的需求，必须写清使用边界与删除机制。

7.8 小结 / 核心心法

需求文档的价值，不在写得多完整，而在让错误更早暴露。

1. 需求文档是交付闭环的入口，不是形式主义。
2. 一人公司优先用一页纸需求契约。
3. 「非目标」和「验收标准」比功能描述更重要。
4. 用户原话要翻译成任务、范围和验收。

执行清单：

• [ ] 每个新项目是否有一页纸需求文档？
• [ ] 是否写了「明确不做」？
• [ ] 是否有可勾选验收标准？
• [ ] 对方是否确认过范围？

---

上一章：第06章 需求验证：最小成本证伪 下一章：第08章 需求的失败边界