范围层 —— 定义做什么，更要定义不做什么

本课导读

战略层回答了"为什么"，范围层把它翻译成一张清单："这一版，我们具体做什么。"从这一层开始，图上劈出了两条支线：任务流这边产出功能规格（产品要提供哪些功能），信息流那边产出内容需要（产品要提供哪些内容）。本课三件事：需求从哪来、规格怎么写才不埋雷、以及范围层真正的必杀技——理直气壮地说"这个不做"。预计 35 分钟。

为什么需要"范围"这个动作

很多团队跳过范围层直接开干，理由是"需求都在我脑子里"。代价会在两个时刻爆发：

1. 开发中途："等等，那注册了但没付费的用户看到什么？"——没人想过。现场拍脑袋的补丁设计，就是产品里那些"莫名其妙的角落"的来源
2. 上线前夜："这功能谁说要做的？为什么做成这样？"——没有书面范围，就没有验收依据，扯皮代替复盘

把范围写下来的两个作用，Garrett 总结得很白：让你知道你在做什么，让你知道你不在做什么。第二条比第一条值钱——后面细说。

需求从哪来

需求有三个来源，可靠度递减，但都有用：

1. 用户调研里的问题（最可靠）：上一课挖到的"用户真实卡点"，天然就是需求。注意继续警惕"更快的马"——用户提的功能要翻译回问题再决定方案
2. 战略目标的推演：成功指标倒推。指标是"新手 5 分钟内完成首次体验"，那"跳过注册先试用"就是被推演出来的需求
3. 利益相关方的想法（最需要过滤）：老板的点子、销售答应客户的承诺、工程师觉得"顺手就能加"的功能。它们不是天然错，但必须过同一道安检：它推进哪个战略目标？说不出的进停车场，不上车

一个好用的组织工具是场景（scenario）：写一小段故事——"老张下班地铁上打开 App，想接着昨天的进度学 20 分钟"。顺着故事走一遍，需要什么功能、什么内容，自己会掉出来（断点续学、单课时长标注、离线可读……），而且掉出来的需求天然带着使用情境，不是真空里的功能名词。

功能规格：三条写作纪律

规格不用写成百页大部头（那是重型流程的遗产），但每条要过三道纪律——都是为了消灭歧义：

• 正面写（说系统"做什么"，别只说"不做什么"）："系统在浏览器不支持视频时显示文字版讲义"，好于"系统不能在不支持视频的浏览器上崩溃"——后者没告诉任何人该做出什么
• 具体写（可检验）："热门课程置顶展示"是歧义窝——什么算热门？多久更新？改成："完成人数最多的 3 门课展示在首页第一屏，每日零点更新"
• 客观写（别用需要品味裁决的词）："界面要时尚"无法验收；"界面遵循平台现行设计规范 v2"可以

内容需要：被工具型思维忽略的那半边

信息流这边常被轻视，因为"内容不就是往里填字吗"——直到项目被它拖死。内容需要至少要定四件事：

• 有哪些内容：类型清单（课程正文？术语表？视频？FAQ？）与规模预估（42 课，每课约 1500 字）
• 谁来生产：内容不是免费的。每类内容标注负责人，没人认领的内容等于没有
• 多久更新：内容会腐烂。技术教程两年不更新就开始误人子弟——维护成本在收录时就要算
• 特征规格：功能有规格，内容也有——目标读者、语气、单篇长度、结构模板（本课程每课都有"导读—正文—练习—测验—小结"的模板，就是内容规格的产物）

排优先级："不做"是范围层的必杀技

需求收集完毕，永远比资源多。排序有个简单顺手的框架 MoSCoW：

档位	含义	判断标准
Must	没有它产品不成立	砍掉后价值主张还成立吗？不成立就是 Must
Should	重要但本版可绕过	有临时替代方案（人肉运营顶一阵）
Could	有了更好	资源有富余才做，第一批砍它
Won't	明确本版不做	写下来，防止它开发中途溜回来

两个实战要点：

