開發者到職通常是用新人訓練花了幾天來衡量的，而那是問題的另一頭。真正重要的數字是另一個：一位新來的工程師要過多久，才能改動某個東西，而且有把握自己沒有弄壞別的地方。在大多數團隊裡，這個數字是以月計算的，而不是以天計算的。

延遲很少出在人身上。它出在系統裡有多少部分只存在於別人的腦袋裡，以及前兩週裡有多大一部分時間，是靠一次次打斷別人，一點一點把這些東西挖出來的。

唯一值得追蹤的指標：從到職到他們的第一次改動進入正式環境，需要多久。 不是第一次提交，提交可以只是改一個錯字，而是一次有意義而且真正上線的改動。如果這個時間超過一週，障礙幾乎從來都不是能力。而是一份最近沒有人從零走過一遍的環境建置流程，或者一份沒有人帶路就找不到入口的程式碼庫。

開發者到職正在和什麼爭奪資源

一共有三筆成本，其中只有一筆是新人自己的時間。

他們的時間，這是看得見的一筆，也是所有人都在最佳化的一筆。團隊的時間，因為每一個問題都會打斷某個正在做別的事的人，而這一筆比第一筆更大。還有那些始終沒被問出口的問題的成本：新工程師寧願自己猜，也不想在一個上午裡第五次去打擾別人，而這一猜錯得很隱蔽，兩個月後才浮出水面。

好的到職流程真正消除的，正是第三筆。寫文件之所以值得，不是因為讀比問更快，而是因為它讓人可以在晚上十一點自己查清楚，不必先掂量再問一次的人情成本。而那些問不出口的問題，恰恰最容易埋下隱患，因為它們從來不會出現在任何一次站立會議上。

先把環境修好

決定第一週成色的最大單一因素，是這個專案能不能在一台乾淨的機器上、不靠任何人幫忙就跑起來。

團隊總是低估這一點，因為每個人都已經有一套能用的環境，而且兩年來沒人重建過。與此同時，那份建置文件指向的版本早就往前走了，漏掉了去年春天某人加進來的環境變數，還預設新人擁有某個服務的存取權限，而那個權限從來沒有給過他。資料庫的初始資料一個字也沒寫，寫文件的人自己也想不起來為什麼只有他本機上有。

補救辦法並不體面。讓下一位到職的人嚴格照著文件走，一個字都不改，把每一處失敗都記下來。那張清單才是你真正的建置流程。更好的做法是把它壓縮成一道指令，一道指令就產出一套帶著可用測試資料、已經跑起來的系統，因為每一個手動步驟都是一個遲早會走樣的步驟。清單上的每一條最好變成儲存庫裡的一次提交，而不是又一頁寫在內部文件平台上、下一個人同樣讀不到的說明。

權限也是環境的一部分。一個人拿到了程式碼，卻沒有儲存庫權限、沒有測試環境的憑證、沒有任務追蹤系統，他就還沒有準備好開工。請在到職日之前把帳號準備好，而不是在第一個早上才發現破洞。一次權限申請卡在忙碌的核准者那裡、整整一天就沒了，這種事一點都不少見。

立刻給一件真正的任務

想讓新人先躲開真實工作兩週，這份好意會起反效果。沒有目的地讀程式碼庫，學到的東西非常有限，因為讀到的內容沒有可以掛靠的地方。

相反地，在第二天或第三天交給他一個小的、真實的、可以發布的改動，就等於把整條交付路徑教了一遍：程式碼在哪裡，測試怎麼跑，審查怎麼走，部署怎麼發生，以及該通知誰。新工程師最需要的正是這條路徑，而最不可能被寫在任何地方的也正是這條路徑。

要挑一件真的有使用者在等的事，不要編一個練習題。人是分得出來的，而這個差別決定了他們會不會認真看待回饋。第一次審查要盡快給出，讓第一個改動掛上兩天，等於在教一條你並不想教的、關於團隊優先順序的道理。

