02 - 立项与 Roadmap：想法 → 可执行计划

Roadmap = 团队对业务的"承诺"——但好的承诺是"留 30% 缓冲 + 季度评审 + 利益相关者共识"的产物，不是"老板拍脑袋"的清单。

一句话

立项回答"做不做"，Roadmap 回答"什么时候做什么"——前者决定资源投入，后者决定季度节奏。两者共同决定团队"输出"的可预测性。

立项的 3 件事

任何项目立项前必须答 3 件事——少一件就开干，等于"先射箭再画靶"。

第 1 件：业务问题（为什么做）

模板（一页纸）：

【项目名】
[代号或功能名]

【业务问题】
[一个具体的痛点，用用户的语言而不是技术语言]

【为什么现在做】
- [市场/竞争压力]
- [内部能力积累]
- [客户明确要求]

【不做会怎样】
- [不做的代价 —— 失去 X / 错过 Y]

【衡量成功】
- [可量化指标 1：转化率提升 X%]
- [可量化指标 2：错误率降低到 Y%]
- [可量化指标 3：覆盖率达到 Z 客户]

反模式：

❌ "做一个更牛的支付系统"（没有业务问题）
✅ "用户结账时流失率 35%，主要因为要填 8 个字段"

第 2 件：利益相关者（为谁做 / 谁关心）

必答 4 个问题：

决策者——谁能拍板做不做？（产品总监 / CEO / 客户）
受益者——用这个功能的人是谁？（具体画像）
影响者——谁的工作方式会变？（客服 / 运营 / 销售）
反对者——谁会因此失去什么？（老员工 / 旧流程负责人）

为什么要找"反对者"：被忽视的反对者会变成项目最大的阻力——早点解决胜于事后妥协。

模板：

【利益相关者地图】

| 角色 | 姓名 | 立场 | 沟通频率 | 关键顾虑 |
|---|---|---|---|---|
| 决策者 | 张总 | 强支持 | 周会 | ROI |
| 受益者 | 一线销售 | 观望 | 培训 | 会不会更难用 |
| 影响者 | 客服 | 反对 | 见面 | 培训压力 |
| 反对者 | 流程主管 | 中立 | 月报 | 是否影响 KPI |

第 3 件：项目边界（不做什么）

核心技巧：明确写出"不做什么"——比"做什么"更难，但防止范围蔓延。

反面案例：

"做一个支付系统" → 没说什么不支付 → 半年后做了一卡通、Apple Pay、积分、储值卡……

好案例：

【本季度范围】
✅ 微信支付 + 支付宝
✅ 自动退款
✅ 支付失败重试

【本季度不做】
❌ Apple Pay
❌ 储值卡
❌ 支付分（信用支付）

立项前 7 个问题自检

回答全部为"是"才能开干：

问题	是	否
业务问题用用户语言写清楚了？	✅
利益相关者名单完整（含反对者）？	✅
成功标准是量化指标？	✅
"不做什么"已明确？	✅
资源预算（人 / 钱 / 时间）已确认？	✅
高层决策者已签字？	✅
与其他项目的依赖关系已梳理？	✅

3 个"否"就该停下重新对齐——不是"项目不重要"，是"现在开干风险太高"。

Roadmap 的 4 层结构

不是"按时间排序的需求列表"——那是 Backlog，不是 Roadmap。

真正的 Roadmap 回答"未来 12 个月我们要走向哪里"：

┌────────────────────────────────────────────────┐
│  愿景（Vision）                                  │
│  [1 句话：我们 3 年后要成为什么]                    │
└────────────────────────────────────────────────┘
           ↓
┌────────────────────────────────────────────────┐
│  年度目标（Annual Goals / OKR）                  │
│  [3-5 个可量化目标]                              │
└────────────────────────────────────────────────┘
           ↓
┌────────────────────────────────────────────────┐
│  季度主题（Quarterly Themes）                    │
│  [本季度专注的 2-3 个方向]                        │
└────────────────────────────────────────────────┘
           ↓
┌────────────────────────────────────────────────┐
│  季度里程碑（Milestones）                        │
│  [本季度 5-8 个具体可交付物]                      │
└────────────────────────────────────────────────┘

第 1 层：愿景（1 句话）

示例：

❌ "做最好的电商系统"
✅ "让小镇上的小商家能用上和城市大商家一样先进的零售工具"

判断：愿景能否 3 年后还能用？能的话是对的。

第 2 层：年度目标（OKR 风格）

格式（每个目标配 3 个关键结果）：

O1: 让订单履约效率提升 50%
   KR1: 平均配送时长从 60 分钟降到 30 分钟
   KR2: 履约成本下降 30%
   KR3: 履约异常率从 5% 降到 1%

O2: 新用户获取成本降低 40%
   KR1: CAC 从 ¥80 降到 ¥50
   KR2: 注册转化率从 25% 提升到 40%
   KR3: 新用户 7 日留存从 30% 提升到 45%

第 3 层：季度主题

示例：

2026 Q3 主题：
- 建立可扩展的订单履约基础设施（铺垫 Q4 大促）
- 提升新用户首单转化
- 完成支付通道整合

原则：主题 = 战略方向，不是"要做的功能"。

第 4 层：季度里程碑

格式：

