整套系統只有一個人懂——當那個工程師請假,您的公司會發生什麼事？
當唯一懂系統的那個人突然請假
您的電商網站付款功能突然失效,客服電話響個不停。打開後台一看,訂單資料卡在「待處理」狀態超過兩小時,但系統沒報錯、log 也看不出問題。
您馬上想到小張——那位負責後端的工程師,他處理過類似狀況。但小張今天請事假,手機關機,人在墾丁。
團隊其他人翻遍程式碼,發現有一支叫 legacy_sync.py 的排程任務,上次修改時間是一年半前,註解只有一行:「臨時修正,之後重構」。沒有人知道它在做什麼、為什麼會影響付款、該怎麼重啟。
<cite index="3-11">這個問題在軟體工程裡有個專有名詞,叫做「bus factor」——指的是團隊中最少要失去多少人,專案就會停擺。</cite>如果答案是「一個人」,那就是最危險的狀態。
這不是技術能力的問題,而是知識分布的問題。當整套系統的關鍵知識集中在一個人腦袋裡,<cite index="2-7">無論是生病、休假,還是離職,都會讓專案陷入困境。</cite>
為什麼會變成「只有一個人懂」？
很多老闆以為這是工程師故意的——「他想讓自己變得不可取代」。但實務上,這種局面多半不是刻意造成的,而是時間壓力下的自然結果:
專案趕上線,沒時間交接。 當初為了搶在活動前上線,小張一個人熬夜趕工,寫完就直接部署了。其他人連程式碼都沒看過,更不用說知道部署流程。
系統跑得順,沒人想碰。 上線後系統穩定運作,大家覺得「既然沒壞,就不用修」。小張偶爾修個 bug、調個參數,但從來沒有第二個人需要碰這塊。
文件一直沒補。 每次出問題小張都說「我先修好,文件晚點補」,但「晚點」從來沒有到來。久而久之,連他自己都忘了當初為什麼要這樣寫。
<cite index="4-7">在許多軟體團隊中,一兩個人可能掌握了舊系統的運作邏輯、關鍵演算法,或者所有的部署知識。</cite>如果這些人離開,其他人根本無法接手。
對台灣中小企業來說,這個問題特別嚴重。<cite index="24-1">根據 104 人力銀行調查,2025 年台灣中小企業自願離職率已達 21.8%,這意味著每 5 個員工就有 1 個會在一年內離職。</cite>當您的系統只有一個人懂,而這個人隨時可能離開,風險就不是「如果」,而是「何時」的問題。
不撕破臉的知識轉移:三個實際做法
降低這種單點依賴,不是要逼工程師交出密碼、寫一堆沒人看的文件,而是要建立一套讓知識自然流動的機制。以下是三個在不破壞信任關係的前提下,可以立刻開始的做法:
1. 讓第二個人「陪同處理」,而不是「事後看文件」
<cite index="6-11,6-13">當系統出問題時,安排第二位工程師跟小張一起處理。短期內會比較慢,但三個月後,當小張休假時,第二個人已經有實際處理過問題的經驗——不是因為讀過文件,而是因為他們一起 debug 過。</cite>
這種做法的好處是:
- 不會讓小張覺得「公司在防我」
- 第二個人學到的是真實情境,不是理論
- 知識轉移發生在工作流程中,不需要額外時間
2. 建立「能跑起來」的最小部署文件
不要要求工程師寫「完整系統架構文件」,那種東西寫了也沒人看。<cite index="6-14">您需要的是一份輕量級的操作手冊,涵蓋「如何執行這個系統」和「log 檔在哪裡」這類基本資訊。</cite>
實務上,這份文件應該包含:
- 系統啟動 / 重啟的指令
- 常見錯誤訊息與對應處理方式
- 關鍵設定檔的位置與用途
- 緊急聯絡流程(例如:小張不在時該找誰)
這種文件不需要解釋「為什麼」,只要能讓系統在緊急狀況下重新跑起來就夠了。
3. 把「code review」變成日常,而不是驗收
<cite index="13-3,13-4">程式碼審查不只是抓錯,更是知識轉移的動態媒介。它讓資深工程師的經驗自然傳遞給團隊成員,同時提升整體程式碼品質。</cite>
即使團隊只有兩個工程師,也能執行最簡化的 code review:
- 小張寫完一段關鍵邏輯後,花十分鐘跟另一位同事講一遍
- 不用逐行檢查,重點是讓第二個人知道「這段程式在做什麼」
- 如果小張講不清楚,那代表這段程式碼本身可能有問題
下一步:讓系統知識不再鎖在一個人身上
當您意識到「整套系統只有一個人懂」這件事,代表風險已經存在一段時間了。但好消息是,這個問題是可以解決的,而且不需要撕破臉、不需要讓工程師覺得「公司在防我」。
關鍵在於:
- 不要等到那個人提離職才開始交接
- 不要把「寫文件」當成唯一解法
- 讓知識轉移融入日常工作流程,而不是變成額外負擔
如果您手上有一套想上線或已經上線的系統,但發現只有一個人真正了解它的運作方式,現在正是降低風險的時機。我們的免費健診服務會幫您檢視系統的知識集中度,並提供具體的風險降低建議——在那個關鍵的人離開之前。