roadmap-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Roadmap Planning

路线图规划

Before Starting

开始之前

Check for EM context first. If

.agents/em-context.md

exists, read it.

.agents/em-context.md

does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and

.agents/reports/[name].md

does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update

.agents/em-context.md

.agents/reports/[name].md

automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先检查工程经理（EM）相关背景信息。如果存在

.agents/em-context.md

文件，请读取该文件。

如果

.agents/em-context.md

文件不存在，请先询问并保存一份极简的经理资料，再提供详细建议：职位/头衔、团队规模、团队使命或负责领域、当前挑战或优先级。

如果对话核心涉及特定人员且

.agents/reports/[name].md

文件不存在，请先询问并保存该人员的极简资料，再提供详细建议：职位/级别、任职时长、优势、当前挑战或成长方向。

如果后续对话出现可长期留存的新背景信息，请自动更新

.agents/em-context.md

或

.agents/reports/[name].md

文件。仅保存稳定事实和模式，不保存猜测内容、短暂情绪或未明确的解读。

Response Style

回应风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

State the likely diagnosis or recommendation first
Ask at most 2-3 targeted questions only if the missing context changes the advice
Give the next concrete action and, when useful, exact wording the manager can use
Mention the relevant framework briefly, but do not explain every part of it
Offer a deeper version only after the direct answer

首次回答需简洁实用。除非用户要求深入讲解，否则不要一次性输出完整框架内容。

默认遵循以下原则：

先给出可能的诊断或建议
仅当缺失背景信息会影响建议时，提出最多2-3个针对性问题
给出下一步具体行动，必要时提供经理可直接使用的精准话术
简要提及相关框架，但无需解释每个细节
在直接回答后，再提供深入版本的选项

How to Use This Skill

如何使用本技能

Negotiating tech debt time with stakeholders → Tech Debt and the "20% Rule"
Feature is being broken into phases — pressure-test whether it's right → Phased Releases
Need to show the ongoing cost of building new things → Maintenance Costs as a Third Dimension
Team keeps missing sprint goals / perception of the team is "slow" → The Always Green Method
Sprint rituals are creating more friction than value → Sprint Anti-Patterns
PM keeps adding one-off custom features → Hidden Costs of Custom Features
Hard deadline is at risk — what to do → When the Team Can't Make a Critical Deadline
Project estimates keep being wrong → The Iron Law of Projects
Technical work keeps getting deprioritized → There Are No Technical Projects
Team is shipping but nothing seems to have impact → Feature Factory Warning Signs
Running a company-wide cleanup event → read
```
references/extended.md
```
— The Cleanathon

与利益相关者协商技术债务处理时间 → 技术债务与“20%规则”
功能需分阶段开发——验证该方案是否合理 → 分阶段发布
需要展示持续构建新功能的成本 → 作为第三维度的维护成本
团队持续未达成Sprint目标 / 团队被认为“效率低下” → Always Green方法
Sprint仪式带来的摩擦大于价值 → Sprint反模式
产品经理不断添加一次性自定义功能 → 自定义功能的隐性成本
关键期限面临风险——该如何应对 → 当团队无法达成关键期限时
项目估算持续偏差 → 项目铁律
技术工作持续被降优先级 → 不存在纯技术项目
团队不断交付但无实际影响 → 功能工厂预警信号
开展全公司范围的清理活动 → 阅读
```
references/extended.md
```
—— Cleanathon（清理马拉松）

Default Response Shape

默认回应结构

When helping with roadmap planning, make tradeoffs visible:

Planning problem: tech debt, phases, deadlines, capacity, maintenance, feature factory, or stakeholder alignment.
Decision frame: what options are actually on the table.
Business translation: why the engineering work matters in product or company terms.
Recommendation: what to do now and what to defer.
Stakeholder message: concise wording for PMs, leadership, or the team.

If the issue is "technical work keeps losing," translate it into risk, cost, speed, reliability, or customer impact before arguing for it.

在协助路线图规划时，需明确展示权衡关系：

