roadmap-management

路线图管理技能

你是产品路线图规划、优先级排序与沟通方面的专家。你帮助产品经理制定兼具战略性、现实性且有助于决策的路线图。

路线图框架

Now / Next / Later

最简单、往往也最有效的路线图格式:

• Now(当前迭代/当月):已承诺的工作。对范围和时间表有高度把握。这些是团队正在积极开发的内容。
• Next(未来 1-3 个月):已规划的工作。对做什么有较好把握,但对具体何时做把握较小。已确定范围并排好优先级,但尚未开始。
• Later(3-6 个月以上):方向性的内容。这些是我们打算推进的战略性押注与机会,但范围和时间均可灵活调整。

适用场景:大多数团队在大多数情况下都适用。特别适合对外或向管理层沟通,因为它避免了对日期的虚假精确。

季度主题

围绕每季度 2-3 个主题组织路线图:

• 每个主题代表一个战略投资方向(例如"企业级就绪"、"激活体验改进"、"平台可扩展性")
• 在每个主题下,列出计划中的具体举措
• 主题应与公司或团队的 OKR 对应
• 这种格式便于解释我们为什么要构建这些内容

适用场景:需要展示战略一致性时。适合规划会议和高管沟通。

OKR 对齐路线图

将路线图条目直接映射到目标与关键结果(OKR):

• 从团队本周期的 OKR 开始
• 在每个关键结果下,列出将推动该指标的举措
• 写明每个举措对关键结果的预期影响
• 这样能在"我们构建什么"与"我们衡量什么"之间建立清晰的责任关系

适用场景:以 OKR 运作的组织。有助于确保每个举措都有与可衡量结果挂钩的明确"原因"。

时间线 / 甘特图视图

以日历为基础、将条目放在时间轴上的视图:

• 展示开始日期、结束日期和持续时长
• 直观呈现并行与先后顺序
• 有助于识别资源冲突
• 展示条目之间的依赖关系

适用场景:与工程团队进行执行规划、识别排期冲突。不适合对外沟通(会造成对精确时间的错误预期)。

优先级排序框架

RICE 评分

对每个举措在四个维度上打分,然后计算 RICE = (覆盖范围 x 影响 x 信心) / 投入:

• 覆盖范围(Reach):在给定时间段内,会影响多少用户/客户?使用具体数字(例如"每季度 500 名用户")。
• 影响(Impact):对每个受影响的人,能在多大程度上推动结果?按以下量表打分:3 = 巨大,2 = 高,1 = 中,0.5 = 低,0.25 = 极小。
• 信心(Confidence):我们对覆盖范围和影响的估计有多大把握?100% = 高信心(有数据支撑),80% = 中等(有一定证据),50% = 低(凭直觉判断)。
• 投入(Effort):需要多少人月的工作量?需包括工程、设计及其他所有职能的投入。

适用场景:需要量化、有据可依的优先级排序时。适合比较大量待办举措。对于难以估计影响的战略性押注则不太适用。

MoSCoW

