37signals-way

37signals 产品开发框架

一种打造盈利软件的体系，避免臃肿、官僚作风和过劳，精华源自三本书：Getting Real（少做）、Rework（默认说不）和 Shape Up（固定时间，灵活范围）。用它来规划工作、以六周为一个周期进行押注、组建小型自主团队，并按可预测的节奏交付。

核心原则

少做。 最好的产品功能更少，却能把每件事都做到极致——简单是目的地，而不是起点。传统开发只会不断添加；37signals 的做法则是做减法：打造半个产品（而不是半吊子产品），默认说不，固定时间、灵活范围。约束才能让优秀的工作成为可能——六周、三个人，加上经过梳理的方案，能迫使你找到最精简的版本。

评分

目标：10/10。 根据这些原则，对产品计划、功能范围和团队流程按 0-10 分评分。报告当前得分，以及达到 10/10 所需的具体改进。

• 9-10： 固定周期、经过梳理的方案、小团队、没有待办列表、有主见的默认设置、文案清晰
• 7-8： 工作和团队大多经过梳理且规模较小，但有些范围蔓延或流程负担
• 5-6： 有些工作经过梳理，但待办列表依然存在、团队过大，或用偏好取代决策
• 3-4： 流程繁重（站会、冲刺、故事点），偶尔尝试简化
• 0-2： 功能工厂：长期路线图、大型团队、估算仪式、从不梳理工作

1. 少做，做得比竞争对手少

核心概念： 通过有意舍弃来取胜——功能更少、偏好更少、活动部件更少，而且每一项都比竞争对手做得更好。打造自己需要的软件，解决自己深入了解的问题。

为何有效： 每项功能都会持续带来维护成本、认知成本和机会成本，而受益的通常只是一小部分用户。少做能让产品保持专注、代码库易于管理、团队规模精简。

关键见解：

• 半个产品胜过半吊子产品——少做几件事，但都做好，而不是做很多事，却件件做不好
• 做策展人，而不是囤积者：拒绝好点子，让伟大的点子得以施展
• 做小决策——大决策难以做出，也难以撤回；小决策能积蓄势头
• 做得比竞争对手少：让他们打造瑞士军刀，而你打造牛排刀
• 专注于不会改变的东西——速度、简单、可靠、易用

产品应用：

场景	应用	示例
功能优先级排序	默认答案是否定的	有人要求提供报告仪表板 → 发布 CSV 导出，覆盖 90% 的使用场景
MVP 范围界定	精简到难以割舍，然后再继续精简	v1 暂不提供用户账户；使用电子邮件魔法链接
竞争策略	做得少，而非做得更多	竞争对手有 50 个集成；发布 3 个运行完美的集成

决定删减什么时，请参阅 references/build-less.md——其中介绍了策展技巧、将约束视为功能的论据，以及范围削减实例。

2. 塑造工作

核心概念： 在工作交给团队之前，由一位兼具产品和技术视野的资深人员对其进行粗略构思（留有调整空间）、完善构思（理清主要要素）并划定边界（根据投入意愿限制范围）。

为何有效： 未成形的想法会浪费团队时间；过于详细的规格说明则会让团队沦为任务执行者。塑造工作能消除最大的不确定性，同时保留设计自由；投入意愿（“这件事值得花多少时间？”）取代工期估算（“这要花多长时间？”），以有边界的投入代替无限期承诺。

关键见解：

• 一份塑造完善的提案包含五个要素：问题、投入意愿、解决方案、潜在陷阱、明确不做的事项
• 用地点、可操作项和连接来绘制面包板流程——展现结构，不涉及视觉设计
• 用粗记号笔绘图可保持较高抽象程度；线框图则会在概念得到验证之前引来像素级反馈
• 潜在陷阱（可能导致范围膨胀的风险）应在提案中处理，而不是等到开发过程中再处理
• 明确不做的事项能让边界清晰可见，在范围蔓延开始之前加以防止

产品应用：

场景	应用	示例
功能设计	先画面包板，再做模型	“邀请队友”：设置 → 邀请表单 → 发送电子邮件 → 点击接受链接 → 控制面板
范围定义	先设定投入意愿	“这是一个投入意愿为 2 周的问题，而不是 6 周的问题”，以此决定适合哪种解决方案
风险管理	提前指出潜在陷阱	“权限可能会变得复杂——v1 仅限所有者/成员”

