第二章：需求分析实战
好，咱们直接进入正题。
需求分析这件事，说白了就是搞清楚「到底要做什么」。我见过太多项目，开发到一半才发现需求理解错了，那叫一个痛苦。今天我就把这三块核心内容掰开揉碎讲给你听。
2.1 如何读懂需求文档
拿到一份需求文档，别急着往下翻。我个人的习惯是，先看三样东西：项目背景、用户角色、核心目标。这三样没搞明白，后面的细节看了也白看。
举个例子。有一次我接手一个电商后台的需求文档，文档写得密密麻麻。我扫了一眼背景——「提升运营人员处理退款效率」。嗯，目标明确了。再看用户角色——「运营专员」和「运营主管」。好，那我知道该关注什么了。
读需求文档时，我建议你带着这几个问题去读：
- 谁在用？——用户是谁，他们有什么痛点
- 用来干嘛？——核心功能是什么，解决什么问题
- 做到什么程度？——验收标准是什么，怎么算「做完」
- 有什么限制？——时间、预算、技术约束
2.2 用户故事编写
用户故事这东西，很多人觉得不就是「作为XX，想要XX，以便XX」嘛。其实没那么简单。
我写过几百个用户故事，踩过不少坑。最典型的就是把用户故事写成了功能清单。你想想看，如果写成「用户可以看到订单列表」，那跟写个需求条目有什么区别？
好的用户故事长这样：
作为：运营专员
想要：在退款页面看到每个订单的处理时长
以便：优先处理超时订单，提升客户满意度看到了吗？关键在最后那个「以便」。它说明了业务价值。没有价值描述的用户故事，开发出来可能就是废的。
写用户故事时，我习惯用 INVEST 原则来检查：
| 原则 | 含义 | 我的经验 |
|---|---|---|
| I - Independent | 独立的 | 别把两个功能绑在一起，否则排期会很难受 |
| N - Negotiable | 可协商的 | 别写太死，给技术留点发挥空间 |
| V - Valuable | 有价值的 | 每个故事都要能说清楚「对谁有用」 |
| E - Estimable | 可估算的 | 如果估不出工作量，说明故事太大了 |
| S - Small | 小的 | 一个故事最好2-3天能做完 |
| T - Testable | 可测试的 | 没有验收标准的故事，就是耍流氓 |
2.3 需求优先级排序（MoSCoW法）
需求永远做不完，这是铁律。所以排序就特别重要。
MoSCoW 法是我最常用的方法。它把需求分成四类：
- M - Must have（必须有）：没有这个功能，产品没法上线。比如支付系统的「付款功能」。
- S - Should have（应该有）：很重要，但可以等一等。比如「订单导出」功能，没有也能用，但运营会骂人。
- C - Could have（可以有）：锦上添花的东西。比如「深色模式」，有更好，没有也行。
- W - Won't have（这次不做）：明确告诉需求方，这期不搞。比如「多语言支持」，下个版本再说。
我一般会画个简单的图来跟产品经理对齐：
实际操作时，我有个习惯：先定 Must，再定 Won't。为什么？因为 Must 决定了底线，Won't 划清了边界。中间那些 Should 和 Could，反而可以灵活调整。
核心要点：
- 读需求文档：先看背景、角色、目标，再抠细节
- 写用户故事：记住「以便」才是灵魂，别写成功能清单
- 排优先级：MoSCoW 法帮你守住底线、划清边界
嗯，这三块内容看起来是独立的，其实是一条线。你读懂了需求文档，才能写出好的用户故事；有了用户故事，才能用 MoSCoW 法排优先级。一环扣一环，缺了哪步都容易翻车。
下一章咱们聊聊技术方案设计，到时候我会拿一个真实项目来拆解。今天就先到这儿，有什么问题随时问我。