然後陪著他一起做。在懂這套系統的人旁邊坐一個小時，傳遞的東西比讀一整天還多，而陪著的那個人通常也會重新發現一些關於自家程式碼庫的事。結對時讓新人握著鍵盤、講解的人只動嘴，這樣學到的是操作，而不是旁觀。

什麼該寫下來，什麼不該

文件會腐壞，所以只寫那些能一直成立、而且值回維護成本的內容。

值得寫： 怎麼建置與啟動系統，怎麼部署，架構是什麼形狀以及為什麼是這個形狀，那些不寫下來就會被反覆重新爭論的決定，還有誰負責什麼。我們關於技術文件的指南更詳細地討論了維護這個問題。

不值得寫： 程式碼已經說清楚的一切，對每個月都在變的畫面做的一步步導覽，以及手工維護的完整API參考。這類內容過期得最快，誤導性也最強。

在多數團隊裡，價值最高的一份文件是一頁簡短的架構概覽，說明大的元件有哪些、為什麼被拆開。它花掉一個下午，很少需要改，卻回答了每位新工程師用第一週自己拼湊出來的那個問題。配一張圖會更好，而當那張圖開始不準時，通常說明是設計本身動了。把重要決定連同當時的取捨記成一小段決策紀錄，也比事後再解釋便宜得多。

到職是一場對團隊的考試

新人卡住的每一件事，都是團隊一直在無聲吸收的東西。

如果建置環境要花三天，這筆成本一直都在，只是被每一個重灌過機器的人以小額分攤掉了。如果沒有人說得清某個元件為什麼存在，這份含糊早就在悄悄消耗決策品質。如果部署流程離不開某個特定的人，這份相依本來就是風險，而它也正是在技術盡職調查和任何一份像樣的復原計畫裡會浮出來的同一個風險。

所以把最初幾週當成一次免費稽核。請新人把所有讓他困惑的地方記成一張清單，並且把這張清單當作待辦事項來讀，而不是當作對他能力的評價。那是任何人能寫出的、關於你這套系統最誠實的描述，因為再過兩個月，他也會不再注意到這些了。這張清單最好在第一個月結束前收走，再晚就只剩下已經被習慣蓋住的那一部分了。

Mecanik 會作為軟體開發工作的一部分，經常加入既有的程式碼庫，也就是說我們是靠著替別人的系統做這場考試為生的。上手快的團隊並不是文件最好的團隊，而是最近有人重建過自己的環境、並且把過程中弄壞的地方修好了的團隊。

常見問題

開發者到職應該花多長時間？ 要衡量的是第一次有意義的改動進入正式環境所需的時間，而不是新人訓練的長度。如果超過一週，障礙很少是能力。通常是一份最近沒有人從零走過一遍的環境建置流程，或者一份沒有人帶路就找不到入口的程式碼庫。

新開發者頭幾天應該做什麼？ 做一個小的、真實的、可以發布的改動，而且真的有使用者在等它。沒有目的地讀程式碼庫學不到什麼，因為沒有可以掛靠的地方；而一次真實的改動會教會他程式碼在哪裡、測試怎麼跑、審查怎麼走、部署怎麼發生，以及該通知誰。

為什麼建置開發環境要花這麼久？ 因為每個人都已經有一套能用的，而且很多年沒人從零建過，文件就這樣慢慢走樣了。補救辦法是讓下一位到職的人嚴格照著走、一個字都不改，並把每一次失敗都記下來。那張清單才是真正的流程，把它壓縮成一道指令就不會再走樣。

為了到職，哪些文件值得維護？ 怎麼建置與啟動系統、怎麼部署、架構是什麼形狀以及為什麼，那些不寫下來就會被重新爭論的決定，還有誰負責什麼。程式碼已經說清楚的內容、每月都在變的畫面導覽、手寫的API參考，都可以跳過。

到職緩慢說明團隊存在什麼問題？ 說明團隊一直無聲吸收的那些成本是真實存在的。三天的環境建置，一直由每個重灌過機器的人小額分攤。沒有人能為其辯護的元件，早就在消耗決策品質。只有一個人能執行的部署，在新人到來之前就已經是風險。