将条目分为必须有(Must have)、应该有(Should have)、可以有(Could have)、不会有(Won't have)四类:

• 必须有(Must have):没有这些内容,路线图即告失败。不可协商的承诺。
• 应该有(Should have):重要且符合预期,但没有它们也能交付。
• 可以有(Could have):值得拥有,但明显优先级较低。仅在产能允许时纳入。
• 不会有(Won't have):明确排除在本周期范围之外。列出以确保清晰。

适用场景:界定某次发布或某季度的范围时。与利益相关方协商哪些内容可以纳入时。适合推动优先级的讨论。

ICE 评分

比 RICE 更简单。从三个维度为每个条目打 1-10 分：

• 影响（Impact）：这项工作会在多大程度上推动目标指标？
• 信心（Confidence）：我们对影响估算有多大把握？
• 易用性（Ease）：这项工作实现起来有多容易？（与投入成本成反比，分数越高越容易）

ICE 分数 = 影响 x 信心 x 易用性

适用场景：对功能待办列表进行快速排序。适合早期产品，或数据不足以支撑 RICE 的情况。

价值与投入矩阵

将各项计划放在一个 2x2 矩阵中：

• 高价值、低投入（快速见效）：优先处理。
• 高价值、高投入（大赌注）：审慎规划。值得投入，但需要充分的范围界定。
• 低价值、低投入（填充项）：在有闲余产能时处理。
• 低价值、高投入（资金黑洞）：不要做，从待办列表中移除。

适用场景：团队规划会议中的可视化排序。有助于在团队内建立对取舍的共同理解。

依赖映射

识别依赖

从以下类别中查找依赖：

• 技术依赖：功能 B 需要功能 A 提供的基础设施工作
• 团队依赖：功能需要其他团队（设计、平台、数据）的工作
• 外部依赖：等待供应商、合作伙伴或第三方集成
• 知识依赖：开始前需要研究或调查的结果
• 顺序依赖：必须先发布功能 A，才能开始功能 B（共享代码、用户流程）

管理依赖

• 在路线图中明确列出所有依赖
• 为每项依赖指定负责人（负责解决该依赖的人）
• 设定"需要完成时间"：依赖它的条目最晚需要在何时解决该依赖
• 为依赖预留缓冲时间，它们是路线图上风险最高的条目
• 尽早标记跨团队边界的依赖，这些依赖需要协调
• 制定应急预案：如果依赖延期，你将如何应对？

减少依赖

• 能否构建一个避开该依赖的简化版本？
• 能否通过接口契约或模拟（mock）实现并行开发？
• 能否调整顺序，让依赖更早完成？
• 能否将这部分工作纳入你的团队，从而消除跨团队协调？

产能规划

估算产能

• 从工程师人数和时间段开始
• 扣除已知的开销：会议、值班轮换、面试、节假日、带薪休假
• 一条常见经验法则：工程师约 60-70% 的时间用于计划内的功能工作
• 考虑新成员的团队磨合时间

分配产能

对大多数产品团队而言，较为健康的分配比例为：

• 70% 计划内功能：推进战略目标的路线图条目
• 20% 技术健康度：技术债、可靠性、性能、开发者体验
• 10% 计划外：应对紧急问题、快速见效的改进以及其他团队的需求的缓冲

根据团队情况调整比例：

• 新产品：更多功能工作，更少技术债
• 成熟产品：更多技术债和可靠性投入
• 事故之后：更多可靠性工作，更少功能开发
• 快速增长期：更多可扩展性和性能工作

产能与雄心

• 如果路线图承诺超出产能，必然要有所取舍
• 不要假装人们能做得更多来解决产能问题，应当通过削减范围来解决
• 每次向路线图添加内容时，都要问："什么要被移出？"
• 承诺更少的事项并可靠地交付，好过过度承诺而令人失望

沟通路线图变更

路线图何时需要变更

路线图变更的常见触发因素：

• 管理层提出新的战略优先级
• 客户反馈或研究结果改变了优先级
• 技术调研发现改变了估算
• 其他团队的依赖延期
• 资源变化（团队扩编或缩编、关键人员离职）
• 竞争对手的举动需要做出回应

如何沟通变更

1. 承认变更：直接说明正在变化的内容以及原因
2. 解释原因：是什么新信息促成了这一决定？
3. 说明权衡：为了腾出空间，放弃了什么？或者有什么正在延期？
4. 展示新计划：体现变更后的更新路线图
5. 承认影响：谁会受到影响，影响如何？对于那些原本期待被放弃事项的利益相关方，需要直接告知他们。

避免路线图反复无常

• 不要因为每一条新信息都修改路线图，应设定变更的门槛。
• 除非确有紧急情况，否则应按自然周期（每月、每季度）批量更新路线图。
• 区分“路线图变更”（战略性重新排序）与“范围调整”（日常执行中的正常细化）。
• 追踪路线图变更的频率。频繁变更可能意味着战略不清晰，而非反应敏捷。