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. 少构建，竞争不足

核心概念： 通过刻意省略来取胜——更少的功能、更少的偏好、更少的活动部件，每个都比竞争对手做得更好。构建你自己需要的软件，并解决你深刻理解的问题。

为什么有效： 每个功能都带来永久的维护、认知和机会成本，通常只为一小部分用户服务。少构建使产品保持专注，代码库易于管理，团队保持精简。

关键见解：

• 半个产品胜过半吊子产品——做好几件事，而不是做糟很多事
• 做策展人，而不是囤积者：对好主意说不，让伟大的主意有呼吸空间
• 做小决定——大决定难以做出且难以撤销；小决定积累动力
• 竞争不足：让他们构建瑞士军刀，而你构建牛排刀
• 专注于不会改变的东西——速度、简单性、可靠性、易用性

产品应用：

上下文	应用	示例
功能优先级	默认答案是不	请求报告仪表板 → 提供覆盖90%用例的CSV导出
MVP范围	削减到痛，然后继续削减	为v1放弃用户账户；使用电子邮件魔法链接
竞争策略	不足，不要超越	竞争对手有50个集成；提供3个完美运行的

参见 references/build-less.md 当决定削减什么时——策展策略、约束即功能的论点，以及已完成的削减范围示例。

2. 塑形工作

核心概念： 在工作到达团队之前，一位连接产品和技术世界的高级人员使其粗糙（有回旋余地）、已解决（主要元素已确定）和有边界（范围受胃口限制）。

为什么有效： 原始想法浪费团队时间；详细规格使团队变成工单接收者。塑形移除最大的未知数，同时保留设计自由，胃口（“这值多少时间？”）取代估算（“这需要多长时间？”）——有界投资而非开放式承诺。

关键见解：

• 塑形提案有五个要素：问题、胃口、解决方案、兔子洞、禁区
• 面包板流程作为位置、功能和连接——结构无需视觉设计
• 粗马克笔草图保持高抽象；线框在概念验证之前邀请像素级反馈
• 兔子洞（范围爆炸风险）在提案中处理，而不是在构建期间
• 禁区使边界可见，防止范围蔓延在开始之前

产品应用：

上下文	应用	示例
功能设计	先面包板后模型	“邀请队友”：设置 → 邀请表单 → 发送邮件 → 接受链接 → 仪表板
范围定义	先设定胃口	“这是一个2周的胃口问题，而不是6周”塑造了哪个解决方案合适
风险管理	提前指出兔子洞	“权限可能变得复杂——v1限制为所有者/成员”

道德边界： 设定反映问题真实价值的胃口——绝不要人为地小以给团队施加压力。

参见 references/shaping-work.md 当起草提案时——五要素提案格式、已完成的示例面包板、粗马克笔规则、兔子洞模式表、好/坏禁区示例，以及6步塑形程序。

3. 投注和周期

核心概念： 用投注表取代积压和路线图：高级利益相关者将塑形提案投注到六周周期中，中间有两周冷却期。未完成的工作触发断路器——它不会自动继续。

为什么有效： 积压永远增长，创造虚假进步，稀释焦点；有限的周期槽位迫使真正的优先级排序。断路器杀死僵尸项目，冷却期防止连续冲刺的倦怠。

关键见解：

• 废除积压——如果一个想法重要，它会回来
• 六周足够长以完成有意义的工作，足够短以感受到截止日期
• 可变范围：团队削减非必要范围以赶上固定截止日期，绝不反过来
• 一次计划一个周期——长期路线图是过时的承诺
• 大多数提案不会被投注，这是健康的

产品应用：

上下文	应用	示例
路线图替代	每个周期投注	每6周3-4个塑形提案，而不是12个月路线图
风险管理	断路器杀死僵尸	第6周完成70%？它不会发布——如果仍然重要，重新塑形并重新投注
容量规划	周期之间冷却	两周用于错误、技术债务、探索、恢复

道德边界： 诚实地应用断路器——杀死僵尸，而不是政治不便的项目；重点是焦点，而不是不可持续的压力。

参见 references/betting-cycles.md 当运行投注表或规划周期时——表格如何决定、构建六周/两周节奏、应用断路器，以及反对积压的案例。

4. 小团队和执行

核心概念： 三人团队（一名设计师，一或两名程序员）自主处理塑形提案——没有站会，没有PM徘徊。他们自己发现任务并在山形图上跟踪进度。

为什么有效： 三个人可以对话；十个人需要会议。从塑形提案中发现任务的团队发展出真正的问题理解，山形图说出真相：上坡 = 仍在弄清楚，下坡 = 执行已知工作。

