一個軟韌體測試 Tech Lead 的自學型組織設計筆記
第8篇｜原來我早就在實踐人才發展模型
我從沒報過 L&D（Learning & Development）相關課程，
也不太知道那些理論要怎麼「正規學」。
但幾年下來，當我回頭看自己的團隊架構、文件設計、與日常互動，才發現——我們幾乎完整對應了一整套人才發展模型。
也許是因為痛點太真實：
人會走、需求會變、時間永遠不夠，但品質卻不能掉。
於是我被逼著設計出一個「不靠天才也能穩定運作」的系統。
沒想到，這套系統後來成了——
一個活生生的、實戰版的學習與發展現場。
🎯 一、Learning Design：把學習寫進流程
我沒有開課程。
但我們的每一次 code review、本地測試、錯誤修正，都是一次學習。
我設計了明確的護欄與原則，讓人可以挑戰規則，
但挑戰時必須舉證、必須整理。
每一次「辯贏 reviewer」的過程，其實都是一次學習轉化。
這不是教學，而是以行動驅動的學習。
L&D 的語言會稱這是 Learning Transfer Design，
但在我們這裡，它只是日常開發的一部分。
⚙️ 二、Knowledge Flow：讓團隊記憶變成結構
我們的模組架構幾乎可以直接 Copy & Paste。
文件、錯誤碼、觀測項、甚至回滾腳本都有統一格式。
不需要交接，因為知識從一開始就被設計成「共用」。
這就是最理想的知識流動：
知識不屬於個人，而屬於流程。
在人才發展的觀點裡，這就是一種 Learning Ecosystem（學習生態系）。
知識不是被管理，而是被流動地使用。
🧩 三、Performance Improvement：挑戰是系統成長的機制
我從不怕人挑戰制度，
因為制度被挑戰的那一刻，就是它在學習。
有人在 code review 裡推翻規則；
有人重寫模組結構。
只要說得通、能舉證、能留下記錄，
那次挑戰就會被記進 ADR，成為系統的新知識。
這正是 L&D 模型裡的 Behavior Change——
行為的改變不再是被要求的成果，
而是系統運作的副產品。
🧭 四、Change Leadership：讓制度可挑戰、但不會崩壞
我設計架構時有一條最核心的原則：
「你可以挑戰它，但你打不出它的框。」
這意味著團隊可以自由探索，但永遠不脫軌。
失敗不會造成傷害，反而讓大家更懂為什麼規則存在。
我稱這套邏輯為「反脆弱制度」：
每次挑戰都會讓系統變得更穩定。
這正是現代人才發展裡 Change Leadership 的精神——
領導不是壓制變化，而是設計出能吸收變化的結構。
🧠 五、L&D 對照
- 能力領域 : Learning Design & Delivery
我們的實踐方式 : Code Review + 模組模板 = 日常化學習場景 - 能力領域 : Learning Technologies
我們的實踐方式 : Repo、CI/CD、ADR = 學習載體 - 能力領域 : Knowledge Flow
我們的實踐方式 : 文件與規格標準化，形成團隊共享記憶 - 能力領域 : Performance Improvement
我們的實踐方式 : 透過挑戰與辯證推動行為改變 - 能力領域 : Change Leadership
我們的實踐方式 : 維持可挑戰但穩定的結構，形成反脆弱文化
💬 結語：學習不是被教出來的，是被迫長出來的
說到底，我沒有上過任何 L&D 課。
不是因為我排斥理論，
而是因為我每天都被逼著讓理論變成現實。
當系統要撐住變動、人員要快速上手、知識要自我修復，
你會發現——
那些 Learning Transfer、Knowledge Flow、Change Leadership 的概念，
根本不是「要不要學」，
而是「你撐得下去，就一定會自己長出來。」
所以我沒學過 L&D，
但我真的不小心，把團隊做成了一個學習系統。
📘 建議標題：
「我沒上過 L&D，卻意外把團隊做成學習系統」
（副標：從生存痛點到理論實踐，一個技術主管的反向修煉）