1. Won't 清单必须成文。范围蔓延（scope creep）的经典路径就是"这个小功能顺手加一下呗"——每个"顺手"都在偷走 Must 的资源。书面 Won't 清单是挡箭牌："已评估，本版不做，记录在案。"
2. 裁决标准永远在楼下。某功能是 Must 还是 Could，不看谁嗓门大，看它对战略层成功指标的贡献。这也是为什么战略层要先行——没有它，优先级排序就是权力游戏。

✍️ 练习

练习 1：给病句规格做手术

下面三条规格各违反了哪条纪律？动手改写：

1. "搜索功能要快"
2. "系统不能让用户感到困惑"
3. "首页展示优质内容"

✅ 参考答案

1. 不具体（多快算快？）→ "搜索结果在 1 秒内返回首屏；超时显示进度提示"
2. 负面写法（没说要做什么）→ "每个多步流程顶部显示步骤进度条，标明当前第几步、共几步"
3. 不具体 + 不客观（谁定义优质？）→ "首页第一屏展示近 7 日完成率最高的 3 门课，每日零点更新"

共同病根：歧义。每处歧义都是未来某次返工或扯皮的定时炸弹。

练习 2：MoSCoW 实战

假设你在做 LearnPath 的下一版，手头有六个候选需求：① 课程内容再加 42 课；② 学习页夜间模式；③ AI 答疑机器人；④ 微信登录；⑤ 排行榜和积分系统；⑥ 笔记导出。已知战略：单人转行操作系统，成功指标是每周学习时长稳定 + 内容领先进度 2-4 周。给六项排 MoSCoW 并写一句理由。

✅ 参考答案

• ① Must——内容领先原则写进了守则，内容任务优先级高于功能任务
• ⑥ Must/Should——数据逃生舱是既定约定（用户数据必须可导出），若已有基础版则新数据同步扩展即可
• ② Should——晚间学习是核心场景，但系统级深色模式可临时顶替
• ③ Could——运行守则"土办法先行"：先在对话里人肉跑两周验证，好用再产品化
• ④ Could/Won't——单人 + 少量内测用户，邮箱登录足够，做它不推进任何当前指标
• ⑤ Won't（成文）——游戏化对"每周学习时长"的拉动在单人场景不成立，且它是典型的"顺手加一下"型蔓延源

你的答案不必和参考一致——关键看每条理由是否引用了战略层，而不是"我觉得这个功能酷"。

📝 随堂测验

随堂测验0 / 5 题正确

1. 范围层在任务流和信息流两条支线上的产出分别是？

A交互设计和信息架构B功能规格（做哪些功能）和内容需要（提供哪些内容）C界面设计和导航设计D产品目标和用户需求

2. “系统不能在不支持视频的浏览器上崩溃”这条规格的毛病是？

A太具体了B负面写法——只说了不要什么，没告诉团队该做出什么（应写：不支持视频时显示文字版讲义）C太技术化D没有毛病

3. 关于内容需要，下面哪个认识是对的？

A内容往里填就行，不用规划B每类内容要定：类型规模、生产负责人、更新频率——内容会腐烂，维护成本在收录时就要算C内容是一次性工作，上线就结束D内容规划是编辑的事，与产品设计无关

4. MoSCoW 里把“Won't（本版不做）”写成书面清单的目的是？

A证明团队考虑周全B防范围蔓延——每个“顺手加一下”都在偷 Must 的资源，成文清单是挡箭牌C给老板看的形式主义D以后永远不做这些功能

5. 两个功能争 Must 名额争不下来，正确的裁决依据是？

A哪个技术上更炫B哪个对战略层写下的成功指标贡献更大——楼下当裁判C哪个是老板提的D抛硬币

本课小结

• 范围层 = 把战略翻译成书面清单：功能规格（任务流）+ 内容需要（信息流）
• 需求三来源：用户问题（最可靠）、战略推演、相关方想法（必须过"推进哪个目标"的安检）
• 规格三纪律：正面写、具体写、客观写——歧义只会推迟到最贵的时刻爆炸
• 内容四件事：有什么、谁生产、多久更新、什么规格——内容会腐烂，维护成本收录时就要算
• MoSCoW 排序，Won't 清单成文防蔓延；一切争议回战略层找裁判

下一课登上结构层：需求清单有了，怎么把它们组织成用户走得通的流程（交互设计）和找得到的分类（信息架构）。