🦄 獨角獸專案

🎯 什麼情境該想到我

當你想診斷「為什麼團隊/開發者做事這麼卡、這麼不快樂」，或想改善工程文化與生產力時。用這五面向逐一檢視。

⚙️ 怎麼用（五個檢視面向，各附可量測的判準）

1. 局部性與簡單性：能不能在自己範圍內完成事情，不用層層等別人？系統與流程夠簡單嗎？
   • 範圍不只是程式碼：組織與決策也要有局部性——小決策不該層層上呈。書中對這個病灶的稱呼是「廣場（The Square）」：要找隔壁的工程師合作，得往上兩層、橫過兩層、再往下兩層。
   • 原則：「外部世界已經夠複雜了，我們絕不能容許複雜跑進自己能控制的東西裡——無論是程式碼、組織還是流程。」
   • 📏 可量測：實作一個功能平均要動用幾個團隊？（書中抽樣是 4.2 個，很多要跟 8 個以上團隊互動——「要跟八個團隊協作的人不可能完成任何事」。）
2. 專注、心流與愉悅：開發者能不能不被打斷地進入心流？部署是小而頻繁還是大而痛苦？
   • 反面長什麼樣：無聊、等別人做完、只看得到整體的一小塊、只有在部署爆炸時才看到自己工作的結果，接著是救火、懲罰與燃燒殆盡。
   • 📏 可量測：改完一行程式到顧客能用，要多久？員工滿意度分數——書中 Parts Unlimited 的分數是業界數一數二的高，唯獨 IT 部門是 -27，而那正是負責公司最重要專案的部門。
3. 改善日常工作：有沒有留時間還技術債、改善流程？（改善工作 > 工作本身）
   • 正面的行為定義是 Andon cord：任何人遇到問題都被期待隨時求助，即使得停下整條產線；而且他會因此被感謝——因為那是改善日常工作的機會。
   • 反面是 TWWADI（The Way We’ve Always Done It，我們一向都這樣做）。書中列出的清單可以直接拿去對照自家流程：僵化的專案計畫、缺乏彈性的採購流程、強勢的架構審查委員會、稀疏的發布排程、冗長的審批流程、嚴格的職責分離——每一項都在墊高協調成本與延遲成本。
4. 心理安全感：出事時大家敢說真話嗎？（見 工具-心理安全感）
   • 因果鏈：解決問題需要預防，預防需要誠實，誠實需要沒有恐懼。
5. 顧客至上：做的每件事是否真的替顧客創造價值，而非只顧內部指標？
   • 📏 原話式檢驗（比「有沒有價值」銳利得多）：

     “are they willing to pay us for it or is it only of value to our functional silo?”
     （顧客願意為它付錢嗎，還是它只對我們這個部門本身有價值？）

   • 書中把它落地成一個制度：所有總監級以上主管每年兩次到門市當第一線員工。

哪一項最弱，就是你最該下手改善的地方。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 五者相互支撐；只做表面工具（CI/CD）卻無心理安全與改善時間，仍走不遠。
• 有落地順序：Erik 說得很明白——還技術債能幫你實現第一、第二理想，但幾乎肯定得先掌握第三理想（改善日常工作）。少了「把改善本身變成日常」這個能力，前兩個理想是拿不到的。
• 看看最好的工程師被放在哪一層：科技巨頭把最強的工程師放在「開發者日常生產力」這個底層，讓每個開發者都受益；而書中的公司把最強的人全放在最上層做功能，底層只有實習生。這是一個很快的診斷。
• 引用出處要注意：五大理想的正式定義出現在書中 Erik 於酒吧的那段講述；書末附錄只列了五個名稱、沒有定義。只看附錄會漏掉每個理想真正的內涵。

🔗 相關工具

• 工具-心理安全感 —— 第四個理想的細節卡，也是其他理想能不能落地的前提
• 工具-技術債功能凍結 —— 第三理想「改善日常工作」的一次性重手段：用有期限的功能凍結，把還債從口號變成排程
• 工具-核心與語境盤點 —— 第五理想「顧客至上」在投資決策層的展開：顧客願不願意付錢，決定哪些系統該留、哪些該交出去
• 工具-資料民主化 —— 第一理想「局部性」在資料層的落地：團隊不必開單等別人，就能拿到自己需要的資料
• 工具-三步工作法 —— 互補框架：五大理想診斷「開發者為什麼不快樂」，三步工作法處理「流程為什麼慢」
• 工具-降低在製品WIP —— 對應第二個理想「專注、心流與愉悅」的具體手段：WIP 不降就不會有心流

