roadmap-planning

路线图规划

开始之前

首先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请阅读。

如果 .agents/em-context.md 不存在，请先询问最基本的经理背景信息，并在给出详细建议前保存：角色／职称、团队规模、团队使命或负责范围，以及当前面临的挑战或优先事项。

如果对话中某位特定人员是关键人物，而 .agents/reports/[name].md 不存在，请先询问该人员的基本背景信息，并在给出详细建议前保存：职称／级别、任职时间、优势，以及当前面临的挑战或成长方向。

如果之后的对话透露出持久的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、短暂的挫败情绪或尚未厘清的解读。

回复风格

第一条回复要简洁实用。除非用户要求深入探讨，否则不要倾倒整套框架。

默认做法：

• 首先说明可能的诊断或建议
• 仅在缺失的背景信息会改变建议时，提出最多 2-3 个有针对性的问题
• 给出下一步的具体行动，并在有帮助时提供经理可以直接使用的措辞
• 简要提及相关框架，但不要解释其中的每个部分
• 先直接回答，再提出可以提供更深入的版本

---

如何使用此技能

• 与利益相关方协商技术债务投入时间 → 技术债务与“20% 规则”
• 功能正在分阶段实施——检验这种做法是否合理 → 分阶段发布
• 需要展示构建新功能的持续成本 → 将维护成本视为第三个维度
• 团队总是无法完成 Sprint 目标／团队被认为“速度慢” → 始终保持绿色方法
• Sprint 仪式带来的摩擦大于价值 → Sprint 反模式
• PM 不断添加一次性的定制功能 → 定制功能的隐性成本
• 关键截止日期面临风险——该怎么办 → 团队无法赶上关键截止日期时
• 项目估算总是不准确 → 项目的铁律
• 技术工作总是被降级处理 → 不存在纯技术项目
• 团队不断交付，但似乎毫无影响 → 功能工厂的警示信号
• 举办全公司清理活动 → 阅读 references/extended.md — Cleanathon

---

默认回复结构

协助规划路线图时，要清楚呈现各种取舍：

1. 规划问题： 技术债务、阶段划分、截止日期、产能、维护、功能工厂或利益相关方协同。
2. 决策框架： 实际有哪些备选方案。
3. 业务转译： 工程工作对产品或公司为何重要。
4. 建议： 现在该做什么，以及哪些内容应推迟。
5. 利益相关方沟通： 面向 PM、领导层或团队的简洁措辞。

如果问题是“技术工作总是败下阵来”，在为其争取支持前，先将其转化为风险、成本、速度、可靠性或客户影响。

---

技术债务与“20% 规则”

将 20% 的产能用于纯工程工作，是广受推荐的做法，而且确实有效。但大多数团队的执行方式并不理想，容易落入一些可预见的陷阱。

5 个陷阱

1. 产品和技术各自维护待办列表

当产品工作和技术工作分属不同的待办列表时，产品团队不再干预技术决策，工程团队也不再关注产品优先级。这听起来像是相安无事，实际上却是在慢慢走向失败。

产品和技术并不是彼此独立的。修复 Bug、更新库、改进自动化、安全补丁——这些工作几乎都有业务价值（可靠性、安全性、交付速度）。

解决方法：技术列表中的每个事项都应明确定义业务价值。一旦定义清楚，就把它移到产品待办列表中，与其他事项一起排序。只有当关键工作难以向非技术相关方解释时，才保留单独的技术轨道。

2. 公司不了解你工作的价值

如果业务团队不关心或不了解你的技术计划，那么一旦出现“紧急”事项，这些计划总会最先被降级处理。你在争取招聘、培训或额外时间时也会困难得多。

解决方法：让技术工作变得可见。每月举行评审，由工程团队介绍那些不属于特定产品团队的技术计划进展。用业务语言说明这项工作的意义，而不只是说“我们迁移到了 Swift”，而要说明“这能缩短编译时间、改善开发者体验，并有助于招聘，因为愿意接触 Objective-C 的工程师更少”。

3. 焦点分散

分出 20% 的时间并不能解决所有问题。如果你给团队中的每个人都安排一个不同方向的技术计划，就不会在任何地方取得真正的进展。

