软件项目开发全流程 · 第 4 课 · 目标与范围：把"想要"变成"可交付"

1、范围是项目的"承诺书"，也是最容易失控的地方

项目章程里那句"范围"，其实是一份承诺：我保证做完这些，别的先不承诺。

范围失控有个形象的名字——范围蔓延（Scope Creep）：今天加个按钮，明天加个报表，后天"顺便"再改个流程……每一项单看都"不大"，合起来却能把项目拖垮。

它的可怕之处在于每一次都打着"顺便"的旗号，而"顺便"永远不会出现在排期里。所以本课的核心，就是学会三件事：

把模糊的"想要"拆成清晰的可交付物
用 WBS 把交付物分解到可估算、可分配
用变更控制守住边界，让"加需求"变成一件需要代价的正经事

2、目标要 SMART，否则没法验收

先说目标。很多人写目标是这样的：

❌ "提升系统性能。" —— 多快算快？怎么验证？
❌ "做个好用的后台。" —— 谁用？好用标准是什么？

换成 SMART 原则：

Specific 具体：做什么，清清楚楚
Measurable 可衡量：有指标、有数字
Achievable 可实现：能力/资源够
Relevant 相关：服务于真正的业务目标
Time-bound 有时限：什么时候完成

例：✅ "在 6 月 30 日前，把订单查询接口 P95 响应时间从 800ms 降到 200ms 以内。" —— 具体、可测、有时限。

目标定得越清楚，后面验收争议越少。 记住：无法验收的目标，等于没定目标。

3、从"想要"到"可交付物"

"想要"是愿望，"可交付物（Deliverable）"是能被验收的产物。差别在于：

"想要"（愿望）	"可交付物"（能验收）
用户能管理自己的订单	订单列表页：支持查看/筛选/取消，含 3 个接口与对应测试
系统更安全	全站强制 HTTPS + 依赖漏洞扫描接入 CI + 安全测试报告
页面好看点	交付高保真设计稿与 4 个核心页面的前端实现

把愿望翻译成交付物的过程，就是不断问："做完之后，我拿什么给谁看，他凭什么说'这算做完了'？"

4、WBS：把大石头砸成小石子

WBS（Work Breakdown Structure，工作分解结构） 是把项目逐层分解成更小、更可管理的工作包的方法。

原则：

以交付物为导向：先按"产出什么"分解，而不是按"谁做/怎么做"。
逐层细化：顶层是项目 → 中间是模块/阶段 → 底层是能用 1~3 天完成、可分配给一个人的工作包。
100% 原则：子项加起来必须覆盖父项的全部工作，不多不少。
分解到"能估算"为止：再拆下去没有信息增量就停。

举例（购物车项目）：

购物车系统
├── 1. 需求与设计
│   ├── 1.1 需求梳理
│   └── 1.2 原型与页面设计
├── 2. 后端
│   ├── 2.1 购物车增删改接口
│   ├── 2.2 价格与库存校验
│   └── 2.3 下单接口
├── 3. 前端
│   ├── 3.1 购物车页面
│   └── 3.2 结算流程页
└── 4. 测试与上线
    ├── 4.1 接口与页面测试
    └── 4.2 部署与发布

WBS 的好处：大的吓人的项目，变成一列能排期、能认领、能勾掉的小任务。 它也是第 5 课"估算"和第 17 课"看板"的直接输入。

工具提示：WBS 不等于甘特图。WBS 只管"有哪些活"，甘特图管"这些活排到哪天、谁来做、依赖谁"。先有 WBS，才有靠谱的排期。

5、优先级：范围不可能全要，那就排序

现实里资源永远不够，所以范围必须排序。最常用的两个方法：

MoSCoW 法：

级别	含义	说明
Must have	必须做	不做就没法上线/没法交付价值
Should have	应该做	重要但可临时用替代方案
Could have	可以做	有余力才做，砍掉不痛
Won't have	本次不做	明确排除，写下来防止反复讨论

Kano 模型（按用户满意度分）：

基本型需求：没有会骂，有了不夸（如"能登录"）
期望型需求：越好越满意（如"加载越快越好"）
兴奋型需求：没有无所谓，有了惊喜（如"自动识别收货地址"）

排优先级时最容易犯的错，是把"兴奋型"当成"必须型"。记住：先保基本型，再堆期望型，有余力才做兴奋型。

6、防蔓延：变更要走流程，不是喊一声

范围一定会变，这不丢人。丢人的是"变了却没人知道、没人记录、没人评估代价"。变更控制（Change Control） 就是给变化一个通道：

有人提变更
   ↓
记录（写清：要改什么、为什么、什么时候要）
   ↓
评估影响（工作量 / 排期 / 成本 / 风险 / 质量）
   ↓
决策（接受 / 拒绝 / 延后 / 用其它需求换）
   ↓
若接受 → 更新范围、排期、章程基线

关键在"换"而不是"加"。资源就那么多，加一个需求，就得问："那我们从范围里砍掉什么？或者推迟什么？" 这个问题一问，很多"随便加一下"的需求就自动消失了。

一句话口诀：没有免费的变更，只有被挪用的排期。

7、范围基线：留一个"说好的版本"

范围确认后，要冻结成一个基线（Baseline）：这是团队和干系人"说好的版本"。之后所有变更都相对基线来谈。

基线不是"永远不能改"，而是"改可以，但要走流程、要留痕、要重估"。它给了项目一个稳定的参照系——没有基线，就没有"延期"这个概念，因为从来没人知道原计划是什么。

8、动手实验 🎯

任务：为你自己的项目做一份"范围说明 + WBS + 优先级"。

用 SMART 原则，把你的项目目标重写成一句可验收的话（含数字和时间）。
写一份范围说明：
- In Scope（3~6 项可交付物）
- Out of Scope（至少 3 项，明确"这次不做"）
为项目做一版 WBS，分解到工作包层级（每条 ≤ 3 天能完成）。
用 MoSCoW 给所有工作包标级，并回答：如果时间砍掉一半，你砍哪些？
假设现在有人要插一个需求进来，用第 6 节流程写一遍：记录→评估→决策，并说明"要用什么换"。

做完你会发现："砍掉一半"时，你真正舍不得的其实只有那几件事——那才是项目的核心。

9、今天你带走的三句话

目标要 SMART，可验收的目标才是真目标；愿望不算范围，可交付物才算。
WBS 把大石头砸成小石子：分到"1~3 天、能派给一个人"为止。
没有免费的变更——加需求，就得说清"用什么换"。

下一课，我们给这些工作包排上时间和人：估算怎么做才靠谱？里程碑怎么设？排期为什么总是"看起来能行，做起来必延期"？