关键见解：

• 范围取代任务——将相关工作分组为命名的切片，在山上独立移动
• 会议有毒：改为写下来
• 真实：第2天使用真实数据的工作HTML胜过第5天的Figma模型
• 现在发布，稍后迭代——用户手中的软件胜过演示文稿中的计划
• 设计和编程从第一天起集成——没有交接阶段

产品应用：

上下文	应用	示例
团队结构	最多三人，无PM	每6周投注一名设计师+两名程序员
进度跟踪	山形图，不是燃尽图	“邀请”上坡（权限不清楚）；“电子邮件模板”下坡（执行中）
沟通	异步优先，写下来	书面更新或5分钟视频而不是30分钟会议

道德边界： 自主性要求真正可管理的范围——如果团队持续加班以赶上六周，修复塑形，而不是团队。

参见 references/small-teams-execution.md 当团队在构建中时——读取和更新山形图、切片范围、异步沟通规范，以及使用工作HTML实现真实。

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

核心概念： 伟大的软件做出选择，而不是将用户埋在偏好中——每个偏好都是团队无法或不愿做出的决定。同样的诚实适用于文案：说你的意思，跳过流行语，公开教授你所知道的。

为什么有效： 每个添加的偏好将产品分裂成更多需要设计、测试和支持的状态，并将决定推给缺乏上下文做出好决定的用户；明智的默认值减少认知负荷并创造凝聚力。清晰的文案在营销语言侵蚀信任的地方建立信任，公开教学吸引分享你价值观的客户。

关键见解：

• 选择最佳默认值并发布——只有数据显示它让大多数用户失败时才重新审视
• 本轮（修补早期功能创建的问题的功能）使复杂性复合
• “现在不行”是对好功能请求的有效、健康的回答
• 超越竞争；销售你的副产品（书籍、帖子、工具）
• 界面文案是你最好的营销——每个标签和错误消息建立或烧毁信任

产品应用：

上下文	应用	示例
功能请求	默认不，没有虚假承诺	“感谢您的建议。我们现在不计划这个。”
UI文案	平实语言	“您的文件已保存”而不是“您的资产已成功持久化到云端”
错误消息	诚实且有用	“我们无法发送该电子邮件。检查地址并重试。”
偏好	消除；选择默认值	从浏览器检测时区；提供一个好的主题
营销	诚实的定位	“Basecamp不适合所有人。这是为谁准备的，不是为谁准备的。”

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

常见错误

错误	为什么失败	修复
维护积压	永远增长；虚假进步；焦点稀释	废除它；每个周期投注塑形提案
估算而不是设定胃口	估算膨胀以填满时间并邀请谈判	问“这个问题值多少时间？”
塑形前像素完美模型	太具体太早；邀请自行车棚效应	先面包板和粗马克笔草图
延长六周周期	僵尸项目教团队截止日期是假的	断路器：未完成意味着不发布
添加偏好而不是决定	为少数用户增加所有用户的复杂性	选择最佳默认值并发布
每日站会和状态会议	打断制造者流程；报告开销	山形图用于可见性；异步更新
对好的功能请求说是	好功能仍然增加非必要复杂性	默认不；只投注这个周期重要的事
提前规划多个周期	过时的承诺降低响应能力	一次计划一个周期

快速诊断

问题	如果否	行动
这项工作有固定时间约束吗？	范围无限扩展	先设定六周（或更小）的胃口
工作是否已塑形（粗糙、已解决、有边界）？	范围问题在构建中浮出水面	定义问题、胃口、解决方案、兔子洞、禁区
2-3人的团队能做这个吗？	太大	分解为独立的六周投注
这个周期至少对5件事说了不？	构建太多	在投注表上无情削减
团队是否在弄清楚自己的任务？	微观管理；团队未被授权	交接塑形提案，而不是任务列表
使用山形图跟踪进度？	虚假精确掩盖不确定性	切换到上坡（弄清楚）与下坡（执行）
这个周期后有冷却期吗？	倦怠；没有清理时间	在周期之间安排两个非结构化周
软件在这里有明确意见吗？	决定通过偏好推迟给用户	选择最佳默认值；移除设置

参见 references/case-studies.md 获取端到端的工作场景，当你想遵循一个模型时——采用Shape Up、抵制功能蔓延、用山形图取代状态会议。

进一步阅读

• 《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的创造者，从Basecamp的代码库中提取；他们一起写了《Getting Real》、《Rework》、《Remote》和《It Doesn't Have to Be Crazy at Work》。Ryan Singer 在37signals从事产品塑形超过15年，并在《Shape Up》中编纂了方法论。