37signals-way
熱門使用 37signals 哲學（來自《Getting Real》、《Rework》和《Shape Up》）打造精實、有主見的產品。當使用者提到「Getting Real」、「Rework」、「Shape Up」、「37signals」、「Basecamp 方法」、「六週週期」、「固定時間、彈性範圍」、「胃口 vs 估算」、「下注桌」、「麵包板」、「粗頭筆草圖」、「做得更少」、「低於競爭對手」、「有主見的軟體」、「我們有太多會議」、「我們如何更快交付」或「停止過度建置」時使用。當為了更快交付而縮減範圍、經營小團隊或避免長期路線圖時也觸發。涵蓋塑形、下注、建置，以及說不的藝術。如需 MVP 驗證，請參閱 lean-startup。如需設計衝刺，請參閱 design-sprint。
使用 37signals 哲學（來自《Getting Real》、《Rework》和《Shape Up》）打造精實、有主見的產品。當使用者提到「Getting Real」、「Rework」、「Shape Up」、「37signals」、「Basecamp 方法」、「六週週期」、「固定時間、彈性範圍」、「胃口 vs 估算」、「下注桌」、「麵包板」、「粗頭筆草圖」、「做得更少」、「低於競爭對手」、「有主見的軟體」、「我們有太多會議」、「我們如何更快交付」或「停止過度建置」時使用。當為了更快交付而縮減範圍、經營小團隊或避免長期路線圖時也觸發。涵蓋塑形、下注、建置，以及說不的藝術。如需 MVP 驗證，請參閱 lean-startup。如需設計衝刺，請參閱 design-sprint。
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. 塑形工作
核心概念： 在工作到達團隊之前，一位連結產品與技術世界的高階人員將其塑形為粗略（有操作空間）、已解決（主要元素已釐清）且有界限（範圍受胃口限制）。
為什麼有效： 原始點子浪費團隊時間；詳細規格讓團隊變成接單員。塑形移除最大的未知數，同時保留設計自由，而胃口（「這個問題值多少時間？」）取代估算（「這需要多久？」）——有界限的投資取代無止境的承諾。
關鍵見解：
- 塑形提案有五個元素：問題、胃口、解決方案、兔子洞、禁止事項
- 麵包板流程以位置、功能和連結呈現——有結構但無視覺設計
- 粗頭筆草圖保持高抽象；線框圖在概念驗證前就引來像素級回饋
- 兔子洞（範圍爆炸的風險）在提案中處理，而不是在開發中
- 禁止事項讓界限可見，在範圍蔓延開始前就防止它
產品應用：
| 情境 | 應用 | 範例 |
|---|---|---|
| 功能設計 | 先麵包板，後模型 | 「邀請隊友」：設定 → 邀請表單 → 寄出電子郵件 → 接受連結 → 儀表板 |
| 範圍定義 | 先設定胃口 | 「這是兩週胃口的問題，不是六週」決定哪個解決方案合適 |
| 風險管理 | 事先指出兔子洞 | 「權限可能變複雜——v1 限制為擁有者/成員」 |
道德界限： 設定反映問題真實價值的胃口——絕不人為縮小來施壓團隊。
當起草提案時，請參閱 references/shaping-work.md——五元素提案格式、實際麵包板、粗頭筆規則、兔子洞模式表、好/壞禁止事項範例，以及六步驟塑形程序。
3. 下注與週期
核心概念： 用下注桌取代待辦清單和路線圖：高階利害關係人將塑形提案下注到六週週期，中間穿插兩週的冷卻期。未完成的工作觸發斷路器——不會自動繼續。
為什麼有效： 待辦清單永遠增長、製造虛假進度、稀釋焦點；有限的週期名額強迫真正的優先排序。斷路器殺死殭屍專案，冷卻期防止連續衝刺的倦怠。
關鍵見解：
- 廢除待辦清單——如果點子重要，它會回來
- 六週夠長做有意義的工作，夠短感受截止期限
- 彈性範圍：團隊刪除非必要範圍以達成固定截止期限，絕不反過來
- 一次只規劃一個週期——長期路線圖是過時的承諾
- 大多數提案不會被下注，這是健康的
產品應用：
| 情境 | 應用 | 範例 |
|---|---|---|
| 路線圖替代 | 每週期下注 | 每六週 3-4 個塑形提案，取代 12 個月路線圖 |
| 風險管理 | 斷路器殺死殭屍 | 第六週完成 70%？不交付——如果仍然重要，重新塑形並重新下注 |
| 容量規劃 | 週期之間冷卻 | 兩週處理錯誤、技術債、探索、恢復 |
道德界限： 誠實應用斷路器——殺死殭屍，而不是政治上不方便的專案；重點是專注，不是不可持續的壓力。
當執行下注桌或規劃週期時，請參閱 references/betting-cycles.md——桌子如何決定、六週/兩週節奏的結構、應用斷路器，以及反對待辦清單的論點。
4. 小團隊與執行
核心概念： 三人團隊（一位設計師、一或兩位程式設計師）自主執行塑形提案——沒有站立會議、沒有 PM 緊盯。他們自己發現任務，並用丘陵圖追蹤進度。
為什麼有效： 三個人可以對話；十個人需要會議。從塑形提案發現任務的團隊會發展出真正的問題理解，而丘陵圖說出真相：上坡 = 仍在釐清，下坡 = 執行已知工作。
關鍵見解：
- 範圍取代任務——將相關工作分組為具名切片，在丘陵上獨立移動
- 會議有毒：改用書面溝通
- 務實：第二天用真實資料的可用 HTML 勝過第五天的 Figma 模型
- 現在就推出，之後再迭代——使用者手中的軟體勝過簡報中的計畫
- 設計與程式從第一天就整合——沒有交接階段
產品應用：
| 情境 | 應用 | 範例 |
|---|---|---|
| 團隊結構 | 最多三人，無 PM | 每個六週下注一位設計師 + 兩位程式設計師 |
| 進度追蹤 | 丘陵圖，不是燃盡圖 | 「邀請」上坡（權限不明）；「電子郵件範本」下坡（執行中） |
| 溝通 | 非同步優先，寫下來 | 書面更新或 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" by Jason Fried & David Heinemeier Hansson
- "Rework" by Jason Fried & David Heinemeier Hansson
- "Shape Up: Stop Running in Circles and Ship Work that Matters" by Ryan Singer
- "It Doesn't Have to Be Crazy at Work" by Jason Fried & David Heinemeier Hansson
- "Remote: Office Not Required" by 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》中將方法論系統化。