规划问题：技术债务、分阶段开发、期限、产能、维护、功能工厂或利益相关者对齐。
决策框架：实际可选择的方案有哪些。
业务转化：工程工作对产品或公司的价值所在。
建议：当前应采取的行动及可延后的事项。
利益相关者沟通话术：面向产品经理、领导层或团队的简洁表述。

如果问题是“技术工作持续被忽视”，需先将其转化为风险、成本、速度、可靠性或客户影响，再进行争取。

Tech Debt and the "20% Rule"

技术债务与“20%规则”

Dedicating 20% of capacity to purely engineering work is a widely recommended practice — and it genuinely helps. But most teams implement it poorly and fall into predictable traps.

将20%的产能投入纯工程工作是被广泛推荐的做法——且确实有效。但大多数团队执行不当，会陷入可预见的陷阱。

The 5 Traps

5个陷阱

1. Separate backlogs for product and tech

When product work and tech work live in separate backlogs, Product stops interfering in tech decisions and Engineering stops engaging with product priorities. It sounds like peace — it's actually a slow failure.

Product and technology are not separate things. Bug fixes, library updates, automation improvements, security patches — almost all of these have business value (reliability, security, speed of delivery).

The fix: every item on the technical list should have a clearly defined business value. Once it does, move it to the product backlog — where it gets prioritized alongside everything else. Reserve the separate tech track only for critical work too hard to explain to non-technical stakeholders.

2. The company doesn't understand the value of your work

If the business doesn't care about or understand your technical initiatives, those initiatives will always be the first thing deprioritized when "urgent" things appear. And you'll have a much harder time negotiating for hiring, training, or additional time.

The fix: make technical work visible. Hold monthly reviews where engineering teams present the progress of technical initiatives not tied to specific product teams. Show why the work matters in business terms — not just "we migrated to Swift" but "this reduces compilation time, improves developer experience, and helps with hiring because fewer engineers want to touch Objective-C."

3. Diluted focus

Getting 20% doesn't solve everything. If you assign a separate tech initiative to every single person on the team, each going in a different direction — you'll make no real progress anywhere.

The fix: focus your 20% on a coherent set of initiatives that contribute to a longer-term engineering strategy. Know your goals, know which initiatives contribute to them, and resist the temptation to address every technical itch simultaneously.

4. "We'll fix it later"

Once a team has 20% protected time, it becomes tempting to push things faster, assuming tech debt will get cleaned up later. It almost never does — the next sprint always has something more urgent.

20% time is to make things better, not just less bad. Even when building an MVP, it must be functional, usable, and reliable. Writing tests "after we push to customers" is a classic — those tasks almost never get done because you're either fixing production issues or jumping into the next initiative.

5. Ineffectiveness on large initiatives

20% is one day a week, 1.5 hours a day, or ~4–5 days a month. For genuinely large initiatives — breaking down a monolith, re-platforming — this means a year of context-switching to make 2–3 months of progress. It doesn't work.

The fix: large strategic initiatives shouldn't live in the 20% — they should become product priorities with business justification, full organizational support, and tracked progress. Save the 20% for genuine maintenance and smaller tactical improvements.

1. 产品与技术待办事项分离

当产品工作和技术工作分属不同待办事项列表时，产品团队不再干预技术决策，工程团队也不再关注产品优先级。看似相安无事，实则是缓慢的失败。

产品与技术并非独立存在。 bug修复、库更新、自动化改进、安全补丁——几乎所有这些工作都具备业务价值（可靠性、安全性、交付速度）。

解决方案：技术列表中的每一项都应明确其业务价值。一旦确定，将其移至产品待办事项列表——与其他所有工作一同参与优先级排序。仅将难以向非技术利益相关者解释的关键工作保留在单独的技术追踪列表中。

2. 公司不理解技术工作的价值

如果业务方不关心或不理解技术举措，这些举措在出现“紧急”事项时总会最先被降优先级。同时，你在争取招聘、培训或额外时间时也会困难重重。

解决方案：让技术工作可视化。每月开展评审会，由工程团队展示未绑定特定产品团队的技术举措进展。用业务术语说明工作的重要性——不是“我们迁移到了Swift”，而是“这缩短了编译时间，提升了开发者体验，有助于招聘，因为很少有工程师愿意接触Objective-C”。

3. 注意力分散

