核心定位¶
要解决什么问题¶
在很多团队中，需求是这样产生的：业务方说"我们需要一个XX功能"，产品经理画原型，开发实现，上线后发现业务问题根本没解决。
根本原因不是执行差，而是团队从一开始就在"假问题"上做"真努力"。
BRD 的作用是强制团队先定义问题，再讨论方案。
本质¶
BRD 只做一件事：把"要做什么"改造成"发生了什么"。
从「要做什么」→「发生了什么」：从结论回到现场
从「功能列表」→「业务场景」：系统不再是模块，而是行为的组合
从「直接给方案」→「延迟决策」：先把问题讲清，再决定怎么做
边界¶
BRD 只描述问题，不描述功能。
正确：描述业务痛点、卡点、后果
错误：描述"支持审批流配置"、“自动发送通知”
示例对比：错误（功能描述）假设支持审批流配置和自动通知；正确（能力变化）如果存在这样一个平台，能够让所有参与方在同一上下文中完成责任确认与反馈。
核心方法¶
场景定义¶
场景 = 一次完整的业务行为闭环，必须包含触发、过程、结果。
错误理解：一个按钮点击（太小）、一个公司级流程（太大）
正确认知：跨部门审批一次请求的完整过程
示例（以"员工报销多次被退回"为例）：触发是员工出差后需要提交报销申请；过程是员工填写报销单、部门负责人审批、财务复核、若不合规则退回重新提交；结果是报销成功或被多次退回，耗时长达数天。
标准结构¶
每个场景必须按照以下结构撰写：
场景 X：<场景名称>
工作角色：（谁在参与，各自承担什么行为）
问题：（业务是如何"卡住"的——触发、现状、困难、后果）
假设：如果存在这样一个平台，能够……示例：
场景：员工报销多次被退回
工作角色：发起方（员工）提交报销申请，上传发票，跟进审批进度；确认方（部门负责人）审核报销合理性、预算归属；复核方（财务）核对发票合规性、金额准确性。
问题：发起方不清楚差旅住宿标准，提交后被多次退回；确认方手动核对标准耗时长；复核方发现发票重复或金额不符。单次报销平均耗时5天。
假设：如果存在这样一个平台，能够在填写时自动提示标准上限、自动校验发票信息、审批时展示累计报销额和剩余预算。
如何写好问题¶
问题必须回答四件事：触发、现状、困难、后果。
错误写法（抽象）：数据同步效率低，存在信息孤岛
正确写法（画面感）：销售在客户现场签单时，需要反复打电话给仓库确认库存，导致单笔订单成交时间延长了20分钟，且经常出现"下单后发现无货"的尴尬。
示例（报销场景的问题）：触发是员工出差结束需要提交报销；现状是员工手动填写金额和费用类型，不清楚公司标准，部门负责人逐条核对预算科目，财务月底集中处理发票；困难是员工不知道标准被反复退回，负责人审批一条需8分钟，财务发现发票重复或抬头不全需逐一联系员工；后果是员工抱怨报销慢（平均5天），财务月底加班严重，公司合规风险上升。
假设句式¶
必须使用：如果存在这样一个平台，能够……
这是 BRD（问题空间）到 PRD（方案空间）的唯一接口。它既定义了需求边界，又给产品经理留下创意空间。
示例（报销场景的假设）：如果存在这样一个平台，能够在发起方填写金额和费用类型时自动提示对应标准上限，自动校验发票抬头、金额、日期并标记缺失信息，在确认方审批时展示该员工本月累计报销额及剩余预算，支持复核方一键比对电子发票与税务系统数据。
角色定义¶
角色不等于岗位。角色是"在某个场景中承担某种行为的人"。
错误（岗位）：产品经理、财务、CEO
正确（工作角色）：发起方、审核方、执行方、确认方
为什么用角色而不是岗位：岗位会随组织架构调整而变动，但角色在业务流中是稳固的。这能保证 BRD 的生命周期更长。
示例（报销场景的角色）：发起方（员工）提交报销申请，上传发票，跟进审批进度；确认方（部门负责人）审核报销合理性、预算归属；复核方（财务）核对发票合规性、金额准确性。
验收标准¶
一份合格的 BRD 必须同时满足以下四点：
能让不了解业务的人"看见现场"（画面感）
不包含任何具体功能描述
不同人读完，对问题理解一致
可被 QA 验证"问题是否被解决"
写完 BRD 后，用以下问题检验：是否很自然就能开始画功能结构；不同人是否可能提出不同的解决方案；大家对问题本身是否没有争议。
如果答案是是，说明 BRD 成功。否则，你只是写了一份"换皮的 PRD"。