解决方法：把 20% 的时间集中用于一组目标一致、能够推动长期工程战略的计划。明确目标，了解哪些计划有助于实现目标，并抵制同时解决所有技术痛点的诱惑。

4. “我们以后再修”

团队有了 20% 的受保护时间后，人们很容易想要加快进度，认为技术债以后再清理。可这几乎从未发生——下一个 Sprint 总会有更紧急的事情。

20% 的时间是为了让事情变得更好，而不只是没那么糟。即使是在构建 MVP，也必须确保它功能完善、易于使用且可靠。“等推送给客户后再写测试”就是一个典型例子——这些任务几乎从来不会完成，因为你要么在修复生产问题，要么已经开始下一个计划。

5. 大型计划的效率低下

20% 的时间相当于每周一天、每天 1.5 小时，或每月约 4–5 天。对于真正的大型计划——例如拆分单体架构、重新搭建平台——这意味着要花一年不断切换上下文，才能取得相当于两三个月的进展。这行不通。

解决方法：大型战略计划不应纳入 20% 的时间，而应成为产品优先事项，并具备业务依据、获得整个组织的支持，同时跟踪进展。把 20% 的时间留给真正的维护工作和较小的战术性改进。

---

分阶段发布：何时有帮助，何时没有

分阶段发布功能听起来谨慎稳妥、能降低风险。但很多时候，这只会拖延获取经验，还会增加阻力。

用以下五个问题审视分阶段路线图：

1. 分阶段是因为用户提出了需求，还是因为团队想做更多？ 第 2 阶段往往是愿望清单，而非用户需求。
2. 没有第 2 阶段，用户真的会使用第 1 阶段吗？ 如果第 1 阶段本身没有价值，你交付的就只是个空壳。用户不在乎你们内部如何划分阶段。
3. 第 1 阶段能让你学到什么，从而为第 2 阶段提供依据？ 如果你说不出来，那第 2 阶段已经设计得滴水不漏了——这意味着你并没有把第 1 阶段当作一个学习里程碑。
4. 如果第 1 阶段之后就停止，代价是什么？ 分阶段会让团队内部形成预期。第 1 阶段一经发布，第 2 阶段就会开始像一种承诺，而非一种选择。
5. 有没有更简单的版本，能交付完整价值？ “第 1 阶段 + 第 2 阶段”的最佳版本往往就是范围界定得更好的第 1 阶段。

本田的故事。 本田进入美国摩托车市场时，计划以大型摩托车——那些真正的摩托车——打头阵。那些车却出了故障。反而是他们自己骑着四处活动的小型廉价摩托车引起了关注。他们迅速调整方向，开拓出了一个原本未曾计划的市场。

这个故事的启示是：最初的计划只是一种假设。优秀的产品团队愿意在功能开发过程中途叫停，只要信号表明应该这么做。他们把停止视为良好产品文化的体现，而非失败。

向团队传达这一点。 功能被叫停时，工程师往往会感到沮丧。你的职责是换一种方式来表达：“我们已经发布，也学到了经验，现在正根据真实数据调整方向。这本来就应该如此。”另一种做法——明知行不通还继续开发——才是真正的失败。

---

将维护成本视为第三个维度

路线图讨论通常会被限制在两个维度上：做什么，以及需要多长时间。这样就忽略了你承诺的一切带来的持续成本。

你发布的每项功能都会永久增加负担。维护、支持、确保其快速且安全——即使没有任何技术债务，也需要团队持续投入产能。系统之间越不相关，这件事就越难处理。

如何将维护成本纳入讨论：

1. 梳理你负责的每个系统当前产生的持续成本（错误修复、服务中断、紧急客户请求、安全补丁）
2. 估算其占团队产能的比例（例如，“每个系统约占我们 10% 的时间”）
3. 展示承担拟议的新工作后，持续成本预计会如何增加
4. 把这些信息摆出来，让对方做决定

这些数字不会准确。这并不是重点。目标是让维护成本这个维度在讨论中清晰可见——不求精确，而是改变大家会考虑的因素。

开始追踪这些事项，并用实际案例来讨论之后，在不让人觉得你是在阻挠的情况下，对范围提出异议就会容易得多。

---

始终按时交付的方法