获得20%的时间并不能解决所有问题。如果给团队中的每个人分配不同的技术举措，各自为政——最终将无法取得实质性进展。

解决方案：将20%的时间集中投入到一组符合长期工程战略的举措上。明确目标，了解哪些举措有助于实现目标，同时抵制同时解决所有技术问题的诱惑。

4. “以后再修复”

一旦团队拥有20%的专属时间，就会倾向于加快推进工作，认为技术债务以后再清理即可。但实际上几乎从未实现——下一个Sprint总会有更紧急的事项。

20%的时间是为了让事情变得更好，而不仅仅是减少问题。即使构建MVP，也必须保证功能可用、易用且可靠。“推送到客户后再写测试”是典型误区——这些任务几乎永远不会完成，因为你要么在修复生产问题，要么在投入下一个举措。

5. 大型举措效率低下

20%的时间相当于每周1天、每天1.5小时，或每月约4-5天。对于真正的大型举措——拆分单体应用、重新平台化——这意味着需要一年的上下文切换才能完成2-3个月的进度。这种方式行不通。

解决方案：大型战略举措不应纳入20%的时间范畴——它们应成为具备业务合理性、获得全组织支持且进度可追踪的产品优先级事项。将20%的时间用于真正的维护和小型战术改进。

Phased Releases: When They Help and When They Don't

分阶段发布：适用场景与误区

Releasing a feature in phases sounds careful and de-risked. Often it just delays learning and creates drag.

Five questions to pressure-test a phased roadmap:

Are you phasing because users asked for it, or because the team wants to build more? Phase 2 is often a wish list, not a user need.
Will Phase 1 actually be used without Phase 2? If Phase 1 alone isn't valuable, you're just shipping a stub. Users don't care about your internal phases.
What are you learning in Phase 1 that should inform Phase 2? If you can't name it, Phase 2 is already fully designed — which means you're not actually using Phase 1 as a learning milestone.
What's the cost of stopping after Phase 1? Phases create internal expectations. Once you ship Phase 1, Phase 2 starts to feel like a commitment rather than a choice.
Is there a simpler version that delivers the full value? The best version of "Phase 1 + Phase 2" is often just a better-scoped Phase 1.

The Honda story. When Honda entered the US motorcycle market, they planned to lead with their large bikes — the serious motorcycles. Those broke down. Their small, cheap motorcycles (which they were riding around themselves) caught attention instead. They pivoted fast and built a market they hadn't planned for.

The lesson: the plan you start with is a hypothesis. Great product teams are willing to stop a feature mid-build if the signal says to. They treat stopping as a sign of good product culture, not failure.

Communicate this to your team. Engineers often feel demoralized when a feature is stopped. Your job is to frame it differently: "We shipped, we learned, we're redirecting based on real data. That's how this is supposed to work." The alternative — continuing to build something that's clearly not working — is the actual failure.

分阶段发布功能看似谨慎且能降低风险，但往往只是延迟学习进度并造成拖累。

通过五个问题验证分阶段路线图的合理性：

分阶段是因为用户需求，还是团队想多做工作？ 第二阶段通常是愿望清单，而非用户需求。
没有第二阶段，第一阶段是否真的能被使用？ 如果第一阶段本身没有价值，那你只是在交付一个空架子。用户并不关心你的内部阶段划分。
第一阶段能获得哪些可指导第二阶段的经验？ 如果无法明确说明，说明第二阶段已完全设计完成——这意味着你并未将第一阶段作为学习里程碑。
在第一阶段后停止的成本是什么？ 分阶段会产生内部预期。一旦发布第一阶段，第二阶段就会变成一种承诺而非选择。
是否存在能交付全部价值的简化版本？ “第一阶段+第二阶段”的最佳替代方案通常是范围更合理的第一阶段。

本田的故事。当本田进入美国摩托车市场时，原本计划以大排量摩托车——专业摩托——为主打产品。但这些车出现了故障。而他们自己骑行的小型廉价摩托车反而引起了关注。他们迅速调整策略，开拓了一个原本未计划的市场。

教训：初始计划只是一个假设。优秀的产品团队愿意根据信号在功能构建中途停止。他们将停止视为良好产品文化的体现，而非失败。

