Back to Details

scope-cutting

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Cut scope by flipping the question. Instead of "How long will this take?" ask "How much time is this problem WORTH?" Set the appetite first, then shape the solution to fit. This is Shape Up's core insight: fixed time, variable scope.
通过转换问题的方式来裁剪范围。不要问「这需要多长时间？」，而是问「解决这个问题值得投入多少时间？」。先设定时间意愿（Appetite），再调整解决方案以适配这个时间。这是Shape Up的核心理念：固定时间，可变范围。

Set the Appetite

设定时间意愿（Appetite）

Before touching scope, declare the time budget:
  • Small batch: 1-2 weeks for 1-2 people
  • Big batch: 6 weeks max for a small team
If a project takes more than 6 weeks (or 3 weeks for 1-3 people per Linear's method), it's too big. Break it down or walk away.
The appetite is NOT an estimate. An estimate says "this will take X." An appetite says "this is WORTH X." If the shaped solution doesn't fit the appetite, cut scope until it does — or kill the project.
在调整范围之前，先明确时间预算：
  • 小批次： 1-2人投入1-2周时间
  • 大批次： 小型团队最多投入6周时间
如果一个项目需要超过6周时间（或者按照Linear方法，1-3人投入超过3周），那它的规模就过大了。需要拆分项目或放弃该项目。
时间意愿（Appetite）不是预估。预估是指「这需要X时间」，而时间意愿是指「解决这个问题值得投入X时间」。如果调整后的解决方案无法适配这个时间意愿，就持续裁剪范围直到适配——或者终止项目。

Scope Hammering

范围打磨

For every item in the spec, ask these questions in order:
  1. Must-have or nice-to-have? If the feature ships without it and users still get value, it's nice-to-have. Cut it.
  2. Shippable without it? Can you deploy a working version that doesn't include this? If yes, cut it from v1.
  3. Edge case or core path? If fewer than 20% of users will encounter this scenario, defer it.
  4. Compare to baseline. The baseline is NO feature — not the ideal version. "Is this better than nothing?" always wins over "Is this as good as it could be?"
针对需求规格中的每一项，依次问自己以下问题：
  1. 是必备功能还是锦上添花的功能？ 如果去掉该功能后，产品交付给用户仍能带来价值，那它就是锦上添花的功能，应当裁剪掉。
  2. 没有它能否交付？ 你能否部署一个不包含该功能的可用版本？如果可以，就从v1版本中裁剪掉它。
  3. 是边缘场景还是核心路径？ 如果只有不到20%的用户会遇到该场景，就推迟实现它。
  4. 与基准对比。 基准是「没有该功能」——而非理想版本。「有它是否比没有好？」的优先级永远高于「它是否能做到尽善尽美？」

Shape the Solution Down

逐步精简解决方案

When scope is still too big after hammering:
  • Cut breadth, not quality. Support 1 auth provider well instead of 3 badly. Handle the happy path completely instead of covering every error state.
  • Remove entire surfaces. Kill the settings page. Remove the dashboard. Ship with sensible defaults instead of configurability.
  • Time-bound the edge cases. "We'll handle CSV import of up to 1,000 rows. Above that, they email us." Solve it manually until scale demands automation.
  • Ask: "What's the simplest version a customer would thank us for?" That's your scope.
如果经过打磨后范围仍然过大：
  • 裁剪广度，而非降低质量。 把一个身份验证提供商的支持做精，而非粗糙地支持三个。完整处理核心流程，而非覆盖所有错误状态。
  • 移除整个功能模块。 砍掉设置页面，移除仪表盘。提供合理的默认配置，而非让用户自行配置。
  • 给边缘场景设定时间限制。 比如「我们支持最多1000行的CSV导入，超过这个数量的话，用户可以发邮件给我们」。在规模要求自动化之前，手动解决这类问题。
  • 问自己：「客户会为哪个最简单的版本而感谢我们？」 那就是你的项目范围。

Circuit Breaker (Shape Up)

熔断机制（Shape Up）

If it doesn't ship in one cycle, it's cancelled by default. No automatic rollover. The team must re-pitch for another cycle. This prevents zombie projects that drag on forever.
如果项目在一个周期内无法交付，默认直接取消。不自动延续到下一个周期。团队必须重新申请下一个周期的资源。这可以防止项目变成「僵尸项目」，无休止地拖延。

Guidelines

指导原则

  • CRITICAL: NEVER cut quality — cut BREADTH. A polished feature that does one thing > a buggy feature that does five.
  • NEVER estimate. Set appetite. "This is worth 2 weeks" not "This will take 2 weeks."
  • NEVER let v1 have more than 5 must-haves. If it does, you haven't scoped hard enough.
  • ALWAYS compare to baseline (no feature at all), not to the ideal implementation.
  • ALWAYS ask "What can we ship in [appetite]?" not "How long until we ship everything?"
  • NEVER carry work over automatically. Unfinished work must be re-pitched.
Built on Shape Up (Basecamp) and the Linear Method. Skills from productskills.
  • 关键原则：绝对不要降低质量——要裁剪的是广度。一个打磨精良、只做一件事的功能，远胜于一个bug百出、做五件事的功能。
  • 绝对不要做预估，而是设定时间意愿。应该说「这个项目值得投入2周时间」，而非「这个项目需要2周时间」。
  • 绝对不要让v1版本的必备功能超过5个。如果超过了，说明你对范围的裁剪还不够彻底。
  • 始终与基准（没有该功能）对比，而非与理想实现对比。
  • 始终问「在[时间意愿]内我们能交付什么？」，而非「我们要多久才能交付所有内容？」
  • 绝对不要自动延续未完成的工作。未完成的工作必须重新申请资源。
基于Basecamp的Shape Up方法和Linear方法构建。技能来自productskills。