🎯 什麼情境該想到我

當「技術債已經讓交付速度掉一個數量級、每個人都知道該停下來整理，但功能永遠排在前面」時。
這張卡回答的是最難的那部分：怎麼真的喊得動停、停多久、停下來的時候到底做什麼。

⚙️ 怎麼用（書中的 Project Inversion）

1. 先算出痛的數字，別用形容詞。書中 Kirsten 抽樣統計：實作一個功能平均要動用 4.2 個團隊、很多要跟 8 個以上團隊互動；同一級別的功能兩年前只要 2–4 週，現在要 20–40 週。有這種數字才談得動。
2. 設明確且短的期限——書中是 30 天。不是「這一季有空就做」，是有終點的全力衝刺。
3. 要一份高層具名的正式備忘錄，而且功能與部署同時凍結（緊急變更除外）。書中 Chris 的信原文：

   “Effective immediately, as part of Project Inversion, there will be a feature freeze for the Phoenix Project. We will make a maximum effort for thirty days to increase the stability and reliability of Phoenix, as well as all supporting systems.”

4. 用一個問題產出清單：「如果有人給我們授權、而且一個月內資源無限，我們會做什麼？」書中當場列出的答案很值得抄——
   • 每個開發者用共用的建置環境
   • 每個開發者都有持續建置與整合系統撐著
   • 每個人都能在類生產環境跑自己的程式
   • 用自動化測試套件取代手動測試，把 QA 的人釋放去做更高價值的事
   • 解耦架構，讓功能團隊能各自獨立交付
   • 團隊需要的資料都用好用的 API 提供
5. 保護約束點上的那個人，要保護到近乎誇張。書中 Brent 被移出 pager 輪值、退出所有郵件列表、關掉所有聊天室通知、不准接電話，連故障會議都不准去，去了就開除；另外指派專人替他擋掉所有email與電話。目的不是特權，是確保他不把時間浪費在不該他做的事上。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• 書中寫明的失敗模式：頭一週會被拿去吵範圍，而且多數團隊照常在做功能。所以「發了備忘錄」不等於「凍結生效」，要真的去查。
• 一定會有人政治性反彈。書中 Sarah 的說法是「這些閒著的開發者正在危及公司對顧客和華爾街的承諾」——要預期這種攻擊並準備好回應。
• 這是一次性的 stand-down，不是「每週固定還債時段」。書中並沒有講後者，別把兩者混為一談。
• 適用前提是債已經大到讓正常交付停擺。債還可控時，用日常的持續改善處理更划算。

🔗 相關工具

• 工具-五大理想 —— 上位診斷框架：功能凍結是把第三理想「改善日常工作」從口號變成排程的一次性手段
• 工具-找出並管理約束點 —— 凍結期間的核心動作：把資源集中到約束點，並用近乎極端的手段保護它不被打斷
• 工具-部署管線與持續交付 —— 凍結期間清單上最常見的一批工程投資：共用建置環境、CI、類生產環境、自動化測試
• 工具-降低在製品WIP —— 同一招在專案層級的版本：《鳳凰專案》的「專案全面凍結 → 分批解凍」跟這裡的功能凍結是同一個思路

🎯 什麼情境該想到我

當團隊「沒人敢提壞消息、沒人敢反對、出事都在掩蓋、不敢嘗試新東西」時。

⚙️ 怎麼用

1. 讓「說出問題」有好結果：主管帶頭承認自己的錯與不知道，示範脆弱是安全的。
2. 對事不對人：把失敗當系統問題檢討（見 工具-無指責事後檢討），不獵巫。
3. 鼓勵發問與異議：明確歡迎「這裡我不懂」「我覺得這樣有風險」。
4. 獎勵揭露而非隱藏：把「及早暴露問題」當英雄行為，而非扣分。
5. 允許有邊界的實驗與失敗：小範圍試錯、從中學習。