伦理边界： 设定的投入意愿应体现问题的真实价值，绝不能刻意压低，以此向团队施压。

起草提案时，请参阅 references/shaping-work.md——其中包含五要素提案格式、一份完整的面包板示例、粗记号笔绘图规则、潜在陷阱模式表、明确不做事项的正反示例，以及 6 步塑造流程。

3. 押注与周期

核心概念： 用押注表取代待办事项列表和路线图：资深利益相关者将塑造完善的提案押入 6 周周期，周期之间间隔 2 周冷却期。未完成的工作会触发断路器，不会自动延续。

为何有效： 待办事项列表会无限增长，营造虚假的进展，并分散注意力；有限的周期名额能迫使团队真正做出优先级取舍。断路器会终止僵尸项目，而冷却期则能避免持续冲刺造成的倦怠。

关键见解：

• 废除待办事项列表——重要的想法会再次出现
• 6 周足以完成有意义的工作，也足够短，能让人感受到截止日期的压力
• 范围可变：团队会削减非必要范围以赶上固定截止日期，绝不反过来延长截止日期
• 一次只规划一个周期——长期路线图很快就会变成过时的承诺
• 大多数提案不会被押注，这是健康的做法

产品应用：

场景	应用	示例
替代路线图	每个周期都进行押注	每 6 周押注 3-4 份塑造完善的提案，而不是制定 12 个月路线图
风险管理	用断路器终止僵尸项目	到第 6 周完成了 70%？不予发布——如果仍然重要，就重新塑造并再次押注
容量规划	在周期之间设置冷却期	用 2 周处理缺陷、技术债务、探索工作和恢复

伦理边界： 诚实地使用断路器来终止僵尸项目，而不是终止在政治上不方便的项目；重点在于聚焦，而不是施加不可持续的压力。

运行押注表或规划周期时，请参阅 references/betting-cycles.md——其中介绍押注表如何做出决定、如何安排 6 周/2 周的节奏、如何使用断路器，以及反对待办事项列表的理由。

4. 小团队与执行

核心概念： 由三人组成的团队（一名设计师、一到两名程序员）可以自主推进经过明确规划的提案——无需每日站会，也没有项目经理在一旁监督。他们自行发现任务，并通过 hill chart 跟踪进度。

有效原因： 三个人可以直接交流；十个人则需要开会。团队从经过明确规划的提案中发现任务，能真正理解问题；hill chart 则如实反映进度：上坡 = 仍在摸索，下坡 = 正在执行已知工作。

关键见解：

• 用范围取代任务——把相关工作归为有名称的切片，让它们在 hill chart 上各自独立推进
• 会议有害：不如把内容写下来
• 务实一些：第 2 天拿出使用真实数据的可运行 HTML，胜过第 5 天做出 Figma 模型
• 现在就发布，之后再迭代——让软件交到用户手中，胜过把计划放在演示文稿里
• 设计与编程从第一天起就结合起来——不要设置交接阶段

产品应用：

情境	应用	示例
团队结构	最多三人，不设项目经理	每个为期 6 周的项目由一名设计师 + 两名程序员组成
进度跟踪	使用 hill chart，而非燃尽图	“邀请”还在上坡（权限尚不明确）；“电子邮件模板”已下坡（正在执行）
沟通	异步优先，把内容写下来	用书面更新或 5 分钟视频代替 30 分钟会议

伦理边界： 自主工作需要真正可控的范围——如果团队总是加班才能赶上 6 周期限，就应该改进规划，而不是责怪团队。

当团队正在开发时，请参阅 references/small-teams-execution.md，了解如何阅读和更新 hill chart、拆分范围、建立异步沟通规范，以及通过可运行的 HTML 务实推进。

5. 有主见的软件与清晰沟通

核心概念： 出色的软件会替用户做出选择，而不是用各种偏好设置淹没用户——每一项偏好设置，都是团队本可以或不愿替用户做出的决定。文案也应秉持同样的坦诚：有话直说，避免行话，公开分享所知。

有效原因： 每增加一项偏好设置，产品就会多出更多需要设计、测试和支持的状态，还会把决定推给缺乏相关背景、难以做出正确选择的用户；合理的默认选项能减轻认知负担并增强一致性。清晰的文案能建立信任，而营销套话会侵蚀信任；公开分享知识，则能吸引价值观相同的客户。

关键见解：

