讀完這章你要能回答：Tech Lead 同時要扮演哪幾種角色？我的專案是真的「卡住了」，還是「以為做完了其實沒上線」？
帶領一個大型專案，難的不是寫程式，而是在不確定中持續推進、在迷霧中辨認方向，並在「看起來快完成」時識破假象。
Tech Lead 的三種角色#
Tech Lead 不是一個單一職務，而是同時戴著三頂帽子，並依專案階段動態切換：
- 技術領導者：定方向、把關設計品質、做關鍵技術決策。
- 專案推進者：拆解工作、追蹤進度、管理範圍與風險。
- 團隊放大器：解除障礙、引導成長、讓每個人發揮最大效能（而非自己埋頭把活全做完）。
一個常見陷阱：Tech Lead 退化成「最強的個人貢獻者」，把難題全攬在自己身上。真正的槓桿在於讓整個團隊變強，而不是自己變忙。
推進專案的五步迴圈#
帶大型專案，本質是一個持續循環的專案管理迴圈，而不是一次性的甘特圖。
flowchart LR
A[🧩 拆解<br/>大問題切成可執行小塊] --> B[🔦 推進未知<br/>優先攻擊最不確定的部分]
B --> C[⚙️ 執行調整<br/>邊做邊校準計畫]
C --> D[📐 管理範圍變更<br/>守住核心、協商取捨]
D --> E[🛡️ premortem 收尾<br/>提前想像失敗]
E --> A
style A fill:#e3f2fd
style B fill:#fff3e0
style C fill:#fce4ec
style D fill:#fff8e1
style E fill:#e8f5e9- 拆解：把模糊的大目標切成可估算、可分派的小任務。
- 推進未知：先攻擊最不確定的部分，把風險提前暴露，而非把難題留到最後。
- 執行與調整：計畫是會變的，邊執行邊根據新資訊校準。
- 管理範圍變更：守住核心目標，對新增需求做明確的取捨協商，而非默默吸收。
- premortem 收尾：在關鍵節點前，假設「專案已經失敗」，回推可能原因並先行防堵。
premortem 怎麼做
premortem（事前驗屍）是 postmortem 的反向操作：
- 召集團隊，宣布一個前提：「想像六個月後，這個專案徹底失敗了。」
- 每個人各自寫下「它為什麼會失敗」的所有可能原因。
- 彙整這些原因，挑出風險高、可預防的，現在就採取行動。
它的價值在於：讓人們在「還能改變結果」時，安全地說出心裡的擔憂——這些擔憂在樂觀的啟動會議上往往被壓抑。
停滯診斷：三種「卡住」#
專案停滯時，先別急著加人或加班。先診斷它屬於哪一型，因為解法完全不同。
| 停滯型態 | 症狀 | 解法 |
|---|---|---|
| Blocked（被擋住） | 在等外部依賴、決策或資源 | 升級處理、找替代路徑、主動推進阻塞點 |
| Lost（迷失方向） | 不知道下一步該做什麼、目標模糊 | 回到目標、重新拆解、補上缺的資訊 |
| Arrived but not done（自以為到了） | 宣稱「做完了」但其實沒真正交付 | 用更嚴格的「完成」定義重新檢查（見下） |
最危險的是第三型。「程式碼寫完（code-complete）」不等於「部署上線（deployed）」，不等於「被使用者實際使用（used）」，更不等於「穩固運作（hardened）」。很多專案在「以為做完」的狀態下空轉，因為沒人用同一把尺衡量「完成」。
把「完成」拆成明確的階梯，能戳破這種假象：
code-complete → deployed → used → hardened
（寫完） （上線） （有人用） （穩定可靠）兩條帶人原則#
- 一個任務，一位當責人：每件事都要有單一的 owner。共享責任 = 沒人負責。當責不等於獨自完成，而是「確保這件事被完成」的那個人。
- 招募互補者，而非複製自己：刻意找與自己技能、視角互補的人，補上團隊的盲點。複製一群和自己一樣的人，只會放大同一組弱點。
本章要點#
- Tech Lead 三角色：技術領導者、專案推進者、團隊放大器，動態切換。
- 五步迴圈：拆解 → 推進未知 → 執行調整 → 管理範圍變更 → premortem 收尾。
- 先攻擊未知：把不確定性提前暴露，別把風險留到最後。
- 三種停滯：Blocked / Lost / Arrived-but-not-done，對症下藥。
- 完成有階梯：code-complete ≠ deployed ≠ used ≠ hardened。
- 帶人兩原則：一任務一當責人；招募互補者而非複製自己。