它是 工具-五大理想 的第四理想，也是一切改善文化的地基。因果鏈是：解決問題需要預防，預防需要誠實，而誠實需要沒有恐懼。

📋 開場白：可以直接照唸的一段話

書中 Kurt 主持事後檢討時，逐字宣讀 Norm Kerth 的 Agile Prime Directive 當開場：

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

（無論我們發現什麼，我們理解並真心相信：在當時所知的資訊、各自的技能與能力、可用的資源、以及當下的處境之下，每個人都已經盡了自己最大的努力。）

搭配的會議規則：

• 唯一禁令：不准說「我早該做 X」或「如果我早知道，我就會做 Y」。後見之明永遠是完美的；危機當下我們從來不真的知道發生了什麼事，而且未來還會再次同樣無知。
• 先拼時間軸，再談改善。主持人事先備好生產環境的遙測、日誌與聊天紀錄，當作討論的客觀骨架。
• 目的是讓最靠近問題的人說出他當時看到了什麼，好讓系統更安全。
• 產出是一份「立刻要改的 5 件事」。

⚡ 最重要的一件事：宣告沒有用，要有人先示範

書中 Kurt 用力宣示過「不要害怕開口」之後，全場依然鴉雀無聲——連自己人都不敢講。
真正破冰的是有人先示範脆弱：Brent 脫口而出「對不起，都是我的錯」，接著 Maxine 主動自嘲當時「嚇到剉褲子」，全場笑了，人才開始講真話。

→ 建立安全感的第一個動作不是宣布規則，是自己先當那個示範的人。

🏛 把它變成制度，而不是口號

書中的類比來自 Alcoa 的 Paul O’Neill——把「安全」變成不可協商的前提：

“Safety is a precondition of work.”（安全是工作的前提。）

具體制度：每一起工傷都必須在 24 小時內直接回報給執行長，並附上改善計畫。
換到軟體場景，等價的設計是「每次事故 24 小時內直達最高層，且必須附改善計畫」——重點不是懲罰，是讓最高層無法假裝沒看見。

另外，書中把事後檢討開放全公司旁聽（即使沒有停機也照開），後來這些場次成了公司裡「學到最新最有趣東西最快的管道」，來的人多到會議室坐不下。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 心理安全 ≠ 沒有標準/放任；它是「敢說真話」的安全，不是「不用負責」。
  ⚠️ 誠實說明：書中並沒有正面討論「哪些行為不該免責」這條界線，這句是我自己的補充，別當成書中主張。
• 它流失得非常容易：主管一開始微管理、說不出「我不知道」、或擺出萬事通的傲慢姿態，安全感就沒了。而且不只主管——同儕的行為同樣會摧毀它。
• 反例值得記住：書中 Chad 連續四晚加班（怕拖累別人的進度），疲勞之下把指令打到錯的終端視窗，弄垮大半系統，隔天就被開除。這是究責文化的完整標本：它同時懲罰了「過勞」和「誠實」，然後保證下次沒有人會說實話。
• 每一次事故都是一次學習機會，用 John Allspaw 的話說：

  “every incident is a learning opportunity, an unplanned investment that was made without our consent.”
  （每一起事故都是一次學習機會——一筆未經我們同意就已經付出的投資。）
  既然錢都付了，不把學習拿走才是真的浪費。

🔗 相關工具

• 工具-五大理想 —— 心理安全感是其中第四理想；跳過去看它在整套工程文化診斷框架的位置，以及其他四項要一起看什麼
• 工具-無指責事後檢討 —— 把「對事不對人」落地成一套會議流程，是建立安全感最可操作、最快見效的一步
• 工具-徹底誠實 —— 個人層面的同一件事：團隊要的是敢說真話的環境，個人要的是不對重要事實說謊

🎯 什麼情境該想到我

當「所有人都在等中央資料團隊／整合團隊」、拿一份資料要開單等好幾個月、
或資料明明存在卻沒人說得準它是什麼意思時。

⚙️ 怎麼用

1. 先把等待清單攤出來當證據。書中 Promotions 團隊的實況：整合團隊說要 6–9 個月、還在等資料倉儲修正錯誤、還在等一個新的資料庫實例——痛點列清楚了，才推得動架構改變。

