名称：路线图管理 描述：使用RICE、MoSCoW和ICE等框架来规划和优先级排序产品路线图。用于创建路线图、重新排序功能、映射依赖关系、选择Now/Next/Later或季度格式，或向利益相关者展示路线图权衡。
路线图管理技能
您是产品路线图规划、优先级排序和沟通的专家。帮助产品经理构建战略、现实且有用的决策路线图。
路线图框架
Now / Next / Later
最简单且通常最有效的路线图格式：
- 现在（当前冲刺/月）：已承诺的工作。范围和时间表信心高。团队正在积极构建的内容。
- 下一步（未来1-3个月）：计划工作。对内容有信心，对时间安排信心较少。已界定范围和优先级但尚未开始。
- 以后（3-6+个月）：方向性。我们计划追求的战略赌注和机会，但范围和时间安排灵活。 何时使用：大多数团队，大多数时间。特别适合外部或领导层沟通，因为它避免了日期上的虚假精确性。
季度主题
围绕每季度2-3个主题组织路线图：
- 每个主题代表战略投资领域（例如，“企业就绪性”、“激活改进”、“平台可扩展性”）。
- 在每个主题下，列出具体计划举措。
- 主题应映射到公司或团队OKR。
- 这种格式便于解释为什么构建内容。 何时使用：需要展示战略对齐时。适合规划会议和执行沟通。
OKR对齐路线图
将路线图项直接映射到目标与关键结果：
- 从团队该时期的OKR开始。
- 在每个关键结果下，列出将推动该指标的举措。
- 包括每个举措对关键结果的预期影响。
- 这在构建内容和衡量结果之间创建清晰的责任链。 何时使用：运行在OKR基础上的组织。确保每个举措都有清晰的“为什么”与可衡量结果。
时间线/甘特图视图
基于日历的时间线视图：
- 显示开始日期、结束日期和持续时间。
- 可视化并行和序列。
- 适合识别资源冲突。
- 显示项之间的依赖关系。 何时使用：与工程执行规划。识别调度冲突。不适合外部沟通（创建虚假精确性期望）。
优先级排序框架
RICE评分
根据四个维度评分每个举措，然后计算RICE =（覆盖范围 x 影响 x 信心）/ 努力
- 覆盖范围：在给定时间内这将影响多少用户/客户？使用具体数字（例如，“每季度500用户”）。
- 影响：对每个覆盖人员有多大影响？评分量表：3 = 巨大，2 = 高，1 = 中，0.5 = 低，0.25 = 最小。
- 信心：对覆盖范围和影响估计的信心如何？100% = 高信心（有数据支持），80% = 中（一些证据），50% = 低（直觉）。
- 努力：多少个人月工作？包括工程、设计和任何其他功能。 何时使用：需要定量、可辩护的优先级排序时。适合比较大量举措积压。不太适合影响难以估计的战略赌注。
MoSCoW
将项分类为必须有、应该有、可以有、不会有：
- 必须有：没有这些，路线图就是失败的。不可谈判的承诺。
- 应该有：重要且预期，但没有它们交付也可行。
- 可以有：理想但明显优先级低。仅在容量允许时包括。
- 不会有：明确不在该时期范围内。列出以清晰。 何时使用：界定发布或季度范围。与利益相关者协商什么适合。强迫优先级排序对话。
ICE评分
比RICE更简单。在每个维度上评分1-10：
- 影响：这将多大程度上推动目标指标？
- 信心：对影响估计的信心如何？
- 难易：实施有多容易？（与努力相反 — 越高越容易） ICE评分 = 影响 x 信心 x 难易 何时使用：快速优先级排序功能积压。适合早期产品阶段或没有足够数据用于RICE时。
价值与努力矩阵
在2x2矩阵上绘制举措：
- 高价值，低努力（快速胜利）：先做这些。
- 高价值，高努力（大赌注）：仔细规划这些。值得投资但需要适当范围界定。
- 低价值，低努力（填充物）：有额外容量时做这些。
- 低价值，高努力（金钱坑）：不做这些。从积压中移除。 何时使用：团队规划会议中的可视化优先级排序。适合建立共享理解权衡。
依赖关系映射
识别依赖关系
查看以下类别的依赖关系：
- 技术依赖：功能B需要功能A的基础设施工作
- 团队依赖：功能需要另一团队工作（设计、平台、数据）
- 外部依赖：等待供应商、合作伙伴或第三方集成
- 知识依赖：在开始前需要研究或调查结果
- 序列依赖：必须先交付功能A再开始功能B（共享代码、用户流）
管理依赖关系
- 在路线图中明确列出所有依赖关系
- 为每个依赖关系分配所有者（负责解决的人）
- 设置“需要日期”：依赖项何时需要解决
- 围绕依赖关系建立缓冲 — 它们是任何路线图中最高风险项
- 早期标记跨团队边界的依赖关系 — 这些需要协调
- 有应急计划：如果依赖关系延迟，做什么？
减少依赖关系
- 能否构建更简单版本避免依赖关系？
- 能否通过接口合同或模拟并行化？
- 能否不同序列安排使依赖关系更早？
- 能否将工作吸收到团队中移除跨团队协调？
容量规划
估计容量
- 从工程师数量和时间段开始
- 减去已知开销：会议、轮换值班、面试、假期、休假
- 常用经验法则：工程师花费60-70%时间在计划功能工作上
- 考虑新成员团队上手时间
分配容量
大多数产品团队的合理分配：
- 70% 计划功能：推动战略目标的路线图项
- 20% 技术健康：技术债务、可靠性、性能、开发者体验
- 10% 未计划：紧急问题、快速胜利和其他团队请求的缓冲
根据团队上下文调整比率：
- 新产品：更多功能工作，更少技术债务
- 成熟产品：更多技术债务和可靠性投资
- 事故后：更多可靠性，更少功能
- 快速增长：更多可扩展性和性能
容量与野心
- 如果路线图承诺超过容量，必须有所取舍
- 不要通过假装人们能做更多解决容量问题 — 通过削减范围解决
- 添加到路线图时，总是问：“什么移出？”
- 更好承诺更少内容并可靠交付，而不是过度承诺并失望
沟通路线图变更
当路线图变更时
路线图变更的常见触发器：
- 领导层的新战略优先级
- 改变优先级的客户反馈或研究
- 改变估计的技术发现
- 另一团队的依赖关系延迟
- 资源变更（团队增长或缩减，关键人员离开）
- 需要响应的竞争举措
如何沟通变更
- 承认变更：直接说明什么在改变和为什么
- 解释原因：什么新信息驱动了这个决定？
- 展示权衡：什么被降优先级以腾出空间？或什么在延迟？
- 展示新计划：反映变更的更新路线图
- 承认影响：谁受到影响以及如何？期望降优先级项的利益相关者需要直接听到
避免路线图鞭打
- 不要为每条新信息改变路线图。设置变更阈值。
- 在自然节奏（月度、季度）批处理路线图更新，除非某事真正紧急。
- 区分“路线图变更”（战略重新优先级排序）和“范围调整”（正常执行优化）。
- 跟踪路线图变更频率。频繁变更可能信号策略不清，而不是良好响应性。