新人不是來接受能力測試的，是來替你的知識系統做壓力測試的——他問的每一個問題，都是一份缺席的文件。

到職兩週的一天

昨天最後說：這些洞平常看不見，直到一個新人加入。

那就讓他加入。案例照例經過去識別化與合併改寫。

一位新進的後端工程師，到職快滿兩週的某個早上，接到一個不難的任務：改一個報表欄位，部署到測試環境。理論上，半天可以做完。

九點半，他查部署方式。Wiki 上有一頁「部署指南」，最後更新停在兩年前；照著做，第三步的指令就報錯。鄰座同事探頭過來：「喔，那頁不能信。部署要問那位資深後端，他有一份自己的筆記。」

十一點，他看懂了程式，卻看不懂資料：要用的那個欄位，值有一到七，沒有任何說明。他問了一圈，得到的答案是：「三跟五意思一樣，但舊資料只認三。細節要問對資料庫最熟的那位，他當年參與過搬遷。」

下午兩點，功能改完了，他想順手把報表格式調整得好看一點。這次換 PM 攔住他：「那張報表有個客戶盯很緊，小數位數不能動，動了月底會出事。為什麼？說來話長，反正先不要動。」

傍晚，半天的任務用掉了一天。他的筆記本多了三行，沒有一行是技術：

部署        → 問資深後端（用他的私人筆記）
欄位語意    → 問資料庫最熟的那位（搬遷史）
客戶地雷    → 問 PM（說來話長）

每個人都很熱心，每個問題都有答案。只是沒有一個答案，存在於「某個人」以外的地方。

週會上，主管關心新人適應得如何。團隊的共識溫暖而一致：

「新人嘛，還不熟，過幾個月就好了。」

只有他自己知道：這兩週他真正在學的不是系統，是一份人肉索引——哪件事要找哪個人。他不是還不熟技術，是還沒背完通訊錄。

當時團隊怎麼理解這件事

團隊怎麼看新人的低效率？大概是這樣：新人本來就需要時間；我們的系統比較複雜，眉角很多；文件寫了也沒人看，口頭教最快；而且有問題隨時可以問，我們的文化很開放。

老樣子：每句單獨看都有道理，合在一起剛好繞開一個問題：

為什麼完成工作必要的資訊，沒有被設計成新人可以取得？

「有問題隨時可以問」聽起來是開放文化，翻譯過來是：資訊的取得方式是「知道要問誰」。

而「知道要問誰」這件事本身，也要問人。

新人不是能力測試，是壓力測試

換個角度看這兩週。

他不是在受訓，他是在對這個組織的知識系統做一次完整的壓力測試。每一個他答不出來、必須去問人的問題，都是一次命中：

部署要問人
→ 缺的是 Runbook
  （兩年前的 Wiki 不算，那是遺跡）

欄位語意要問人
→ 缺的是資料定義，也就是 Day 09 說的 Contract
  （這次連自己人都讀不懂彼此的欄位）

客戶地雷要問人
→ 缺的是 Day 11 說的 ADR
  （為什麼小數位數不能動，沒有寫在任何地方）

連「要問誰」都要問人
→ 缺的是知識的入口——任何一個入口

注意：這些洞沒有一個是新的。Day 08 到 Day 12 講過的每一種洞，這個團隊全都有。差別只有一個——老成員的腦中各自帶著一份補丁，新人沒有。

所以「大家都知道，只有我不知道」這句話，其實描述得不準。準確的版本是：

沒有任何一個地方寫著這些事。「大家」也不是都知道，只是各自背了一小塊，而且背得夠久，久到忘記這些東西從來沒有被寫下來過。

這個問題，瀑布與敏捷原本都有自己的解法。瀑布傳統會留下一整套文件——需求、設計、操作手冊——很重，但至少它誠實地假設了一件事：人會離開，人會加入。敏捷把這份重量減下來：README、ADR、自動化測試、輕量的 Runbook，Artifact 可以變薄，但「知識存在於人腦之外」這個責任沒有被取消。

而這個團隊的狀態是：重的沒有，輕的也沒有，只有熱心的同事。

從新人的位置，第一次看清楚大神們

第二部走到今天，前五篇我們都站在團隊裡面看大神：需求不清有人腦補、介面沒定有人熟、驗收沒寫有人通靈、決策沒記原作者還在、變更沒記 PM 記得。

站在裡面看，一切運作得太順了，順到看不見。

新人是第一個站在外面的人。他沒有那些記憶，所以他看到的是這套系統的素顏：

老成員眼中：部署很簡單啊，跑一下就好
新人眼中：部署需要一份只存在某人筆記裡的儀式

老成員眼中：那個欄位大家都知道意思
新人眼中：一個欄位需要一場考古訪談

老成員眼中：這客戶的規矩我們有默契
新人眼中：默契是一種我無法存取的儲存格式

所以今天的大神段落，跟前五天方向相反。前五天要費力追問「大神偷偷補了什麼」；今天不用追問了——新人的問題清單直接把答案抄了出來。他每問一次人，就是這套靠人腦運轉的系統被觀測到一次失手：平常由記憶默默供應的答案，這次必須現形，走一遍「找人、開口、打斷、口述」的明路。

換句話說，新人的問題清單，就是這個團隊的大神依賴地圖。

而多數團隊拿到這份地圖的第一個反應，是把它當成新人的成績單。

這次到底誰在吸收代價？

Scope       □   沒有人覺得該為此立什麼項
Time        □   「新人慢」被當成自然現象，不進任何時程
Cost        □
Quality     □
Risk        ■   他哪天不問、直接動手呢？月底那張報表在等他
人          ■   新人背人肉索引；被問的每一位輪流被打斷   ← 這次是一整排人

這次「人」這格特別擠。吸收代價的不只新人：資深後端每隔幾天被部署問題打斷一次、資料庫最熟的那位反覆口述同一段搬遷史、PM 一遍遍重講「說來話長」的那段長話。每一句「問一下就好」，都是一次免費的知識提領，從某個人的專注力帳戶扣款。

而且這筆帳有個殘忍的性質：下一個新人來，全部重付一次。

如果沒有大神，應該留下什麼

好消息是：該補什麼文件，不用開會討論，新人已經替你把清單列好了。

他問過的每一個問題，都附帶一份最有力的證明：這份知識被真實需要過。這比任何「文件化計畫」都精準——不用猜哪些東西值得寫，把他問過的問題收回來就好。

條件只有一個：團隊得把這份清單當成流程的檢討對象，而不是新人的成績單。

今日 Artifact｜Onboarding 缺口清單

請下一位新人（或現在就請最資淺的成員）做一件事：每次「必須問人才能繼續」，就記一行。兩週後回收：

□ 問題：我卡在＿＿＿＿，必須去問＿＿＿＿（職稱即可）
□ 次數：這個問題，歷來的新人被迫問過＿＿次
□ 落地：它應該變成＿＿＿＿
       （Runbook／欄位定義／Contract／ADR／Checklist，擇一）

排序方式很簡單：次數最多的先補。被問了五次的部署流程，比任何宏大的文件工程都值得先寫下來。

今日一句

新人問的每一個問題，都是一份缺席的文件；把它當成績單，你錯過一次修流程的機會，把它當清單，你賺到一份免費的盤點。

回頭看看第二部這六個現場：需求靠腦補、介面靠交情、驗收靠通靈、決策靠原作者、變更靠記憶、新人靠自求多福。把這些洞攤開排成一列，會浮現同一個結構。

明天，給它一個正式的名字。Day 01 埋的那個暫稱，該上台了。