第二章：需求分析实战——从用户故事到功能列表，如何挖掘真正的需求？需求优先级排序方法
大家好，我是你们的老朋友。
上一章我们聊了项目启动，今天进入最磨人的环节——需求分析。说实话，我见过太多项目死在这一步。不是技术不行，而是从一开始就搞错了要做什么。
你想想看，客户说“我要一个商城”，你吭哧吭哧做了三个月，结果他说“我要的是能直播带货的商城”。嗯，这就尴尬了。
2.1 用户故事：别让客户写需求文档
很多团队喜欢让客户写需求文档。我个人习惯是——千万别这么干。客户写出来的东西，要么太抽象，要么太具体到实现细节。
举个例子，客户说：“我要一个登录功能，用手机号验证码登录。”
这看起来很清楚对吧？但实际做的时候你会发现，他其实想要的是：
- 新用户首次登录自动注册
- 验证码60秒内有效
- 登录后跳转到上次浏览的页面
这些细节，客户不会写进文档里。所以，我建议用用户故事来替代需求文档。
用户故事的标准格式：
作为【角色】，我想要【功能】，以便【价值】
比如：
- 作为普通用户，我想要用手机号快速登录，以便不用记密码
- 作为运营人员，我想要查看用户登录日志，以便分析用户活跃度
我在项目中遇到过最典型的案例：客户说“我要一个审批流程”。我们按用户故事拆解后发现，他其实要的是“不同金额走不同审批人”。如果直接做通用审批流，那工作量至少翻三倍。
2.2 从用户故事到功能列表：三步法
有了用户故事，怎么变成功能列表？我总结了一个三步法，用了好几年，挺管用的。
第一步：提取动词+名词
把每个用户故事里的动作和对象拎出来。
| 用户故事 | 动词 | 名词 |
|---|---|---|
| 用户想要用手机号登录 | 登录 | 手机号、验证码 |
| 运营想要查看登录日志 | 查看 | 登录日志、时间范围 |
| 管理员想要禁用异常账号 | 禁用 | 账号、状态 |
第二步：补充边界条件
这一步最容易漏。我习惯问自己三个问题：
- 正常流程是什么？
- 异常情况怎么处理？
- 有没有权限限制？
比如“登录”这个功能：
- 正常：输入手机号→获取验证码→输入验证码→登录成功
- 异常：验证码错误→提示重新输入；手机号格式不对→提示格式错误
- 权限：所有用户都可以登录，但管理员登录后有额外菜单
第三步：合并去重，形成功能列表
把重复的功能合并，把相关的功能归类。比如“登录”和“注册”可以合并成一个“账号管理”模块。
小技巧：功能列表不要写得太细。我一般控制在每个功能点不超过20个字。比如“用户登录”而不是“用户通过手机号验证码进行登录操作”。
2.3 挖掘真正的需求：5Why法
客户说的需求，往往不是真正的需求。怎么挖？我推荐5Why法——连续问五个为什么。
举个例子：
- 客户说：“我要一个报表导出功能。”
- 问：为什么需要导出？——因为要给老板看。
- 问：为什么老板要看？——因为要分析销售数据。
- 问：为什么分析销售数据？——因为要调整下个月的促销策略。
- 问：为什么调整策略？——因为这个月销量下降了。
- 问：为什么销量下降？——因为竞争对手降价了。
你看，真正的需求不是“报表导出”，而是“了解竞争对手动态，调整定价策略”。
我曾经遇到一个客户，非要做一个“实时数据大屏”。我连问五个为什么之后发现，他其实只是想在周会上展示数据。最后我们做了一个定时刷新的看板，成本只有原来的十分之一。
注意：5Why法不是真的只问五次。问到你觉得找到了根本原因为止。有时候三次就够了，有时候要问七次。
2.4 需求优先级排序：别什么都想做
功能列表出来了，但资源有限，先做哪个？我见过最蠢的做法是——客户说哪个重要就做哪个。结果做到一半，客户又说另一个更重要。
我常用的方法是MoSCoW法：
| 优先级 | 含义 | 例子 |
|---|---|---|
| Must have | 必须有，没有就不能上线 | 用户登录、商品展示 |
| Should have | 应该有，但可以延迟 | 搜索功能、评论功能 |
| Could have | 可以有，但不影响核心 | 个性化推荐、暗黑模式 |
| Won't have | 这次不做，以后再说 | 多语言支持、AI客服 |
怎么用？我一般这样操作：
- 把所有功能点列出来
- 和客户一起，每个功能点打上M/S/C/W
- M类功能必须全部完成才能上线
- S类功能至少完成80%
- C类功能看时间，能做就做
- W类功能直接砍掉，别犹豫
嗯，这里要注意：客户可能会把所有功能都标成M。这时候你要跟他算账——每个M功能需要多少开发时间，总时间是多少，上线日期是什么时候。让他自己权衡。
2.5 避坑指南：我踩过的三个坑
做需求分析这么多年，我踩过的坑不少。分享三个最典型的：
坑一：过度承诺
我曾经为了拿项目，答应客户所有需求。结果开发团队加班三个月，还是没做完。最后客户不满意，团队也累垮了。
教训：宁可少做，也要做好。把W类功能明确告诉客户“这次不做”，比做到一半说“做不了”要好得多。
坑二：忽略非功能需求
有一次我们做了一个电商系统，功能全做完了，上线第一天就崩溃了——因为没考虑并发量。客户说“我要能支持1000人同时访问”，我们以为就是功能需求，结果性能测试没做。
教训：功能列表里一定要包含非功能需求：性能、安全、可扩展性、可维护性。
坑三：需求变更不管理
有个项目做到一半，客户说“加个支付功能吧”。我们觉得简单，就加了。结果支付涉及第三方对接、财务对账、退款流程……最后项目延期两个月。
教训：任何需求变更都要走正式流程。评估影响、调整排期、重新确认优先级。别口头答应。
2.6 实战案例：一个完整的例子
最后，我拿一个真实案例串一下整个过程。
背景：某教育机构要做在线考试系统。
客户原话：“我要一个能在线考试的网站，学生可以在上面做题，老师可以批改。”
第一步：写用户故事
- 作为学生，我想要在线答题并提交，以便随时随地进行考试
- 作为老师，我想要创建试卷并批改，以便减少纸质工作
- 作为管理员，我想要查看考试统计数据，以便分析教学效果
第二步：5Why挖掘
问老师：为什么需要在线批改？——因为试卷太多，批改累。
问：为什么累？——因为要一题一题看。
问：能不能自动批改？——选择题可以，主观题不行。
问：主观题能不能只批改关键词？——可以试试。
你看，真正的需求是“自动批改选择题+主观题关键词匹配”，而不是“老师手动批改”。
第三步：功能列表
| 模块 | 功能点 | 优先级 |
|---|---|---|
| 考试管理 | 创建试卷（选择题+主观题） | M |
| 考试管理 | 发布考试 | M |
| 学生端 | 在线答题 | M |
| 学生端 | 提交试卷 | M |
| 批改系统 | 自动批改选择题 | M |
| 批改系统 | 主观题关键词匹配 | S |
| 批改系统 | 老师手动批改主观题 | S |
| 统计报表 | 考试成绩分布 | C |
| 统计报表 | 学生答题详情 | C |
| 其他 | 多语言支持 | W |
第四步：排期
第一期（1个月）：完成所有M功能，保证能考试、能批改选择题。
第二期（2周）：完成S功能，主观题关键词匹配+手动批改。
第三期（看情况）：C功能，统计报表。
W功能：直接砍掉，跟客户说“以后版本再做”。
好了，这就是需求分析的全流程。说白了，就是别信客户说的，要挖他真正要的；别什么都做，要排好优先级。
下一章我们聊聊架构设计，到时候见。