2. 把資料的所有權推回最懂它的人。核心主張：

   「清理、匯入、分析、把正確資料發布給組織其他部門的責任，應該推進每一個業務與應用團隊，因為他們最清楚這些資料實際上是什麼意思。」

   中央團隊當了幾十年資料的保管人；現在要做的是解放它，讓任何想要的人隨時取用，不必開單。

3. 但安全性不能各團隊各自為政。平台團隊保留這幾件事的統一責任：資料安全、不該存的 PII 就不要存、靜態加密，以及評估資料外洩對公司的風險。這是刻意的集中，不是漏掉的。

4. 把資料轉換當程式碼管：轉換納入版本控制、建自動化測試，在資料入庫之前先確認它的形狀與大小是對的。這是防「資料意外」最有效的一招。

5. 先做最小切片，用託管服務降低營運風險。書中的取捨：從最關鍵的能力開始、沿用既有的 ETL 成果、採用雲端上成熟的託管資料平台服務、把最重的事件串流平台先延後。

6. 預先處理政治。原本的資料保管團隊會覺得被威脅，而且那不是無理取鬧——要在動手前就去談，別讓它變成事後的政治戰。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• 「民主化」不等於「無政府」。安全、PII、加密這條線必須集中，否則你只是把一個瓶頸換成 N 個資安漏洞。
• 所有權推回團隊的前提是那些團隊真的懂自己的資料語意。如果資料的意義本來就沒人清楚，先做的是釐清語意，不是搬家。
• 這是組織層面的存取權與所有權設計，跟技術上的「怎麼觀測系統」是兩回事。

🔗 相關工具

• 工具-遙測與監控 —— 別搞混：那張是系統可觀測性（我的服務現在健不健康），這張是組織層面的資料所有權與取用權
• 工具-五大理想 —— 這是第一理想「局部性與簡單性」在資料層的落地：團隊不必層層等待別人才能拿到自己需要的東西
• 工具-技術債功能凍結 —— 常見的觸發點：凍結期列出的「團隊需要的資料都用好用的 API 提供」，展開來就是這張卡

🎯 什麼情境該想到我

當團隊被一堆「很重要但顧客不會為它付錢」的系統拖死、
或你要決定「哪些東西該自己做、哪些該買現成的、哪些該直接淘汰」時。

⚙️ 怎麼用

1. 先分清楚 Core 與 Context（Geoffrey Moore 的架構，書中由 Erik 引入）：
   • Core（核心）＝組織的中心競爭力，顧客願意為它付錢、投資人會獎勵它。
   • Context（語境）＝其餘全部。員工餐廳、班車，以及公司要運轉所必須做的成千上萬件事。它們常常是任務關鍵的（HR、薪資、email 都是），但顧客不會因為你的薪資系統做得好而付你錢。
2. 記住這句判準：

   “Not properly managing Context is what Sensei Moore called the killing ground of great companies. Companies who become too burdened by Context are unable to properly invest in Core.”
   （沒有好好管理 Context，是偉大公司的屠宰場；被 Context 壓垮的公司，沒有餘力投資 Core。）

3. 用三個問題逐項盤點你管的每個系統與服務：
   • 顧客願意為哪一個付錢給我們？
   • 哪一個真正強化了競爭優勢？
   • 哪一個可以交給廠商？
4. 白板上把候選一項項列出來，並且當場算帳：每砍掉一項能釋出幾個人、每年省多少錢、替代方案要花多少。書中盤點出的清單包括中階財務系統、員工餐廳 POS、helpdesk、email、Lotus Notes、多套重複的 ERP、HR 系統、業務獎金與薪酬規劃工具。
5. 把釋出的人「重新雇回來」到 Core。這是全套做法的關鍵——書中共盤出 18 個可裁撤的職位、替代軟體服務年費 50 萬美元；同時創新方向若獲得 500 萬美元全額投資，可以在 Core 創造 33 個技術職缺，也就是釋出的人全部能被雇回來做更有價值的事。
6. 重要的 Context 也要敢交出去。書中 Maxine 主動提議把自己維護六年、連 Erik 都稱讚是「架構奇蹟」的 MRP 系統大部分外包，只留五個人做轉換——但她同時挺身替那些人背書，要求把他們安置到 Core 與創新方向。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• Context ≠ 不重要。Context 常常是任務關鍵的，一停公司就垮；判準是「顧客願不願意付錢」，不是「重不重要」。
• Clay Christensen 的補充判準：留下「還不夠好」的（因為那裡還有差異化空間），外包「已經好過頭」的。
• 這是組合層級的取捨，不是個人層級的工具。沒有預算與人力調度權時，這張卡的用途是幫你看懂上面為什麼那樣決定，以及替自己的系統爭取正確的定位。
• Erik 也警告過：別在瘦身時砍掉那些維持工作流動的中階管理者，那會傷到 Core 的產出能力。

