02 · 需求拆解：从模糊需求到可执行任务
"给我做个看板"——这句话不是需求，是愿望。 需求拆解解决的就是这个落差：把一句模糊的话，变成目标清晰、边界明确、能排期、能验收的任务。这是前端转全栈后最容易忽略、也最值钱的一步。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 用"目标 → 用户 → 边界 → 拆解 → 估算 → 验收"六步，把模糊需求变成可执行、可验证的任务 |
| 核心内容 | 需求 vs 愿望、目标先行的三问、用户与场景、边界与反例、任务拆解的原子化、估算与验收标准 |
| 读完能回答 | 拿到一句模糊需求先问什么？怎么判断拆完了？怎么让验收不再扯皮？ |
| 相关板块 | H02 · 产品思维 ｜ F03 · 技术方案写作 ｜ IH · 软技能 |
一、先分清：这是需求，还是愿望
很多"需求"其实是愿望：它描述"想要的结果"，没描述"要解决什么问题、为谁、怎么算成功"。
| 愿望 | 拆解后的问题 | 可执行的需求 |
|---|---|---|
| "给我做个看板" | 看什么数据、给谁看、多久刷新、要不要告警？ | 运维仪表盘：展示 7 天 CPU/内存曲线，5 分钟刷新 |
| "接口要做鉴权" | 谁有权限、多细的权限、失效怎么办？ | 登录用户按角色访问，token 过期返回 401 并引导重登 |
| "接入 AI 客服" | 答什么范围、答错怎么办、多快响应？ | FAQ 场景内回答，命中率低于阈值转人工 |
判断标准：一条需求如果能被不同的人实现出完全不同的东西，它就不是需求，是愿望。拆解的第一步，是把它变成"谁都能做出同一件事"的表述。
二、目标先行：开工前先问三个问题
拿到需求先不要打开编辑器。先问三个问题，答案直接影响拆解方向：
- 解决谁的什么问题？（用户 + 场景）
- 怎么算成功？（可观测的指标，不是"看起来不错"）
- 不做会怎样？（判断优先级，砍掉伪需求）
前端转全栈的坑：只从"怎么实现"出发拆解（要不要用某个组件、某个库），而没从"解决什么问题"出发。实现是 F03/F04 的事，这里只关心问题和成功标准。
三、边界与反例：拆解的一半价值在"不做什么"
好的拆解不仅写"要做什么"，还写"明确不做什么"。没有边界，任务永远完不成：
| 维度 | 要问的边界问题 |
|---|---|
| 范围 | 第一版支持什么、明确砍掉什么？ |
| 用户 | 是内部用户还是外部用户？要不要兼容老版本？ |
| 数据 | 数据量级多大？没有数据时页面长什么样？ |
| 平台 | 只做移动端还是也要 Web？横屏/离线支持吗？ |
| 合规 | 有没有隐私、鉴权、审计要求？ |
给每个边界写一个反例（"这个版本明确不包含 XX"）。反例是防止范围蔓延最有效的武器：别人说"顺手加一下"，你能拿出白纸黑字说不。
四、拆成原子任务：每个任务都能独立验收
拆解的目标是原子任务：一个任务 = 一个改动 = 一次可验收的交付。判断原子性的三条标准：
- 单一职责：只做一件事（如"展示列表"和"支持筛选"是两个任务）
- 可验收：完成状态能被明确判断（"做得好看"不可验收，"首屏 2 秒内展示数据"可验收）
- 可独立上线：不依赖另一个未完成的任务（避免"等 XX 做完才能测"）
需求：给设备页加一个能耗趋势图表
拆解：
T1 后端：提供 7 天能耗聚合接口（含空数据返回约定）
T2 前端：接入接口并渲染趋势折线（缺省态、加载态、错误态）
T3 交互：时间范围切换 + 图表横屏展开（F02 拆解 → 各域实现）
T4 验收：切 7 天/30 天数据正确，无数据时显示空态前端转全栈的好处：你能同时拆前后端，把契约（接口字段、错误码、空数据约定）作为任务之一写进去，避免联调时互相等。
五、估算：让"大概"变成可排期
估算不是承诺精确时间，而是给不确定度分级：
| 级别 | 含义 | 策略 |
|---|---|---|
| 0.5~1 天 | 做过类似的事，风险低 | 直接排期 |
| 2~3 天 | 有未知点，但可查 | 先做技术验证（spike）再排期 |
| 1~2 周 | 涉及新领域/新集成 | 拆得更细，或先出最小可行版 |
| 2 周以上 | 大项目 | 必须拆成里程碑 + 每阶段可交付 |
估算的秘诀：把"未知的部分"单独列出来估，而不是拍一个总数字。未知越明确，估算越准。
六、验收标准：写进任务，而不是口头约定
验收标准必须在拆解时写下来，且可观测：
| 好 | 差 |
|---|---|
| 接口在 500ms 内返回，超时返回 504 | "接口要快" |
| 无数据时显示空态引导，不白屏 | "页面要友好" |
| 鉴权失败跳登录页，并保留原地址回跳 | "要处理未登录" |
验收标准写进任务后，测试、评审、交接都有共同语言。这也是后面 F03 方案文档、各域测试文章的基础。
自检清单
- [ ] 能区分"愿望"和"需求"，并给出拆解后的可执行表述
- [ ] 开工前能回答"解决谁的问题 / 怎么算成功 / 不做会怎样"
- [ ] 能为任务写出明确的"不做什么"反例
- [ ] 每个任务满足"单一职责 + 可验收 + 可独立上线"
- [ ] 能为含未知点的任务先排技术验证（spike）再排期
- [ ] 每个任务都带可观测的验收标准
常见误区
| 误区 | 事实 |
|---|---|
| "需求很清楚了，直接写代码" | 清楚是假象，拆解是为了逼出没想清楚的部分 |
| "拆解 = 把大需求切成小块" | 切块只是最后一步，先要做目标、边界、验收 |
| "验收标准是产品的事" | 没有可观测验收标准，做完就无法判断"对不对" |
| "边界会限制灵活性" | 明确的"不做"反而保护了核心目标，灵活是对需求的，不是对范围的 |
动手练习
练习 A：拆一个真实需求
拿最近一个需求，按六步拆成原子任务；每个任务标注验收标准。检查有没有任务无法独立验收。
练习 B：写反例
给上一步的任务各写一条"明确不做什么"。试着让产品经理加一条范围外需求，用反例回应。
练习 C：估算复盘
回顾上一个已完成的迭代，把每个任务的估算与实际耗时对比，找出"未知点"估错的地方，总结下次怎么估得更准。
相关文档
本区
- 01 · 工程方法论全景 —— 闭环地图
- 03 · 技术方案写作 —— 拆解完进入方案阶段
其他域
- H02 · 产品思维 —— 目标、用户、指标的语境从哪来
- C00 · 后端学习全景 —— 拆全栈任务时补后端视角
- IH · 软技能与行为面试 —— 向上对齐、跨角色沟通的表达