一、"把结算页优化一下"——一个需求的诞生
第二天晨会，王姐在群里发的需求被正式提上日程。小陈兴冲冲地找到老周：
"师傅，王姐说了三个需求：结算页优化、满减活动、报表改版。我准备开干了！"
老周拦住他："先别急着写代码。你把'结算页优化'做给我看。"
"就……把页面变快啊。"
"多快算快？现在多慢？优化到什么程度算'完成'？影响哪些页面？是所有设备还是只有手机？预算多少时间？影响范围是结算页还是整个购物流程？"老周一口气问了八个问题。
小陈张了张嘴，答不上来。
"这就对了。"老周说，"王姐说的不是'需求'，是'想法'。需求管理的第一件事：把'想法'变成'可以验收的需求'。 不然我们做一个月，她看结果时只会说一句：'这不是我要的。'"
老周在白板上写下需求管理的第一棵树：
第一层：需求管理（做对的事）
├── 需求收集 ← 想法 → 记录
├── 用户故事 ← 记录 → 可讨论的卡片
├── 优先级 ← 一堆需求 → 先做什么
└── 验收标准 ← 卡片 → 可验收的承诺
二、用户故事：把需求写成"人话"
"先教你把'想法'变成'用户故事'。"老周说，"用户故事（User Story）是敏捷开发里最常用的需求格式，就三句话："
作为（谁） → 作为一位手机端顾客
我想要（什么） → 我希望结算页在弱网环境下也能在 3 秒内完成加载
以便（为什么） → 这样我就不用干等，减少放弃下单
验收标准（什么时候算做完）：
- 在 3G 网络模拟下，结算页首屏 ≤ 3 秒
- 加载期间显示进度提示，不白屏
- 图片懒加载，首屏只加载必要资源
"看到'验收标准'了吗？这是灵魂。"老周敲敲桌子，"没有验收标准的需求，就像没有答案的考试题——你写得再认真，也是零分。验收标准把'我以为做完了'变成'测过标准才算完'。 这直接呼应了上一章的 DoD（完成的定义）。"
小陈试着把王姐的"满减活动"改写成用户故事：
作为：书店运营
我想要：推出"满 99 减 20"的促销活动，且能自己配置规则
以便：不用每次找开发改代码，就能灵活做活动
验收标准：
- 运营可在后台配置"满 X 减 Y"，无需改代码
- 满减与会员折扣可叠加（规则：先会员价，后满减）
- 优惠金额分摊到订单明细，对账可查
- 活动时间区间内生效，过期自动失效
"好！但你别高兴太早。"老周泼了盆冷水，"需求写清楚了，只是第一步。真正要命的是下面这个——优先级。"
三、优先级：全都重要 = 全都不重要
"王姐一下子甩来三个需求，加上手头还没做完的，技术部 backlog（需求池）里躺着 17 个需求。"老周说，"17 个需求都'很急'。六个人，两周，只能做 6 个。你告诉我，做哪 6 个？"
小陈："……谁催得急做谁？"
"那是需求方催得急，不是业务优先级高。"老周教了他一个工具——MoSCoW 优先级分类法：
MoSCoW 优先级
M（Must have）必须有 —— 不做，业务就转不动（如：满减活动下周上线是 KPI）
S（Should have）应该有 —— 重要但不致命（如：结算页优化）
C（Could have）可以有 —— 锦上添花（如：报表格式美化）
W（Won't have）这次不做 —— 明确排除，下期再说（如：APP 独立版）
"规则：先把所有需求放进四个框，再按 M → S → C → W 的顺序排期。 关键是 W 框——敢把需求明确放进'这次不做'，比什么都重要。不然每个需求都'紧急'，团队就永远在救火。"
"优先级不是我们程序员自己定的，"老周强调，"是业务方和开发方一起开'需求评审会'定的。我们提供'工作量'和'技术风险'，王姐提供'业务价值'。两边一碰，才能排出真正的优先级。"
四、需求变更：需求管理的"终极 Boss"
需求管理课进行到第三天，王姐又来了：
"周哥！那个满减活动，我看隔壁书店在做'满 100 减 30，会员再打 9 折'，咱们也照这个改！"
小陈差点没站稳："我们才刚按'满 99 减 20'开发了一半……"
老周却很淡定，他早就等着这一天了："需求变更，不是意外，是常态。 需求管理不是'冻结需求'，而是'管理变化'。我们有三个招："
4.1 招一：变更要"过流程"，不能口头一句话
需求变更流程：
1. 需求方提出变更（书面记录：改什么、为什么、多急）
2. 开发评估影响（工作量增加？上线时间延后？）
3. 双方确认（变更带来的延期/范围调整，白纸黑字）
4. 更新用户故事与优先级，重新排期
"口头一句话就改，最后出了偏差，谁都说不清当初怎么说的。书面化 + 评估影响，让变更变得透明、可追溯。"
4.2 招二：小步交付，别憋大招
"为什么这次'开发了一半'才遇到变更？因为满减活动我们打算憋两周一次性上线。"老周说，"如果拆成小步——第一周先上线'后台可配置满减规则'（不含叠加），第二周再上'叠加会员折扣'——那王姐第三天说改，我们只浪费半天，而不是两周。"
"这就是敏捷的核心思想：小步快跑，频繁交付，让需求变更的代价最小化。"
4.3 招三：永远有一个"缓冲"
"排期的时候，永远留 20% 的缓冲时间，专门用来吸收'意外的需求变更'。"老周说，"没有缓冲的排期，是一次变更就崩盘的排期。"
五、章末：老周的第一层总结
第一层：需求管理（做对的事）
├── 需求收集 → 想法要落到纸面，不能口头传
├── 用户故事 → 作为谁/想要什么/以便什么 + 验收标准
├── 优先级 → MoSCoW：M必须 / S应该 / C可以 / W不做
└── 需求变更 → 过流程、小步交付、留缓冲
"小陈，记住这一章最大的教训：开发里 80% 的返工，不是代码写得差，是需求没对齐。 需求管理不是'麻烦的流程'，是'省时间的投资'。"
"那师傅，"小陈问，"需求对齐了，我们六个人终于可以各写各的代码了吧？"
"想得美。"老周笑了，"需求对齐只是说'做什么'对齐了。代码怎么写、怎么合到一起——上一章我提过，你们第一天就互相覆盖代码了。该上真正的硬工具了。"
"什么工具？"
"Git。版本控制。 下一章，我给你看什么叫'三份最终版'的惨案。"