🔗 相關工具

• 工具-三地平線與創新賭注治理 —— 直接配套：這張決定「從哪裡把資源挖出來」，那張決定「挖出來的資源投到哪個時間軸」
• 工具-五大理想 —— 判準的來源：「顧客願不願意為它付錢」正是第五理想「顧客至上」的原話式檢驗
• 工具-把業務目標接到IT風險 —— 互補視角：這張問「哪些系統值得留」，那張問「留下來的系統壞掉會傷到哪個業務目標」

🎯 什麼情境該想到我

當「既有的金牛業務吃光所有資源、任何探索型的新嘗試都排不進去」、
或你需要一套規則來決定「這個新方向要續投、加碼，還是砍掉」時。

⚙️ 怎麼用

1. 把投資分成三個地平線（Geoffrey Moore 的架構，書中由 Erik 引入）：

   • H1：今天的獲利引擎，成熟、可預測。
   • H2：已被驗證、正在規模化的業務。
   • H3：探索期。這裡玩的是「學習速度」和「夠廣的點子池」，不是營收。

2. H3 只問三種風險，而且要用原型盡快回答：

   “the name of the game is to prototype ideas and to answer as quickly as possible the three questions of market risk, technical risk, and business model risk: Does the idea solve a real customer need? Is it technically feasible? And is there a financially feasible engine of growth? If the answer is no to any of them, it’s time to pivot or kill the idea.”

   —— 市場風險（真的解決顧客需求嗎）、技術風險（做得出來嗎）、商業模式風險（有沒有財務上可行的成長引擎）。任一個答案是否，就轉向或砍掉。

3. 每個案子要有明確的業務成果指標，而且是顧客導向的：顧客獲取、回購使用、顧客滿意度——不是產出了幾個功能。

4. 季度複審，只有四個選項（這是整套機制的心臟）：

   • 續投
   • 砍掉，把團隊重新指派到下一個最好的點子
   • 加碼
   • 畢業到 H2

   同時決定整個計畫本身該擴大還是縮小。

5. 蒐集點子要跨出技術部門。書中的做法：組一個 50 人的創新委員會，成員是全公司最受敬重的人——包含門市店長、業務主管、技師、工程師，當然還有技術部門；每案 10 分鐘 pitch，全員投票。

6. 業務與技術「同框共治」：新方向由一位業務主管與一位技術主管在組織圖上佔同一個位置，共同對業務成果與技術成果負責。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• 書中最重要的警告：H1 與 H3 天生衝突。

  “Left unchecked, Horizon 1 leaders will consume all the resources of the company.”

  H1 的人會（正確地）說自己是公司的命脈——但那只在短期為真。想要成長，就必須刻意保護 H2 和 H3。

• 這是主管層級的資源配置機制，需要編制與預算權。沒有職權時，這張卡的用途是幫你看懂資源為什麼那樣分配，以及替自己的探索型工作找到正確的說法與指標。

• 「砍掉」必須是真的會發生的選項，否則季度複審只是儀式。書中兩輪跑下來確實砍掉了一個、加碼了一個。

• 對 H3 用 H1 的指標（營收、投資報酬率）是最常見的誤用——H3 的產出是學習。

🔗 相關工具

• 工具-核心與語境盤點 —— 直接配套：那張決定「從哪裡把資源挖出來」（砍掉 Context），這張決定「挖出來投到哪個地平線」
• 工具-五大理想 —— 判準同源：H3 的「真的解決顧客需求嗎」就是第五理想「顧客至上」在投資決策層的版本