交付速度有 95% 取决于感知。持续按时完成小目标的团队会被认为速度很快。追求宏大目标却未能实现的团队看起来很慢——即使他们交付的内容更多。

核心见解：只要选择合适的目标，你总能按时交付。

山丘概念（来自 Shape Up）

每个项目都有两个阶段：爬山（发现未知事项，弄清楚实际要构建什么）和下山（执行已经明确的工作）。仅靠规划，你无法完全了解项目的需求——必须爬到足够高处，才能看清全貌。

在承诺实现某个目标之前，提前一个 sprint 开始工作。花几天时间真正动手——找出难点、依赖关系和未知事项。到达山顶后，你就能满怀信心地做出承诺。范围上的意外情况也会变得少见。

如何设定总能完成的 sprint 目标：

1. 选择一个最小目标。 一个明确、面向用户的成果。不必花哨。它最多应占团队一半的产能——这样你就能确信周中之前可以完成。
2. 将其拆分为可并行开展的工作。 各部分之间互不阻塞，成员可以各自推进。不依赖其他团队。
3. 公开宣布。 在共享频道中发布：“即使其他事情都不顺利，我们也会交付这个。” 全权负责。
4. 每天跟进。 密切关注，立即排除阻碍。必要时，把人员从“非目标”任务中调过来。
5. 完成它。 如果你有 3 个目标，就需要 3 个勾选标记。完成三分之二并不算成功——这只会让大家再次认定你的团队无法完成目标。

sprint 的其余工作不会停下——Bug、技术债务、规划、支持其他团队。最小目标只是不可妥协的底线。

关于宏大目标： 持续实现 100% 交付率的团队，长期来看比追逐宏大目标却未能实现的团队做得更多。总能成功的团队效率更高、更受信任，也更愿意额外超额交付。另一种做法——目标宏大，却总是落空——只会让所有人精疲力尽。

---

Sprint 反模式

僵化地执行 sprint 会带来新的问题。以下迹象表明 sprint 流程正在妨碍团队：

• 到 sprint 结束时，选择一个较小的 Bug 来做，因为 2 天时间不足以完成真正重要的工作
• 仍在推动完成已经不再合理的 sprint 目标
• 把“推进 X 的进展”算作 sprint 目标
• 将速率作为成功指标跟踪，却一再延迟交付功能
• 技术债务连续 6 个月被推到“下一个 sprint”

无法改变流程时的应对方法：

• 始终留出余地。有人说“把它放进 sprint 吧，最坏的情况是再挪出去”时，要坚持回应：“还是别放进去吧，最好的情况是有时间时再加进来。”
• 不要强行设定毫无意义的 sprint 目标。没有目标也比假目标好。
• 有人完成自己的任务后，就让他们做自己想做的事。
• 争取安排“质量 sprint”——每年至少一次，留出 2–3 周来修复问题。
• 质疑那些对团队没有帮助的做法。每日站会毫无价值？那就改成可选参加。

自定义功能的隐性成本

当项目经理或客户提出一次性的“特殊”功能时，显而易见的成本是开发时间。还有三项成本几乎从未被纳入估算：

1. 未来维护成本——每项自定义功能都需要修复、适配产品变更并保持正常运行。这项成本会无限累积。
2. 复杂性成本——每增加一项功能，产品整体都会变得更加复杂，从而增加后续每项功能的成本。
3. 机会成本——这一个开发者月本可以用于影响更大的工作。

实用应对方式：

• 为“客户特供功能”定价时，显著高于标准功能，以体现真实成本
• 追踪团队产能中用于特供功能的比例。与项目经理／管理层商定上限
• 衡量功能的实际使用情况。无人使用的功能只会产生维护成本，没有任何回报

---

团队无法赶上关键期限时

当硬性期限面临风险时，大多数管理者首先想到的办法往往最不奏效。

几乎从不奏效的办法：

• 增加人手——向进度落后的项目中增加开发者，会带来沟通开销，并且一开始会拖慢进度（布鲁克斯定律）。唯一的例外是：如果足够早地安排一位高级开发者与现有开发者结对协作，可能会有帮助。
• 降低质量——“我们之后再写测试”所耗费的成本总是超过节省的时间。这要么会导致上线后出现紧急问题，要么会累积成无法偿还的质量债务。

