需求分析到量产部署完整路径 - 第4节

4. 需求文档撰写:BRD、MRD、PRD 的区别与联系

说实话,我刚入行那会儿,最头疼的就是写文档。老板说要 BRD,产品经理要 MRD,开发要 PRD,我整个人都是懵的——这三兄弟到底有啥区别?

后来踩了不少坑才明白:BRD 是给老板看的,MRD 是给市场看的,PRD 是给我们自己看的。说白了,就是同一个需求在不同阶段的不同表达方式。

4.1 三份文档的核心定位

文档类型 英文全称 目标读者 核心问题 输出物
BRD Business Requirements Document 决策层、投资人 为什么要做?值不值得做? 商业价值、ROI、市场机会
MRD Market Requirements Document 市场、运营、产品 市场需要什么?竞争对手如何? 用户画像、竞品分析、市场策略
PRD Product Requirements Document 开发、测试、设计 具体怎么做?做成什么样? 功能列表、交互原型、验收标准

我的经验:很多团队跳过 MRD 直接写 PRD,结果开发到一半发现市场根本不买账。我个人习惯是:BRD 定方向,MRD 定策略,PRD 定细节,三步缺一不可。

4.2 三者的联系与流转

它们不是孤立的,而是一条需求传递链。我画了张图帮你理解:

需求文档流转关系图 BRD 商业需求文档 MRD 市场需求文档 PRD 产品需求文档 战略→策略 策略→执行 反馈与迭代 关键要点 • BRD 回答“为什么做”,MRD 回答“做什么”,PRD 回答“怎么做” • 三者层层递进,上一份文档的输出是下一份文档的输入 • 实际项目中可以合并,但核心逻辑不能丢

避坑指南:我曾经见过一个团队,老板拍脑袋说要做个“智能客服”,产品经理直接写 PRD 让开发做。结果做了三个月,发现市场上已经有免费方案了。这就是跳过了 BRD 和 MRD 的代价。

4.3 需求文档的标准模板

模板这东西,不同公司有不同风格。但我总结了一套通用模板,你拿去改改就能用。

BRD 模板(1-2 页)

# BRD:商业需求文档

## 1. 项目背景
- 当前业务痛点是什么?
- 市场机会有多大?

## 2. 商业目标
- 核心指标:营收增长?用户增长?效率提升?
- 预期 ROI:投入多少,产出多少?

## 3. 可行性分析
- 技术可行性
- 资源可行性
- 风险与应对

## 4. 建议方案
- 方案 A(推荐)
- 方案 B(备选)

## 5. 时间规划
- 里程碑节点
- 关键交付物

MRD 模板(3-5 页)

# MRD:市场需求文档

## 1. 目标市场
- 市场规模与增长趋势
- 目标用户群体

## 2. 用户画像
- 典型用户场景
- 用户痛点分析

## 3. 竞品分析
- 直接竞品 vs 间接竞品
- 我们的差异化优势

## 4. 功能需求
- 核心功能列表
- 优先级排序

## 5. 市场策略
- 定价策略
- 推广渠道

PRD 模板(10-20 页)

# PRD:产品需求文档

## 1. 版本信息
- 版本号、修订历史、负责人

## 2. 功能概述
- 功能背景与目标
- 用户故事(User Story)

## 3. 功能详述
- 功能流程(正常流程 + 异常流程)
- 界面原型(含交互说明)
- 字段规则与校验逻辑

## 4. 非功能需求
- 性能要求(响应时间、并发量)
- 安全要求(权限、加密)
- 兼容性要求(浏览器、设备)

## 5. 验收标准
- 功能验收清单
- 测试用例要点

注意:PRD 不是一次性写完的。我习惯先写 80% 的确定性内容,留 20% 给开发过程中的迭代。你想想看,需求变更是常态,文档写太死反而容易翻车。

4.4 需求优先级排序

需求永远做不完,但资源永远有限。怎么排优先级?我常用的方法有四种。

方法一:Kano 模型

把需求分成三类:

  • 基本型需求:没有会死(比如登录功能)
  • 期望型需求:有了更好(比如搜索建议)
  • 兴奋型需求:惊喜功能(比如个性化推荐)

我的经验是:先保基本型,再拼期望型,最后看兴奋型。别一上来就搞花活,基础功能都没做好,用户早跑了。

方法二:RICE 评分法

维度 含义 评分标准
Reach 影响范围 每周期影响多少用户
Impact 影响程度 对核心指标的提升(0.25/0.5/1/3)
Confidence 信心指数 对效果预估的把握(20%/50%/80%/100%)
Effort 开发成本 所需人天或人月

计算公式:RICE Score = (Reach × Impact × Confidence) / Effort

分数越高,优先级越高。这个方法我用了好几年,最大的好处是把主观判断变成了可量化的数字,跟老板汇报时特别有说服力。

方法三:MoSCoW 法则

  • M - Must have:必须有,否则项目失败
  • S - Should have:应该有,但可以延后
  • C - Could have:可以有,锦上添花
  • W - Won't have:这次不做,以后再说

我的习惯:每次排期前,我会拉上开发、测试、产品一起过一遍 MoSCoW 分类。你想想看,开发觉得是 Must 的,产品可能觉得是 Could,这种分歧越早暴露越好。

方法四:价值 vs 成本矩阵

画一个四象限图:

价值 vs 成本优先级矩阵 成本(低 → 高) 价值(低 → 高) 高价值低成本 立即做 高价值高成本 规划做 低价值低成本 有空再做 低价值高成本 坚决不做

把每个需求放到对应的象限里,优先级一目了然。我个人最喜欢这个方法,因为它直观、好沟通,开会时在白板上画一画,大家就都懂了。

4.5 总结:文档与优先级的关系

最后说一句:文档是载体,优先级是决策。BRD、MRD、PRD 帮你把需求说清楚,优先级排序帮你把资源用对地方。两者结合,才能做出靠谱的产品。

我的建议:别把写文档当成负担。你想想看,一份好的 PRD 能让开发少走多少弯路?一次好的优先级排序能让团队少加多少班?这些投入,都是值得的。