第三章：需求文档（BRD/PRD）——如何精准捕获客户需求，避免需求蔓延

3.1 需求文档的本质：不是记录，是契约

很多人觉得写需求文档就是“把客户说的话记下来”。

我告诉你，这是最大的误解。

需求文档的本质，是一份可执行的契约。它约束的是双方——客户不能随便改，我们也不能随便做。

我在项目中遇到过最惨的一次：客户口头说“加个小功能”，开发顺手就做了。结果验收时客户说“这不是我要的”，然后要求重做。为什么？因为没有文档约束，双方的理解根本不在一个频道上。

3.2 BRD vs PRD：别搞混了

先搞清楚两个概念：

维度	BRD（商业需求文档）	PRD（产品需求文档）
写给谁看	老板、投资人、决策层	开发、测试、设计师
核心内容	商业价值、ROI、市场分析	功能逻辑、交互细节、数据定义
颗粒度	粗，讲“为什么做”	细，讲“怎么做”
典型输出	一页纸、PPT、商业画布	原型图、用例、字段表

我个人习惯：BRD控制在3页以内，PRD则要写到“开发看了不用问人”的程度。

3.3 捕获需求的“三问法”

客户说“我想要一个报表系统”。

你直接开始画原型？错。

我总结了一个“三问法”，帮你把模糊需求变成可执行需求：

1. 问场景：“这个报表在什么情况下用？谁看？多久看一次？”
2. 问目标：“看完报表后，你要做什么决策？或者解决什么问题？”
3. 问边界：“哪些数据必须包含？哪些数据可以不要？有没有优先级？”

举个例子：

客户说“我要一个订单管理功能”。

你问完三问后，发现真实需求是：“客服每天要查昨天未发货的订单，手动催单。他们需要看到订单号、客户电话、下单时间，并且能一键复制电话。”

你看，从“订单管理”变成了“催单列表+一键复制”。需求一下子就清晰了。

3.4 需求蔓延的根源与对策

需求蔓延，说白了就是“做着做着就多了”。

为什么会这样？

我分析过几十个项目，发现根源就三个：

• 需求没写清楚：客户以为A包含B，你以为A就是A。
• 没有变更流程：客户随口一说，开发随手一改。
• 没有验收标准：做完后客户说“这不是我要的”。

怎么治？

3.4.1 写清楚“不做什么”

很多PRD只写“做什么”，从来不写“不做什么”。

我建议你在文档里专门加一节：“本版本不包含”。

比如：

本版本不包含：
- 批量导入功能（计划V2.0）
- 数据导出为Excel（计划V2.1）
- 多语言支持（暂不考虑）

客户看到这个，就知道哪些是以后的事。不会在验收时突然说“怎么不能导出Excel？”

3.4.2 建立变更流程

我曾经在一个项目里吃过亏：客户在微信上发了一句“这里改一下”，开发就改了。结果改完客户说“我不是这个意思”。

后来我定了一个规矩：所有需求变更，必须走邮件或工单系统。口头说的不算。

流程很简单：

1. 客户提出变更
2. 评估影响（工期、成本、风险）
3. 客户确认评估结果
4. 更新文档并执行

3.5 需求文档的“黄金结构”

我写PRD多年，总结了一个结构，你可以直接套用：

1. 版本记录：谁、什么时候、改了啥
2. 背景与目标：为什么要做这个功能
3. 用户故事：谁用、怎么用、达到什么效果
4. 功能列表：每个功能的优先级、描述、验收标准
5. 数据定义：字段、类型、取值范围
6. 非功能需求：性能、安全、兼容性
7. 本版本不包含：明确边界

嗯，这里要注意：验收标准一定要写清楚。比如“搜索功能”的验收标准可以是：

验收标准：
- 输入关键词后，1秒内返回结果
- 支持模糊匹配
- 搜索结果按时间倒序排列
- 无结果时显示“未找到相关数据”

开发看到这个，就知道做到什么程度算“完成”。测试也知道怎么测。

3.6 一张图看懂需求管理流程

下面这张图是我自己画的，把整个需求捕获到落地的流程串起来了。你写文档时可以参考这个逻辑。

3.7 避坑指南：我曾经踩过的坑

最后分享几个我亲身经历过的坑，你遇到了可以绕开走：

• 坑1：客户说“你先做，我后面再补需求文档”。——千万别信。没有文档，后面全是扯皮。我吃过这个亏，后来坚持“没有文档不动工”。
• 坑2：验收标准写得太模糊。——比如“界面要好看”。什么叫好看？每个人的标准不一样。改成“按钮颜色统一为蓝色，字体大小14px，间距16px”。
• 坑3：需求文档写完后就不管了。——文档要持续更新。每次变更都要同步更新文档，否则文档和代码就“分家”了。

---