新人要多久才能對專案有貢獻？

Sept. 06 12:12~13:38

 

不曉得鄉民們有沒有被指派過去帶新人的工作？N年前Teddy剛當上主管職的時候，對於「如何讓新人可以早點對專案產生實質的貢獻」這件事感到非常困擾。基本上在台灣很多軟體開發團隊帶新人的做法可以簡單分成以下兩種：

1. 自生自滅：新人報到之後，沒人理你，一切靠自己主動去問，自己想辦法找事情做。
2. 給你code，趕快做：另一種常見的情況是，新人報到之後主管把一堆程式碼丟給新人「負責」。這堆程式碼很可能是剛離職的「前員工」所留下來的「遺產」，或是現有團隊成員大家都不想碰觸的「地雷」。公司會給新人一段時間，短則1~2周，長到1~3個月都可能，來讓新人證明自己有能力可以接手這個爛攤子。

除非這個新人是個「正妹」，否則以「臭男生」居絕大多數的軟體業界，很難遇到會主動協助新人的同事。為什麼？因為你的同事自己都處在水深火熱之中，被指派的工作加班都做不完了，哪有時間去管新人。至於主管，很遺憾的，很多軟體團隊的主管都是由技術人員升任，他們的技術能力理論上 曾經 很強，但卻不一定知道要如何管理一個技術團隊。在大多數的情況下你的主管不是正忙於應付無聊的會議以及老闆、業務、行銷、或客戶的關切，就是埋頭在自己有興趣的技術領域。至於新人是否能適應工作內容，就請自求多福吧。

***

基本上以前Teddy也是採用「給你code，趕快做」的方式來應付新人，不過Teddy會先把程式碼的架構大致講解一次。當然，小則幾千，大則幾萬到幾十萬行的程式碼，絕不可能光靠Teddy的一張嘴就讓新人知道全部的內容。所以軟體架構講解完畢之後，會請新人先依據使用手冊（如果有的話）操作一下系統，然後在慢慢看程式碼。

之後Teddy每隔幾天下班前會「問候」一下新人，看看他的反應來 猜測 判斷是否可以丟新的功能給新人獨立開發。這樣的過程需要多久的時間真的是說不太準，遇到程度比較好的新人，可能一個月之內就可以投入寫code的行列。萬一遇到那種「千中選一」的籤王級新人，可能三個月的試用期到了都還沒進入狀況。

***

後來接觸到敏捷開發之後，Teddy發現除「自生自滅」與「給你code，趕快做」這兩個方法之外，還有兩種更有效的方式：

1. Pair programming：如果你想要成為一位大廚，把自己關在家裡讀食譜是沒有用的。最好的方式就是跟在另一位大廚身邊幫忙打打下手，近距離學習大廚的手藝。程式開發也是一樣，採用pair programming的方式是讓新人可以快速進入狀況的一種方法，也許可能是目前已知的最好方法也說不定。有人可能會認為跟新人一起pair會拖慢資深人員的進度。沒錯，一開始的確是這樣。但是如果我們關注的是「團隊的進度」而非「個別員工的進度」，那麼一開始讓新人與老人實施pair programming所減低的開發速度就不算什麼了，而且這些損失很快地可以由新人增加的生產力所彌補。此外，新人在pair programming的過程中也並非完全沒有貢獻。多一雙眼睛盯著，多多少少都會看出一些單獨開發所忽略的問題。
2. 寫自動化驗收測試：要讓新人可以有能力立即改程式的難度是挺高的，除了採用pair programming以外，另一種Teddy覺得很有效的方式就是讓新人撰寫自動化驗收測試案例。因為「驗收測試」是一種黑箱測試，所以新人可以在不了解source code的情況之下就開始動工。讓一個不了解系統的人來做測試還有另一個好處，就是很可能會找出現有開發團隊所忽略的問題。正所謂當局者迷，讓新人這個旁觀者來測試，更可提高找到問題的機會。當然這麼作也是有一些先決條件，例如新人要懂得撰寫自動化驗收測試的技巧與工具，例如使用Robot Framework、Selenium等等。

***

Teddy最短的紀錄是只花了一天的時間就讓新人對專案開始有實質的貢獻。新人報到的第一天上午接受HR的公司簡介訓練，下午先花兩個小時設定好電腦，然後Teddy再花一到兩小時把系統架構（以block diagram與design pattern的形式畫在白板上面）跟新人說明。隔天上班新人就可以認領撰寫自動化驗收測試的工作。

上述這個例子之所以會這麼順利當然是有前提的，因為這個新人是Teddy的學弟，在學校實驗室的時候Scrum、自動化測試、持續整合這些敏捷開發方法與實務做法都已經非常熟悉了，所以才有辦法在這麼短的時間之內立即對專案有所貢獻。藉由撰寫自動化驗收測試，新人也慢慢地了解到團隊所開發的系統到底長的是圓的還是扁的。這些知識提供了一個context，讓新人日後對於程式碼的理解以及更進一步有能力開發新功能提供很大的協助。

***

友藏內心獨白：這個紀錄可能很難打破了。