有时奏效的办法：

• 增加工作时间——真正的危机中确实可能有必要，但会开创先例。应谨慎使用。

最有效的办法：

• 缩减范围——找出哪些内容可以删减，同时仍能交付核心价值。“我们至少要交付什么，才能解决这个问题？”这是赶期限之前最重要的问题，而不是期限迫近时才问。

---

项目的铁律

摘自 How Big Things Get Done（Flyvbjerg）：在对数千个大型项目的研究中，只有 8.5% 按时并在预算内完成。这并非项目管理失误，而是人类规划方式的一种结构性特征。

估算几乎总是不准确的原因：

• 规划者以最佳情形为基准，并认为项目独一无二（“这个项目很特殊”）
• 未知的未知因素不会出现在任何估算中
• 复杂性呈非线性增长，估算却呈线性增长
• 乐观偏差：团队会系统性地低估工期和成本

参考类别预测——解决方法：

不要从头开始估算（“这需要多久？”），而要问：“类似的项目结果如何？”

找出一组已完成的可比项目——范围、团队和领域都相似。看看它们实际用了多久、花了多少钱。以此为估算基准，再根据具体差异进行调整。

这听起来显而易见，但几乎没人这么做。人们本能地把每个项目都当作独特项目，并自下而上地估算。数据表明：外部视角（可比项目）几乎总是比内部视角（详细的自下而上估算）更准确。

慢思考，快行动：

项目交付中成本最高的事情，就是在执行过程中改变方向。Flyvbjerg 的原则是：在承诺之前投入大量精力进行规划，承诺之后就快速执行。

让项目失败的模式是：设计尚未确定就迅速启动，随后在中途遇到根本性问题，只能付出高昂代价转向，或者交付无法正常工作的成果。

实际做法：在批准大型计划之前，先问设计是否真正敲定。“边做边想”不算设计。爬坡概念（见“始终保持绿色的方法”）是同一理念的微型版本：在承诺之前，先爬到足以看清完整范围的位置。

---

没有纯技术项目

值得牢记的犀利观点：所有项目都是业务项目。 如果工程团队做的事情无法用业务价值来论证，那他们做得就不对。

这并不意味着要放弃技术工作。它意味着每项技术举措——重构、依赖项升级、基础设施变更、架构改进——都应围绕其带来的业务价值来阐述。

看起来像	实际上是
重构	将功能交付时间缩短 N 周
更新依赖项	降低安全风险和支持成本
添加测试	降低生产事故的发生频率和处理成本
改进架构	让团队能够构建他们目前无法构建的 X

业务论据不必精确，但必须真实且清晰可见。技术工作如果没有业务层面的阐述，就会成为规划中最先被砍掉的项目；如果有，就能与其他项目平等竞争。

还有一条原则：有些事情就是必须做。 没有测试、安全保障或运维支持，就无法构建软件。要解释这些工作为何必要，但不要让“可这本质上是业务决策”成为持续降低这类保障系统正常运行的工作的优先级的理由。

---

功能工厂的警示信号

以下迹象表明，你的团队正被当成功能工厂运作——只交付产出，却不衡量成果：

• 功能发布后没有衡量其影响
• 团队不断在项目之间重新组合（团队俄罗斯方块）
• 一味围绕“交付”做表面文章，却从不讨论交付是否奏效
• 即使功能无人使用，也从不移除
• 团队无法将自己的工作与关键业务或客户指标联系起来
• 回顾会只关注流程，从不讨论产品决策是否正确

风险在于，功能工厂看起来效率很高——交付很多、演示很多——但实际上创造的业务价值很少。作为工程经理（EM），你的职责是推动衡量成果，即便交付机器不愿意放慢速度。

---

深入了解

如果用户询问某个框架的来源、想阅读原文，或希望进一步了解此技能中的任何主题，请阅读 references/sources.md。如需举办全公司范围的清理活动，请阅读 references/extended.md。

---

相关技能

• shadow-work — 隐性待办和未跟踪的工作是导致容量规划失败的主要原因
• team-health — 将团队容量和士气作为规划依据
• working-with-pm — 真正的合作能为产品和技术制定统一路线图
• managing-urgency — 截止日期压力凌驾于计划之上时