第二章 需求分析实战：从用户故事到功能列表

需求分析这件事，说简单也简单，说复杂能让你掉一层皮。我见过太多项目，开发到一半才发现「咦，用户要的不是这个啊」。嗯，今天我们就来聊聊，怎么把一句「我想要个某某系统」变成一份靠谱的功能列表。

2.1 用户故事：别让用户写需求文档

你想想看，让业务方写需求文档是什么结果？要么是几百页没人看的 Word，要么是「跟某某系统一样就行」。这两种我都踩过坑。

我个人习惯用用户故事来破冰。用户故事不是需求文档，它只是一个沟通工具。标准格式就三句话：

作为 <角色>
我希望 <功能>
以便 <价值>

举个例子：

看出区别了吗？好的故事有具体角色、具体操作、具体价值。坏的故事说了等于没说。

2.2 从故事到功能列表：拆解的艺术

用户故事收集完了，下一步就是拆成功能列表。这一步很多新手会犯一个错误——把故事直接当功能。

一个用户故事往往对应多个功能点。比如「扫码自动填充入库单」，拆开来看：

1. 扫码枪接入功能
2. 条码解析与校验
3. 自动匹配商品信息
4. 入库单模板填充
5. 异常条码处理（扫不出来怎么办）

你看，一个故事拆出 5 个功能点。我曾经在一个项目中，20 个用户故事拆出了 120 多个功能点。不拆细一点，开发排期就是一笔糊涂账。

功能列表的格式我建议这样：

功能编号	功能名称	关联故事	优先级	预估工时
F-001	扫码枪接入	US-003	P0	2人天
F-002	条码解析与校验	US-003	P0	3人天
F-003	自动匹配商品信息	US-003	P0	4人天
F-004	入库单模板填充	US-003	P1	2人天
F-005	异常条码处理	US-003	P1	3人天

2.3 优先级排序：不是所有功能都值得做

功能列表出来了，但资源有限，先做哪个？我见过最蠢的做法是「按用户说的顺序做」。用户说的时候可没考虑技术依赖和业务价值。

我个人常用 MoSCoW 方法，简单粗暴：

• Must have（必须有）：没有这个功能，系统没法上线。比如登录、核心业务流程。
• Should have（应该有）：很重要，但可以等一等。比如报表导出。
• Could have（可以有）：锦上添花，有时间再做。比如深色模式。
• Won't have（这次不做）：明确告诉用户，这次版本不包含。

排序的时候，我建议你画一张四象限图：

把功能点往这四个象限里一放，优先级一目了然。左上角（高价值低难度）先做，右下角（低价值高难度）直接砍掉。

2.4 需求评审：别让评审变成走过场

需求评审是很多团队的痛点。要么没人说话，要么吵成一锅粥。我参加过不下 50 场需求评审，总结了几条铁律：

评审前：准备比会议重要

• 提前 2 天发功能列表和用户故事
• 要求参会者提前看，带着问题来
• 准备好原型或流程图（哪怕手画的也行）

评审中：控制节奏

• 先过整体流程，再扣细节
• 每个功能点确认：理解是否一致
• 争议点记录下来，不现场拍板
• 控制在 1 小时内，超时另约

评审后：输出比讨论重要

• 当天发出评审纪要
• 明确每个争议点的决策人和截止时间
• 更新功能列表状态（已确认 / 待确认 / 已驳回）

2.5 需求变更：拥抱变化，但要有代价

需求不变更的项目是不存在的。但变更不能是「你说改我就改」。我建议建立一套变更流程：

1. 提出变更申请（写清楚为什么变、变什么）
2. 评估影响范围（哪些功能要改、工时增加多少）
3. 评审是否接受（变更的价值 vs 代价）
4. 更新功能列表和排期

说白了，变更可以，但要让大家知道代价。我曾经在一个项目中，用户要求加一个「导出 Excel」的功能，看起来很简单。一评估才发现，涉及 5 个模块的数据整合，要加 3 天工时。用户听完自己就放弃了。