向团队传达这一点。当功能被停止时，工程师往往会感到士气低落。你的工作是换一种方式解读：“我们交付了产品，获得了经验，并根据真实数据调整方向。这才是正确的工作方式。” 相反——继续构建明显无效的东西才是真正的失败。

Maintenance Costs as a Third Dimension

作为第三维度的维护成本

Roadmap discussions usually get trapped on two axes: what to build and how long it will take. This misses the ongoing cost of everything you commit to.

Every feature you ship adds permanent weight. Maintaining it, supporting it, keeping it fast and secure — even with zero technical debt — takes ongoing team capacity. The more unrelated the systems, the harder this becomes.

How to add maintenance cost to the conversation:

Map the current ongoing costs of each system you own (bug fixes, outages, urgent customer requests, security patches)
Estimate as a percentage of team capacity (e.g., "~10% of our time per system")
Show the estimated increase in ongoing cost if you take on the proposed new work
Let the other side make the decision with that information visible

The numbers won't be accurate. That's not the point. The goal is to make the maintenance cost dimension visible in the conversation — not to be precise, but to change what gets considered.

When you start tracking these things and bringing in real stories, it becomes much easier to push back on scope without it feeling like obstruction.

路线图讨论通常局限于两个维度：要构建什么和需要多长时间。这忽略了所有已承诺工作的持续成本。

你交付的每个功能都会增加永久负担。维护、支持、保持其快速安全——即使没有技术债务——也需要持续占用团队产能。系统之间的关联性越低，这项工作就越困难。

如何将维护成本纳入对话：

梳理你负责的每个系统当前的持续成本（bug修复、故障处理、紧急客户请求、安全补丁）
估算其占团队产能的百分比（例如：“每个系统占用我们约10%的时间”）
展示承担拟议新工作后，持续成本的预计增幅
让对方在可见该信息的前提下做出决策

数据无需完全准确。这不是重点。目标是让维护成本维度在对话中可视化——无需精确，只需改变决策考量因素。

当你开始追踪这些数据并引入真实案例后，在推回范围时会更容易，且不会被视为阻碍。

The Always Green Method

Always Green方法

Delivery speed is 95% about perception. A team that consistently delivers on-time small goals is perceived as fast. A team that swings for ambitious goals and misses looks slow — even if they shipped more.

The core insight: you can always deliver on time if you choose the right goals.

The Hill Concept (from Shape Up)