• 选择最佳默认设置并发布——只有数据表明它对大多数用户都不适用时，才重新审视
• 叠床架屋的功能（用来修补早期功能所造成问题的功能）会不断累积复杂性
• 对合理的功能请求回答“现在不行”，完全有效且健康
• 在知识分享上胜过竞争对手；销售由此产生的成果（书籍、文章、工具）
• 界面文案是最好的营销——每个标签和错误消息都在建立或消耗信任

产品应用：

情境	应用	示例
功能请求	默认拒绝，不做虚假承诺	“感谢你的建议。我们目前没有计划实现这个功能。”
UI 文案	使用简单明了的语言	“你的文件已保存”，而不是“你的资源已成功持久化到云端”
错误消息	坦诚且有帮助	“我们无法发送这封电子邮件。请检查地址后重试。”
偏好设置	删除设置；选择默认值	根据浏览器检测时区；只提供一个出色的主题
营销	坦诚定位	“Basecamp 并非适合所有人。以下是它适合和不适合的人群。”

回应功能请求或移除设置时，请参阅 references/opinionated-software.md；编写界面文案、空状态或错误消息时，请参阅 references/ux-ui-copy.md。

常见错误

错误	失败原因	修正方法
维护待办列表	越积越多；制造虚假的进展感；分散注意力	取消待办列表；每个周期都押注于经过梳理的提案
估算时间，而不是设定投入时间	估算会膨胀到填满可用时间，还会引发讨价还价	询问“这个问题值得投入多少时间？”
梳理前就制作像素级精细的模型	太早过于具体；容易引发无休止的细节争论	先制作线框图和粗略草图
延长六周周期	僵尸项目会让团队觉得截止日期并不算数	设置断路器：没完成就不发布
添加偏好设置，而不是做决定	为了服务少数用户，让所有用户都承担复杂性	选定最佳默认值并发布
每日站会和状态会议	打断创作者的工作流；增加汇报负担	用进度图表展示进展；异步更新
接受不错的功能请求	不错的功能仍会增加非必要的复杂性	默认拒绝；只押注于本周期最重要的事情
提前规划多个周期	过时的承诺会降低响应能力	一次只规划一个周期

快速诊断

问题	如果否	行动
这项工作是否有固定的时间限制？	范围会无限扩大	先设定六周（或更短）的投入时间
这项工作是否经过梳理（粗略、已解决、有边界）？	范围问题会在开发过程中浮现	明确问题、投入时间、解决方案、棘手问题和禁区
2～3 人的团队能完成这项工作吗？	规模太大	拆分成独立的六周押注
本周期至少拒绝了 5 项工作吗？	做得太多了	在押注会议上果断削减
团队是否自行梳理任务？	微观管理；团队缺乏自主权	交付经过梳理的提案，而不是任务清单
是否使用进度图表追踪进展？	虚假的精确度掩盖了不确定性	改用上坡（探索问题）与下坡（执行）阶段
本周期结束后是否安排了冷静期？	精疲力尽；没有清理时间	在周期之间安排两周无固定安排的时间
软件在这个问题上是否有明确主张？	通过偏好设置把决定推给用户	选定最佳默认值；移除该设置

如果你想要参考范例，了解端到端的实际场景（采用 Shape Up、抵制功能膨胀，以及用进度图表取代状态会议），请参阅 references/case-studies.md。

延伸阅读

• "Getting Real"，作者 Jason Fried 和 David Heinemeier Hansson
• "Rework"，作者 Jason Fried 和 David Heinemeier Hansson
• "Shape Up: Stop Running in Circles and Ship Work that Matters"，作者 Ryan Singer
• "It Doesn't Have to Be Crazy at Work"，作者 Jason Fried 和 David Heinemeier Hansson
• "Remote: Office Not Required"，作者 Jason Fried 和 David Heinemeier Hansson

关于作者

Jason Fried 是 37signals（Basecamp、HEY）的联合创始人兼 CEO，也是倡导平和公司文化和产品简洁性的领军人物。David Heinemeier Hansson（DHH） 是 37signals 的联合创始人，也是 Ruby on Rails 的创作者；Ruby on Rails 源自 Basecamp 的代码库。他们共同撰写了 Getting Real、Rework、Remote 和 It Doesn't Have to Be Crazy at Work。Ryan Singer 在 37signals 负责产品塑造工作超过 15 年，并在 Shape Up 中系统总结了这套方法论。