shape-up

Shape Up

它是什么

Shape Up 是一种产品开发方法论，其核心理念是：无法靠估算来保证交付——必须通过塑造方案来实现交付。

传统方法会问“这要花多长时间？”，然后设法按估算完成。Shape Up 则反其道而行之：先决定你愿意投入多少时间（投入时限），再塑造一个能在这一限制内完成的解决方案版本。

这套方法论源于 Basecamp 17 年的开发实践。当时，创始团队面临一个不同寻常的限制：他们唯一的工程师（DHH）每周只工作 10 小时。这迫使团队必须极其明确地决定要构建什么，并严格控制范围，确保每个小时都发挥作用。随着公司发展壮大，他们将这些实践正式整理成 Shape Up，以便在扩大规模时保持创业公司的速度。

**关键转变：**从“这个要多久？”转向“在我们愿意投入的时间内，能有把握交付这个方案的哪个版本？”

适用场景

在以下情况下，可以使用 Shape Up：

• 避免项目一拖再拖——本应几周完成的工作却要花上几个月
• 摆脱估算陷阱——你厌倦了总是出错的估算
• 赋予团队真正的自主权——而不只是执行工单
• 减少会议开销——Scrum 仪式占用了太多时间
• 交付有意义的整体成果——而不只是彼此无关、加起来也没有实际价值的增量工单
• 让产品与工程保持一致——两者之间如今存在隔阂
• 保持创业公司的速度——在规模扩大到 30-50 人之后

不适用场景

在以下情况下，不要使用 Shape Up：

• 团队只有 3 人或更少——直接彼此沟通即可，还不需要正式化流程
• 工作没有真正的复杂性——简单任务不需要塑造方案
• 无法让工程师参与塑造方案——没有技术输入，塑造过程就无法奏效
• 领导层不支持——你需要高管支持，才能保障构建时间
• 只做维护工作——修复 bug 不需要完整流程

模式

展示如何正确应用 Shape Up 的详细示例。每种模式都会说明一种常见错误及其正确做法。

关键（这些地方做错了，就会白费功夫）

模式	说明
estimates-vs-appetite	别问“要多久？”——先决定你愿意投入多少时间
unshaped-work	Figma 文件或 PRD 并不等于经过塑造的工作——你需要通过协作达成明确共识
shaping-without-engineering	没有资深工程师参与塑造方案，很容易导致项目失控
ten-pound-bag	不能把 10 磅的工作范围塞进 5 磅的时间盒
fuzzy-problem	“构建一个日历”不是问题——先缩小问题范围

影响显著

模式	说明
too-abstract-shaping	用粗笔绘制的草图必须传达构想，而不只是模糊的线框图
scope-hammering	开始之前就缩减范围，不要等到时间不够时才动手
tickets-not-projects	把完整项目交给团队，而不是拆得支离破碎的工单
hill-chart-theater	爬坡图展示真实进展，而不是表演式的进度展示
missing-kickoff	构建者必须把经过塑造的工作转化为 9 个或更少的实施范围
cool-down-skipping	团队在周期之间需要喘息空间，以便重整状态

中等影响

模式	传达的经验
betting-table-dysfunction	押注是一种真正的承诺，而不是重新排列待办事项
junior-detail-dial	根据开发者的情况调整塑造细节
circuit-breaker-fear	如果行不通，就停止构建并回到塑造阶段

深入了解

仅在需要更多细节时阅读。

• references/shape-up-playbook.md：更详尽的框架说明、检查清单和示例。

资源

书籍：

• Shape Up，作者 Ryan Singer — 原版免费书籍（basecamp.com/shapeup）
• Demand-Side Sales 101，作者 Bob Moesta — 适用于框定问题／发现问题阶段
• Competing Against Luck，作者 Clayton Christensen — Jobs-to-be-Done 理论

课程：

• Shaping in Real Life — Ryan Singer 关于实践塑造的课程

其他：

• Ryan Singer 的网站：ryansinger.co
• 37signals 博客，持续分享见解

---

致谢：Shape Up 由 Ryan Singer 在 Basecamp/37signals 工作的 17 年间创立。本技能基于他的书籍和播客访谈。