当你想减少过度构建、用小团队和固定周期更快交付产品时，用…

适用于想以固定时间、灵活范围、小团队和减法式产品策略来减少积压、裁剪范围并更快发布有价值软件的团队。

适用场景

解决思路

1. 采纳核心原则：构建更少；通过减法而非加法取胜；把简单当作目的地，而不是起点。
2. 用约束创造好工作：固定六周、三人团队和一个 shaped pitch，迫使自己找到本质版本。
3. 对产品计划、功能范围和团队流程按 37signals 原则进行 0-10 评分，并报告当前分数以及达到 10/10 所需的具体改变。
4. 评分 9-10 时定义为：固定时间周期、shaped pitches、小团队、无 backlog、有主见的默认值、清晰文案。
5. 评分 7-8 时定义为：多数工作已 shaped 且团队小，但存在一些范围蔓延或流程开销。
6. 评分 5-6 时定义为：有一些 shaping，但 backlog 持续存在、团队过大，或用偏好代替决策。
7. 评分 3-4 时定义为：重流程（standups、sprints、story points）但仅有偶尔的简化努力。
8. 评分 0-2 时定义为：功能工厂，长期路线图、大团队、估算仪式且没有 shaping。
9. Build less：通过刻意省略取胜——更少功能、更少偏好、更少活动部件，并让每个保留项都比竞争对手做得更好。
10. Build less：构建你自己需要的软件，并解决你深度理解的问题。
11. Build less：做半个产品，而不是半成品——把少数事情做好，而不是把许多事情做差。
12. Build less：做策展人而不是囤积者——对好点子说不，让伟大点子有空间。
13. Build less：做微小决策——大决策难做且难逆，小决策能建立动力。
14. Build less：弱化竞争——让对手做瑞士军刀，你做牛排刀。
15. Build less：聚焦不会变的东西——速度、简单、可靠、易用。
16. 功能优先排序时默认回答不；例如有人要求报表仪表盘时，先交付覆盖 90% 用例的 CSV export。
17. MVP 范围裁剪时一直砍到痛，再砍更多；例如 v1 去掉用户账号，用 email magic links。
18. 竞争策略采用弱化竞争而不是超越竞争；例如竞争对手有 50 个集成时，你只交付 3 个完美可用的集成。
19. 参考 references/build-less.md 决定该砍什么，包括策展战术、把约束当功能、以及范围裁剪示例。
20. Shaping：在工作到达团队前，由连接产品与技术的高级人员把工作塑造得 rough、solved、bounded。
21. Shaping：用 appetite（这个问题值多少时间）替代 estimate（要花多久），做有界投入而不是开放式承诺。
22. Shaping：让 shaped pitch 包含五个元素：problem、appetite、solution、rabbit holes、no-gos。
23. Shaping：用 breadboard 表达流程，将其表示为 places、affordances、connections，只做结构不做视觉设计。
24. Shaping：用 fat marker sketch 保持高抽象；在概念验证前不要用 wireframes 引发像素级反馈。
25. Shaping：在 pitch 中处理 rabbit holes（导致范围爆炸的风险），不要留到构建时。
26. Shaping：用 no-gos 让边界可见，在范围蔓延开始前阻止它。
27. 功能设计时先 breadboard 再 mockup；示例：Invite teammate 流程为 Settings → invite form → email sent → accept link → dashboard。
28. 范围定义时先设 appetite；例如把它定义为 2 周 appetite 的问题，而不是 6 周问题，这决定哪个方案合适。
29. 风险管理时提前指出 rabbit holes；例如权限可能变复杂，v1 限制为 owner/member。
30. Shaping 的道德边界：设置反映问题真实价值的 appetite，绝不人为设小来施压团队。
31. 参考 references/shaping-work.md 起草 pitch，包括五元素格式、breadboard 示例、fat marker 规则、rabbit-hole 模式表、no-go 正反例和六步 shaping 流程。
32. Betting：用 betting table 取代 backlog 和 roadmap；高级利益相关者把 shaped pitches 下注进六周周期，中间隔两周 cool-down。
33. Betting：未完成工作触发 circuit breaker，不自动继续。
34. Betting：废除 backlog；如果点子重要，它会回来。
35. Betting：把六周设为长到能做有意义工作、短到能感受截止日期的周期。
36. Betting：采用可变范围；团队裁剪非必要范围以赶上固定截止日期，绝不反过来。
37. Betting：一次只规划一个周期；长期路线图是过时承诺。
38. Betting：接受多数 pitch 不会获得下注，这是健康的。
39. 路线图替代：每个周期下注；每 6 周下注 3-4 个 shaped pitches，而不是维护 12 个月路线图。
40. 风险管理：用 circuit breaker 杀死僵尸项目；第 6 周完成 70% 也不发布，如果仍重要就重新 shaping 并重新下注。
41. 产能规划：周期之间安排 cool-down；用两周做 bug、技术债、探索和恢复。
42. Betting 的道德边界：诚实应用 circuit breaker 来杀死僵尸项目，而不是政治不便项目；重点是聚焦，不是不可持续压力。
43. 参考 references/betting-cycles.md 运行 betting table 或规划周期，包括下注桌如何决定、六周/两周节奏、circuit breaker 和反 backlog 论证。
44. Small teams：用三人团队（一名设计师、一名或两名程序员）自主完成一个 shaped pitch，不设 standups，也不让 PM 盯人。
45. Small teams：让团队自己发现任务，并用 hill charts 跟踪进度。
46. Small teams：用 scopes 取代 tasks；把相关工作分组为命名切片，让它们在 hill 上独立移动。
47. Small teams：认为会议有毒，写下来代替。
48. Small teams：Get real，第 2 天有真实数据的 working HTML 胜过第 5 天的 Figma mockup。
49. Small teams：现在发布，之后迭代；软件到用户手里胜过 deck 里的计划。
50. Small teams：设计与编程从第一天集成，不设交接阶段。
51. 团队结构：最多三人，无 PM；每个 6 周 bet 配一名设计师加两名程序员。
52. 进度跟踪：用 hill charts 而不是 burndowns；例如 Invitations 处于 uphill（权限不清），Email templates 处于 downhill（执行中）。
53. 沟通：async-first，写下来；用书面更新或 5 分钟视频代替 30 分钟会议。
54. Small teams 的道德边界：自主需要真正可控范围；如果团队持续加班才能达到六周，修 shaping，不是修团队。
55. 参考 references/small-teams-execution.md 在团队构建中阅读和更新 hill charts、切分 scopes、建立 async 沟通规范和用 working HTML get real。
56. Opinionated software：让软件做选择，而不是把用户埋在偏好里；每个偏好都是团队未能或不愿做的决定。
57. Opinionated software：文案同样诚实，说你的意思，跳过 buzzwords，公开教你知道的。
58. Opinionated software：选最佳默认值并发布；仅在数据表明它对多数用户失败时才重新考虑。
59. Opinionated software：消除 epicycles，即用功能修补早期功能造成的问题，避免复杂度复利。
60. Opinionated software：把 Not now 作为对好功能请求的有效且健康回答。
61. Opinionated software：Out-teach competition；出售副产品，如书、文章、工具。
62. Opinionated software：把 interface copy 当作最好的营销；每个标签和错误消息都在建立或烧毁信任。
63. 功能请求：默认不，不虚假承诺；例如回复：Thanks for the suggestion. We're not planning this right now。
64. UI 文案：用平实语言；例如用 Your file is saved，而不是 Your asset has been successfully persisted to the cloud。
65. 错误消息：诚实且有帮助；例如：We couldn't send that email. Check the address and try again。
66. 偏好：消除偏好并选择默认值；例如从浏览器检测 timezone，只发布一个好主题。
67. 营销：诚实定位；例如：Basecamp is not for everyone. Here's who it's for and who it's not for。
68. 参考 references/opinionated-software.md 回应功能请求或移除设置，参考 references/ux-ui-copy.md 写界面文案、空状态或错误消息。
69. 避免常见错误：不要维护 backlog，改为每个周期对 shaped pitches 下注。
70. 避免常见错误：不要估算，改为设置 appetite，问这个问题值多少时间。
71. 避免常见错误：不要在 shaping 前做 pixel-perfect mockups，先做 breadboards 和 fat marker sketches。
72. 避免常见错误：不要延长六周周期，使用 circuit breaker，未完成即未发布。
73. 避免常见错误：不要添加偏好代替决策，选最佳默认并发布。
74. 避免常见错误：不要用 daily standups 和状态会议，改用 hill charts 提供可见性并用 async updates。
75. 避免常见错误：不要对好功能请求说 yes，默认 no，只对本周期重要的事下注。
76. 避免常见错误：不要提前规划多个周期，一次只规划一个周期。
77. 快速诊断行动：如果没有固定时间约束，先设置六周或更小的 appetite，防止范围无限扩张。
78. 快速诊断行动：如果工作没有 shaped，定义 problem、appetite、solution、rabbit holes、no-gos，防止构建中才暴露范围问题。
79. 快速诊断行动：如果 2-3 人做不了，拆成独立的六周 bets。
80. 快速诊断行动：如果本周期对至少 5 件事说了不，继续；否则在 betting table 上狠砍。
81. 快速诊断行动：如果团队不能自己发现任务，要交付 shaped pitches，而不是任务清单。
82. 快速诊断行动：如果没用 hill charts 跟踪进度，切换到 uphill（还在弄明白）和 downhill（正在执行），避免虚假精确掩盖不确定性。
83. 快速诊断行动：如果本周期后没有 cool-down，安排两个非结构化周，避免倦怠并留出清理时间。
84. 快速诊断行动：如果软件在这里没有清晰观点，选最佳默认并移除设置，避免把决策推给用户。
85. 参考 references/case-studies.md 获取端到端示例：采用 Shape Up、抵抗功能蔓延、用 hill charts 替代状态会议。
86. 进一步阅读：Getting Real、Rework、Shape Up、It Doesn't Have to Be Crazy at Work、Remote。

适用边界 · 注意事项

• 当目标是对 MVP 做验证时，改用 lean-startup。
• 当目标是运行设计冲刺时，改用 design-sprint。
• 当组织要求长期路线图、大型多团队协调或严格契约式估算时，不适合直接套用。