| 里程碑 | 负责人 | 验收标准 | 截止日 |
|---|---|---|---|
| 订单系统重构上线 | 张三 | 平均履约 < 30 分钟，错误率 < 1% | 9/30 |
| 新用户引导 5 步改 3 步 | 李四 | 注册转化 ≥ 40% | 9/15 |
| 微信支付 + 支付宝上线 | 王五 | 上线支付成功率 ≥ 95% | 9/20 |

Roadmap 实施 5 步法

季度内 5 步循环：

第 1 周：季度评审 + OKR 对齐
        ↓
第 1-2 周：需求分解 + 优先级排序
        ↓
第 2-9 周：执行（Sprint 循环）
        ↓
第 10 周：里程碑评审
        ↓
第 11-13 周：下季度规划 + 写新 Roadmap

Roadmap 的反模式（5 种）

1. Roadmap 是"按时间排序的需求列表"

症状：Roadmap 长这样：

- 5月：用户登录
- 6月：商品列表
- 7月：订单创建

问题：这只是 Backlog 时间化。没有战略方向，没有里程碑，没有"为什么先做这个"。

修复：回到 4 层结构——愿景 → 年度 → 季度主题 → 里程碑。

2. 排满 12 个月，没缓冲

症状：Roadmap 排满到 12 月——每周都有"必做"事项。

问题：一切都是"重要"，等于没有重要。30% 缓冲给"未预料的事"。

修复：用 60% 给计划 + 30% 给 bug + 10% 给新机会（60-30-10 法则）。

3. 季度评审走过场

症状：季度末开个会宣布"完成 80%"，没有"什么没完成 / 为什么 / 下季度怎么办"。

问题：学不到经验，明年同样问题再出现。

修复：用前面提到的 Retro 模板 + 关键问题：

完成/未完成比例
已完成项实际影响 vs 预期
未完成项的真实原因（不是借口）

4. Roadmap 写给老板看

症状：Roadmap 在 Notion 里很精致，但团队不知道本周/本月该做什么。

问题：Roadmap 没有驱动行动。

修复：Roadmap 必须有"周/月可执行切片"——每个里程碑分解到每周。

5. 季度中途不动 Roadmap

症状：Q3 已经过半，发现 Q3 目标过时了，但坚持继续走。

问题：错过调整窗口，浪费整个季度。

修复：每月 1 小时"Roadmap 健康检查"——只问"还合理吗"。

Roadmap 工具栈

小团队：

Notion / 飞书文档（主文档 + Roadmap 单页 + 里程碑仪表盘）
GitHub Projects（里程碑视图）
飞书日历（季度评审会议）

中大型团队：

Confluence（Roadmap 文档）
Jira（Epic 链到 Roadmap）
ProductBoard（专业 Roadmap 工具）
自建仪表盘（Grafana 嵌入业务指标）

关键模板

模板 1：立项书

markdown

# 项目立项书：[项目代号]

## 业务问题
[一段话，用户的语言]

## 衡量成功
- [ ] 指标 1：数值 + 时间 + 责任人
- [ ] 指标 2：...

## 利益相关者
| 角色 | 姓名 | 立场 |
|---|---|---|
| 决策者 | | |
| 受益者 | | |
| 影响者 | | |
| 反对者 | | |

## 本季度范围
✅ 包含：
❌ 不做：

## 资源预算
- 人力：X 人 × Y 周 = Z 人周
- 预算：¥___
- 时间：从 _ 到 _

## 关键风险
1. [风险描述 + 应对预案]
2. ...

## 决策签字
- 产品：___ 日期：___
- 技术：___ 日期：___
- 业务：___ 日期：___

模板 2：季度 Roadmap

markdown

# 2026 Q3 Roadmap

## 季度主题
- [方向 1]
- [方向 2]
- [方向 3]

## OKR
O1: ...
   KR1: ...
   KR2: ...

## 里程碑
| 里程碑 | 负责人 | 验收标准 | 截止日 |
|---|---|---|---|

## 资源分配（60-30-10）
- 计划内：60%
- Bug / 技术债：30%
- 新机会：10%

## 不做清单
- [明确不做的功能 1]
- [明确不做的功能 2]

进入下一章

立项与 Roadmap 完成后，下一步是：

03 需求打磨——Roadmap 里程碑分解为用户故事和验收标准

作者：基于 INCOSE C04 (Stakeholder Requirements) + SE@Google Ch7 (Productivity) 综合 最后更新：2026-06-28

02 - 立项与 Roadmap：想法 → 可执行计划 ​

一句话 ​

立项的 3 件事 ​

第 1 件：业务问题（为什么做） ​

第 2 件：利益相关者（为谁做 / 谁关心） ​

第 3 件：项目边界（不做什么） ​

立项前 7 个问题自检 ​

Roadmap 的 4 层结构 ​

第 1 层：愿景（1 句话） ​

第 2 层：年度目标（OKR 风格） ​

第 3 层：季度主题 ​

第 4 层：季度里程碑 ​

Roadmap 实施 5 步法 ​

Roadmap 的反模式（5 种） ​

1. Roadmap 是"按时间排序的需求列表" ​

2. 排满 12 个月，没缓冲 ​

3. 季度评审走过场 ​

4. Roadmap 写给老板看 ​

5. 季度中途不动 Roadmap ​

Roadmap 工具栈 ​

关键模板 ​

模板 1：立项书 ​

模板 2：季度 Roadmap ​

进入下一章 ​