roadmap-planning

路线图格式

选择符合受众和规划周期的格式。

Now / Next / Later

一种基于时间范围的方式，可避免对日期做出虚假的精确承诺：

• Now（当前冲刺或本月）：团队正在执行的工作。范围明确，交付把握较高。
• Next（未来一到三个月）：已确定优先级并大致规划范围。“做什么”很明确；“何时做”仍有些不确定。
• Later（未来三到六个月及更久）：战略意图和方向性押注。范围和时间安排仍有意保持灵活。

最适合：对外沟通、向领导层汇报，以及希望避免过早锁定具体日期的团队。

按季度制定主题计划

围绕两到三个投资主题来规划每个季度：

• 主题阐明战略重点领域（例如：“自助式入门引导”“企业安全态势”“开发者生态系统增长”）
• 各项计划归入相应主题之下
• 主题应对应公司或团队层面的目标与关键结果
• 这种格式突出每项计划背后的战略“原因”

最适合：高管评审、规划周期，以及展示执行与战略之间的一致性。

由 OKR 驱动的路线图

将每项路线图内容直接关联到目标和关键结果：

• 从团队在规划周期内的 OKR 开始
• 在每个关键结果下，列出预计能推动该指标的计划
• 标注每项计划预计对关键结果的贡献
• 由此在交付与衡量之间建立直接的问责链条

最适合：采用 OKR 流程，并希望在构建与衡量之间形成紧密反馈循环的组织。

甘特图／时间线视图

以日历为导向的布局，展示持续时间、并行情况和先后顺序：

• 显示每项计划的开始日期、结束日期和工作时长
• 揭示资源冲突和排期瓶颈
• 直观呈现各项内容之间的依赖关系
• 突出并行工作流的汇合点

最适合：工程协调和资源分配讨论。避免对外分享，因为精确到日历的安排会带来僵化的预期。

评分与优先级排序模型

RICE 评分

用四个维度量化优先级：评分 =（覆盖范围 x 影响 x 信心）/ 工作量

• 覆盖范围：在指定时间段内受到影响的用户或客户数量。使用具体估算（“每季度 800 个账户”）。
• 影响：对每位覆盖对象产生的变化程度。等级：3 = 变革性，2 = 显著，1 = 中等，0.5 = 轻微，0.25 = 可忽略。
• 信心：对覆盖范围和影响估算的确信程度。100% = 有数据支持，80% = 有合理证据，50% = 有依据的估计。
• 工作量：所有职能（工程、设计、研究等）合计的人月数。

最适合：以量化方式严谨比较大量待办事项。对于影响本质上难以预测的大胆战略押注，效果较差。

ICE 评分

当缺少详细数据时，可采用更精简的替代方案。按三个维度分别为每项内容打 1 到 10 分：

• 影响：对目标指标的预期推动程度
• 信心：影响估算的可靠程度
• 易实施性：实施的简便程度（与工作量成反比；分数越高表示越简单）

评分 = 影响 x 信心 x 易实施性

最适合：快速筛选待办事项、早期阶段的产品，或无法获取 RICE 所需数据的情况。

MoSCoW 分类

将各项举措分为四类，以推动优先级讨论：

• 必须有：没有这些内容，计划就无法推进。它们代表不可妥协的承诺。
• 应该有：价值高且符合预期，但即使延期，计划仍然可行。
• 可以有：有余力时值得纳入。取消它们不会影响时间安排。
• 不会有：本周期有意排除的内容。将其列出可避免歧义。

最适用于：与需要了解取舍内容的利益相关方开展发布范围界定和协商会议。

价值与投入四象限

在一个 2×2 网格中直观呈现各项举措：

• 高价值、低投入（快速见效）：立即执行。这些事项的杠杆效应最高。
• 高价值、高投入（战略投资）：审慎投入资源。值得付出成本，但需要周密规划。
• 低价值、低投入（机会性补充）：在工作较少的时期或大型工作之间处理。
• 低价值、高投入（陷阱）：不予考虑。它们消耗资源，却几乎没有回报。

最适用于：需要团队在取舍上达成共识的协作式规划会议。

依赖管理

依赖分类

检查以下类别中的依赖：

• 技术依赖：举措 B 依赖举措 A 交付的基础设施或平台变更
• 跨团队依赖：工作需要设计、平台、数据工程或其他产品团队交付成果
• 外部依赖：受供应商交付成果、合作伙伴集成或第三方 API 阻碍
• 信息依赖：工作开始前需要研究探索、用户研究或数据分析的结果
• 顺序依赖：由于共用界面或用户流程的限制，功能 A 必须先于功能 B 发布

有效处理依赖

• 在路线图文档中明确列出每项依赖
• 指定一名负责人，跟踪并解决每项依赖
• 确定“需要日期”：上游交付成果最晚何时到位，下游事项才能按计划进行
• 为依赖项预留时间余量——它们是任何计划中风险最高的节点
• 尽早升级跨团队依赖；延迟越久，协调成本越高
• 准备备用方案：如果某项依赖延期，有什么替代路径？

最大限度减少依赖的策略

• 探索缩小范围的版本是否能完全绕开依赖
• 使用接口契约或模拟对象，以便并行开发
• 调整顺序，让依赖项在时间线上更早得到解决
• 将依赖工作纳入自己的团队，以消除协调成本

团队产能规划

估算可用产能

• 从团队人数和规划周期开始估算
• 扣除已知的非计划工作：定期会议、值班轮班、招聘流程、假期和计划休假
• 一个实用的基准：工程师通常将 60-70% 的时间投入计划内的路线图工作
• 将新成员在周期中途加入时的适应时间考虑在内

资源分配指南

大多数产品团队的均衡分配方式：

• 70% 战略交付：推进业务目标的路线图举措
• 20% 基础设施健康：减少技术债务、强化可靠性、优化性能、改进开发者工具
• 10% 预留：用于紧急请求、突发升级和范围较小的机会

根据具体情况调整比例：

• 较新的产品适合加大功能投入，减少技术债务工作
• 成熟的产品适合增加可靠性和可扩展性方面的投入
• 事故发生后的阶段需要加强对基础设施的关注
• 超高速增长阶段需要投入资源提升可扩展性和运营韧性

平衡雄心与现实

• 当计划中的承诺超出可用产能时，应缩小范围，而不是降低对个人产出的期待
• 制定常设规则：在计划中增加一项举措，就必须移除或推迟另一项
• 可靠地兑现更少的承诺，比过度承诺却错过期限更能建立组织信任

沟通路线图调整

路线图修订的触发因素

• 领导层提出新的战略指示
• 用户研究或客户反馈导致优先级重新排序
• 工程探索发现工作量估算发生重大变化
• 其他团队的依赖项未能按期完成
• 团队构成发生变化：扩招、人员流失或关键成员离职
• 竞争态势出现需要应对的新进展

清晰传达变更

1. 直接说明变更：哪些事项发生了调整，调整方向是什么
2. 解释触发因素：是什么新信息促成了这一决定
3. 说明取舍：为配合此次调整，哪些事项被降低优先级或推迟
4. 展示修订后的计划：反映最新情况的路线图
5. 联系受影响方：原本依赖优先级降低事项的利益相关方，应直接收到沟通

保持稳定

• 并非每个新数据点都值得修订路线图。应在做出变更前设定重要性门槛。
• 除非确实紧急，否则应在自然节奏节点（每月或每季度）集中调整。
• 区分战略优先级重排（路线图变更）与正常执行优化（举措范围调整）。
• 跟踪路线图变更的频率。过于频繁的变动可能意味着战略模糊，而非适应性规划。