product-brd

name	product-brd
description	业务需求文档（BRD）编写技能。用户需要编写或评审 BRD 时使用，指导围绕业务场景组织文档，以问题为中心，包含标准结构、问题四要素、假设句式等规范。

product-brd

业务需求文档（BRD）编写技能。

核心定位

BRD 只做一件事：把「要做什么」改造成「发生了什么」。

三改变

• 从「要做什么」→「发生了什么」：从结论回到现场
• 从「功能列表」→「业务场景」：系统是行为的组合
• 从「直接给方案」→「延迟决策」：先把问题讲清，再决定怎么做

边界

BRD 只描述问题，不描述功能。

错误：假设支持审批流配置 正确：如果存在这样一个平台，能够让所有参与方在同一上下文中完成责任确认

标准结构

每个场景必须按以下结构撰写：

## 场景 X：<名称>

### 工作角色
（谁在参与，各自承担什么行为）

### 问题
（触发、现状、困难、后果）

### 假设
如果存在这样一个平台，能够……

问题四要素

问题必须回答四件事：

1. 触发：什么情况下发生
2. 现状：现在是怎么做的
3. 困难：卡在哪里
4. 后果：导致了什么

示例：

错误：流程效率低

正确：在跨部门审批时（触发），发起方需要通过多个沟通工具逐一联系审核方（现状），过程中经常责任不清（困难），导致审批周期延长至2-3天（后果）

假设句式

必须使用：如果存在这样一个平台，能够……

这是 BRD 到 PRD 的唯一接口，定义需求边界，给产品经理留创意空间。

角色定义

角色不是岗位，是「在某个场景中承担某种行为的人」。

错误：产品经理、财务、CEO 正确：发起方、审核方、执行方、确认方

验收标准

• 能让不了解业务的人「看见现场」
• 不包含任何具体功能描述
• 不同人读完，对问题理解一致
• 可被 QA 验证问题是否解决

检验：很自然就能开始画功能结构；不同人提出不同方案；大家对问题没有争议。

相关文档

BRD → PRD → IXD → ADD，QA 验证所有层。