Every project has two phases: climbing the hill (discovering unknowns, figuring out what to actually build) and going down (executing on what's now clear). You can't fully understand what a project requires through planning alone — you have to climb far enough to see everything.

Before committing to a goal, start the work a sprint early. Spend a few days actually doing it — uncovering the hard parts, the dependencies, the unknowns. Once you've reached the top of the hill, you can commit with high confidence. Scope surprises become rare.

How to set a sprint goal that you always finish:

Pick a minimal goal. One clear, user-facing outcome. Nothing fancy. It should fill at most half the team's capacity — so you're confident it's done by midweek.
Break it into parallel work. Pieces that people can work on without blocking each other. No dependencies on other teams.
Announce it publicly. Post in a shared channel: "If all else fails, this is what we deliver." Take full ownership.
Watch it daily. Be on top of it. Unblock immediately. Pull people from "non-goal" tasks if needed.
Finish it. If you have 3 goals, you need 3 checkmarks. Two out of three is not a success — it just resets the expectation that your team doesn't finish.

The rest of the sprint doesn't stop — bugs, tech debt, planning, supporting other teams. The minimal goal is just the non-negotiable floor.

On ambitious goals: teams with consistent 100% delivery rates do more over time than teams chasing ambitious goals and missing. An always-succeeding team is more effective, more trusted, and more willing to over-deliver as a bonus. The alternative — ambitious goals, consistent misses — just burns everyone out.

交付速度95%取决于认知。一个持续按时完成小目标的团队会被认为效率高。一个追求宏大目标却屡屡失败的团队会被认为效率低下——即使他们交付的内容更多。

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

Hill概念（来自Shape Up）

每个项目都有两个阶段：爬山（发现未知，明确实际要构建的内容）和下山（执行已明确的内容）。仅通过规划无法完全了解项目需求——你必须爬到足够高的位置才能看清全貌。

在承诺目标之前，提前一个Sprint启动工作。花几天时间实际开展工作——发现难点、依赖关系和未知因素。一旦到达山顶，你就能高度自信地做出承诺。范围意外会变得罕见。

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

选择最小化目标。一个清晰的、面向用户的成果。无需花哨。它最多应占用团队一半的产能——确保你能在周中前完成。
拆分为并行工作。团队成员可独立开展、互不阻塞的任务。无需依赖其他团队。
公开宣布。在共享频道发布：“即使其他所有工作都失败，我们也要交付这个目标。” 全权负责。
每日跟进。密切关注进度。立即解决阻塞问题。必要时将人员从“非目标”任务中抽调过来。
完成目标。如果有3个目标，就需要3个完成标记。完成2个不算成功——这只会强化“团队无法完成目标”的预期。

Sprint的其余工作仍需继续——bug修复、技术债务处理、规划、支持其他团队。最小化目标只是不可协商的底线。

关于宏大目标： 持续100%交付的团队长期来看比追求宏大目标却屡屡失败的团队完成的工作更多。一个总能成功的团队更高效、更受信任，也更愿意超额交付作为额外成果。相反——追求宏大目标、持续失败——只会让所有人精疲力尽。

Sprint Anti-Patterns

Sprint反模式

Sprints, when followed rigidly, create their own problems. Signs that sprint process is working against the team:

Taking a smaller bug at sprint end because 2 days aren't enough for the real work
Pushing to finish sprint goals that no longer make sense
"Making progress on X" counted as a sprint goal
Velocity tracked as a success metric while features are consistently late
Tech debt moved to "next sprint" for 6 months running

What to do when you can't change the process:

Always leave breathing room. Fight the argument "let's take it in the sprint, worst case we move it" with "let's not take it, best case we add it if we have time."
Don't force meaningless sprint goals. No goal is better than a fake one.
When someone finishes their tasks, let them work on what they want.
Fight for "quality sprints" — 2–3 week periods for fixing things, at least once a year.
Question practices that don't serve your team. Daily standups adding no value? Make them optional.

当严格遵循Sprint流程时，会产生自身的问题。以下是Sprint流程对团队产生负面影响的迹象：

在Sprint末期选择小bug修复，因为2天时间不足以处理真正的工作
继续推进已无意义的Sprint目标
“在X上取得进展”被算作Sprint目标
追踪速度作为成功指标，但功能持续延期
技术债务连续6个月被移至“下一个Sprint”

当无法改变流程时该怎么做：

始终预留缓冲空间。反驳“我们把它放进Sprint，最坏情况移到下一个”的说法，改为“我们先不纳入，如果有时间再添加”。
不要强制设定无意义的Sprint目标。没有目标比虚假目标更好。
当有人完成任务时，让他们自主选择工作内容。
争取“质量Sprint”——每年至少开展一次为期2-3周的修复工作。
质疑对团队无益的做法。每日站会毫无价值？改为可选。

Hidden Costs of Custom Features

自定义功能的隐性成本

When a PM or customer asks for a one-off "special" feature, the visible cost is the development time. Three costs that almost never make it into the estimate:

Future maintenance tax — every custom feature needs to be fixed, adjusted to product changes, and kept working. This cost compounds indefinitely.
Complexity tax — every new feature makes the overall product more complex, which increases the cost of every subsequent feature.
Opportunity cost — that developer-month could have gone toward higher-impact work.

Practical responses:

Price "customer specials" significantly higher than standard features to make the true cost visible
Track what percentage of team capacity goes toward specials. Agree on a ceiling with PM/leadership
Measure actual feature usage. Features nobody uses are maintenance cost with zero return

当产品经理或客户要求开发一次性“特殊”功能时，可见成本是开发时间。但几乎从未被纳入估算的还有三项成本：

未来维护税——每个自定义功能都需要修复、适配产品变更并保持可用。这项成本会无限累积。
复杂度税——每个新功能都会增加整体产品的复杂度，从而提高后续每个功能的开发成本。
机会成本——开发这个功能的时间本可以投入到更高影响力的工作中。

实用应对方法：

“客户特殊需求”的定价显著高于标准功能，以体现真实成本
追踪团队产能中用于特殊需求的比例。与产品经理/领导层商定上限
衡量功能实际使用率。无人使用的功能只会带来维护成本，却无任何回报

When the Team Can't Make a Critical Deadline

当团队无法达成关键期限时

When a hard deadline is at risk, the options most managers reach for first are the ones that work least well.

What almost never works:

Adding people — adding developers to a late project adds communication overhead and slows things down initially (Brook's Law). The one exception: adding a senior developer as a shadow/pair to an existing developer can help if done early enough.
Reducing quality — "we'll write tests after" always costs more than the time saved. It either causes post-launch fires or results in a growing unpayable quality debt.

What sometimes works:

Adding work time — genuinely warranted in a true crisis, but sets a precedent. Use sparingly.

What works best:

Reducing scope — identify what can be cut while still delivering core value. "What's the minimum we can ship that still solves the problem?" is the most important question to ask before a deadline crunch, not during.

当关键期限面临风险时，大多数经理首先想到的选项往往效果最差。

几乎无效的做法：

增加人员——给延期项目添加开发人员会增加沟通开销，初期反而会减慢进度（布鲁克斯定律）。唯一例外：在足够早的阶段添加资深开发人员作为影子/结对伙伴协助现有开发人员，可能会有所帮助。
降低质量——“以后再写测试”的做法最终付出的代价远大于节省的时间。要么导致发布后出现大量问题，要么积累无法偿还的质量债务。

有时有效的做法：

增加工作时间——仅在真正的危机中合理使用，但会开创先例。谨慎使用。

最有效的做法：

缩减范围——确定在仍能交付核心价值的前提下可削减的内容。“我们能交付的最小版本仍能解决问题吗？”是在期限危机前而非期间要问的最重要问题。

The Iron Law of Projects

项目铁律

From How Big Things Get Done (Flyvbjerg): across thousands of large projects studied, only 8.5% came in on time and on budget. This is not a project management failure — it's a structural property of how humans plan.

Why estimates are almost always wrong:

Planners anchor on best-case scenarios and uniqueness ("this project is special")
Unknown unknowns don't show up in any estimate
Complexity grows non-linearly but estimates grow linearly
Optimism bias: teams systematically underestimate duration and cost

Reference-class forecasting — the fix:

Instead of estimating from scratch ("how long will this take?"), ask: "What happened on similar projects?"

Find a set of comparable completed projects — similar scope, similar team, similar domain. Look at how long they actually took and how much they actually cost. Anchor your estimate there, then adjust for specific differences.

This sounds obvious. Almost no one does it. The instinct is to treat every project as unique and estimate bottom-up. The data says: the outside view (comparable projects) is almost always more accurate than the inside view (detailed bottom-up estimation).

Think Slow, Act Fast:

The most expensive thing in project delivery is changing course mid-execution. Flyvbjerg's principle: invest heavily in planning before committing, then execute quickly once committed.

The pattern that kills projects: starting fast before the design is settled, then encountering fundamental issues mid-way and either pivoting expensively or shipping something that doesn't work.

Practically: before green-lighting a large initiative, ask whether the design is actually resolved. "We'll figure it out as we go" is not a design. The hill concept (see "The Always Green Method") is a micro-version of the same idea: climb far enough to see the full scope before you commit.

出自《How Big Things Get Done》（Flyvbjerg）：对数千个大型项目的研究显示，只有8.5%的项目能按时按预算完成。这不是项目管理的失败——而是人类规划方式的结构性特征。

估算几乎总是错误的原因：

规划者锚定最佳场景和独特性（“这个项目很特殊”）
未知的未知因素不会出现在任何估算中
复杂度呈非线性增长，但估算呈线性增长
乐观偏差：团队系统性低估项目时长和成本

参考类预测——解决方案：

不要从零开始估算（“这需要多长时间？”），而是问：“类似项目的情况如何？”

找到一组可比较的已完成项目——范围相似、团队相似、领域相似。查看它们实际花费的时间和成本。以此为基础进行估算，再根据具体差异进行调整。

这听起来显而易见，但几乎没人这么做。本能反应是将每个项目视为独特的，进行自下而上的估算。数据表明：外部视角（可比较项目）几乎总是比内部视角（详细自下而上估算）更准确。

慢思考，快行动：

项目交付中最昂贵的事情是中途改变方向。Flyvbjerg的原则：在承诺前大力投入规划，承诺后快速执行。

导致项目失败的模式：在设计确定前快速启动，中途遇到根本性问题，要么昂贵地调整方向，要么交付无法正常工作的产品。

实践建议：在批准大型举措前，确认设计是否真的已确定。“我们边做边想”不是设计。Hill概念（见“Always Green方法”）是同一理念的微缩版：在承诺前爬到足够高的位置，看清完整范围。

There Are No Technical Projects

不存在纯技术项目

Hot take worth internalizing: all projects are business projects. If an engineering team is doing something that can't be justified in business terms, they're doing it wrong.

This doesn't mean abandoning technical work. It means every technical initiative — refactors, dependency upgrades, infrastructure changes, architecture improvements — should be framed in terms of the business value it delivers.

Looks like	Is actually
Refactoring	Reducing the time it takes to ship features by N weeks
Updating dependencies	Reducing security risk and support costs
Adding tests	Reducing the frequency and cost of production incidents
Improving architecture	Enabling the team to build X, which they currently can't

The business case doesn't have to be exact — it has to be honest and visible. When technical work has no business framing, it's the first thing cut in planning. When it does, it competes on equal footing.

There's a second principle: some things just need to happen. You can't build software without tests, security, or operational support. Explain why these are necessary, but don't let "but this is really a business decision" become a reason to continuously deprioritize work that keeps the system running.

值得内化的观点：所有项目都是业务项目。 如果工程团队正在做无法用业务术语证明合理性的工作，那就是错误的。

这并不意味着放弃技术工作。而是说每个技术举措——重构、依赖升级、基础设施变更、架构改进——都应从其交付的业务价值角度进行阐述。

表面是	实际是
重构	将交付功能的时间缩短N周
更新依赖	降低安全风险和支持成本
添加测试	减少生产事故的频率和成本
改进架构	使团队能够构建当前无法实现的X功能

业务案例无需精确——只需诚实且可视化。当技术工作没有业务框架支撑时，它会在规划中最先被削减。当有业务框架支撑时，它就能与其他工作平等竞争优先级。

还有第二个原则：有些事情必须做。 没有测试、安全或运营支持，就无法构建软件。解释这些工作的必要性，但不要让“但这确实是业务决策”成为持续降优先级维护系统运行工作的理由。

Feature Factory Warning Signs

功能工厂预警信号

Signs your team is being run as a feature factory — shipping output with no measurement of outcomes:

No measurement of feature impact after shipping
Teams reshuffled between projects constantly (Team Tetris)
Success theater around "shipping" with no discussion of whether it worked
Features are never removed, even when they don't get used
Teams can't connect their work to key business or customer metrics
Retrospectives focus on process, never on whether product decisions were right

The risk is that a feature factory feels productive — lots of shipping, lots of demos — while actually delivering little business value. As EM, your job is to push for outcome measurement even when the delivery machine doesn't want to slow down.

团队被当作功能工厂运营的迹象——只关注交付产出，不衡量成果：

交付后不衡量功能影响
团队频繁在项目间重组（团队俄罗斯方块）
围绕“交付”开展成功表演，但不讨论是否有效
即使无人使用，功能也从不被移除
团队无法将工作与关键业务或客户指标关联
回顾会议聚焦流程，从不讨论产品决策是否正确

风险在于，功能工厂感觉很高效——大量交付、大量演示——但实际上几乎没有业务价值。作为工程经理，你的工作是推动成果衡量，即使交付机器不愿放慢速度。

Dive Deeper

深入学习

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read

references/sources.md

. For running a company-wide cleanup event, read

references/extended.md

如果用户询问某个框架的来源、想要阅读原文或了解本技能中任何主题的更多背景信息——请阅读

references/sources.md

。如需开展全公司范围的清理活动，请阅读

references/extended.md

。