这不是写文档，这是做一件具体的工作。在开始之前，先统一一个认知：写 BRD 不是"整理需求"，而是还原业务现场 + 拆出真实问题。你要做的不是写字，而是完成一次"问题建模"。
整体流程¶
一份合格的 BRD，必须按以下流程产生：选择场景 → 还原现场 → 找出卡点 → 结构化问题 → 写假设。不要跳步骤，否则一定会写歪。
Step 1：选择场景¶
怎么选：选一个你能回答下面三个问题的场景：谁在做这件事？什么时候发生？做完算结束了吗？如果答不清，就说明场景不成立。
示例：错误（系统视角）用户管理、审批模块；正确（行为视角）一次跨部门审批从发起到结束、一次任务分配到执行完成。
Step 2：还原业务现场¶
这一阶段不要写文档，只做一件事：把事情"讲清楚"，像在复盘一个真实事件。
用这个方法：把场景当成一段"录像"，回答：事情是怎么开始的？中间发生了什么？有哪些人参与？最后怎么结束？
示例（口语版）：有人发起一个审批，然后去群里 @ 人确认，有人没回，又私聊，再去邮件补，中间经常搞不清谁该批，最后拖了两天才结束。这一步不用规范，只要真实。
Step 3：找卡住的地方¶
现在从刚才的过程里找出：哪些地方让人不顺、反复、出错？
常见卡点类型：反复确认（来回沟通）、信息不同步（多个渠道）、责任不清（不知道谁负责）、流程中断（没人推进）。
示例：从刚才场景中抽出要反复确认谁负责审批、信息散落在多个工具中、有人遗漏导致流程中断。
Step 4：写结构化问题¶
把刚才的卡点整理成标准结构：在什么情况下（触发），现在怎么做（现状），卡在哪里（困难），导致什么问题（后果）。
示例：在跨部门审批时（触发），发起方需要通过多个沟通工具逐一联系审核方确认参与（现状），过程中经常出现责任不清或信息不同步（困难），导致审批周期延长至 2-3 天（后果）。
Step 5：写假设¶
现在只做一件事：想象一种"更顺"的状态。
用固定句式：如果存在这样一个平台，能够……
示例：如果存在这样一个平台，能够让所有参与方在同一上下文中完成责任确认与反馈，并保持信息同步……
注意：如果你写出了以下这些词，说明你写错了：配置、功能、模块、自动化。这些属于 PRD，不是 BRD。
Step 6：补充工作角色¶
最后再定义角色（不要一开始就写）。
方法：从刚才的过程里抽象——谁发起 → 发起方；谁处理 → 执行方；谁确认 → 审核方。
示例：发起方提交审批请求并推动流程；审核方对请求进行审核并反馈意见。
拼成完整 BRD¶
现在把所有内容拼起来：
场景一：跨部门审批协同
工作角色：发起方提交审批请求并推动流程；审核方对请求进行审核并反馈意见。
问题：在跨部门审批时，发起方需要通过多个沟通工具逐一联系审核方确认参与，过程中经常出现责任不清或信息不同步，导致审批周期延长至 2-3 天。
假设：如果存在这样一个平台，能够让所有参与方在同一上下文中完成责任确认与反馈，并保持信息同步……
快速自检¶
问自己四个问题：
能不能"看见现场"：读完之后，是否能想象发生了什么？
有没有偷偷写功能：有没有出现配置、系统、自动？
问题是不是具体的：有没有类似"效率低""体验差"这种空话？
别人能不能复述：让另一个人读一遍，如果，他理解的和你想的一样，说明写对了。
最重要的经验¶
不要一开始就写文档。正确顺序是：讲清楚（口头） → 写问题 → 再整理成 BRD。
如果你写得很顺，可能写错了，因为真正的业务问题一开始一定是混乱的、不清晰的。
一句话总结¶
BRD 不是写出来的，是"从混乱中提炼出来的"。如果你只是坐在电脑前"编"，那一定是假的。
进阶：BRD 的机制设计¶
很多人学 BRD 会觉得是在学"怎么写文档"，但实际上这套方法的本质是在构建一套"控制认知偏差的机制"。以下是几点深层洞察：
1. 真正的问题不是"不会写"，而是过早下结论¶
很多方法教的是怎么表达清晰、怎么写结构。但 BRD 在解决一个更本质的问题：人一旦看到问题，就会立刻脑补解决方案。
所以设计了三道"刹车"：
场景（把人拉回现场）
问题结构（强制拆解因果）
假设句式（延迟方案出现）
这本质是在做：防止思维短路。
2. BRD 的本质不是"表达"，而是建模¶
把模糊的业务感受，转成结构化、可验证的模型。
关键变化：
“流程很乱”（感受）
“在X场景下，由于Y行为，导致Z结果”（模型）
这一步一旦成立，后面所有东西（PRD、QA、数据）才有锚点。
3. 切断"方案的正当性来源"¶
在大多数团队里，方案的正当性来自：经验、职级、话语权。
而 BRD 在做的是：只有"问题被清楚描述"，方案才有资格出现。
这会带来变化：讨论从"谁说得对"变成"问题有没有被描述清楚"。
4. 做"组织级的对齐工具"¶
它真正解决的是：不同人脑子里的"问题版本不一样"。
通过结构强制实现：同一个场景、同一组角色、同一条因果链。让认知收敛。
5. 延迟收敛¶
大多数团队的问题是：太快收敛（直接做方案）、太早锁死（改不动）。
BRD 这套是：在问题阶段尽可能发散，在方案阶段再收敛。这是一个决策节奏设计问题，而不是文档问题。
总结¶
BRD 本质不是"写需求"，而是在设计一个机制：让团队只能在"问题清楚之后"才允许开始思考解决方案。
这套方法可以看作是"组织认知操作系统的底层协议"。如果再往前推一步，BRD 还需要反向约束 PRD（防止产品经理重新带偏），那一层一旦打通，体系才真正闭环。