最近，有位朋友跟我討論了他的新創公司中的一些問題。這喚起了我塵封已久的一些類似經驗。

我曾經多次在我過去任職的公司內，負責建立公司的新軟體研發團隊或是新的軟體研發部門。這當中有新創公司，也有中大型的知名上市公司。地點有的在台灣，有的在中國上海。既然記憶被喚醒了，就趁這個機會好好地整理一番。

要建立一個軟體研發團隊，你要問自己三個問題。

1. 首先，這個團隊需要具備什麼樣職能的軟體工程師，才能成功打造出我的產品？

2. 其次，我有多少預算可以用在雇用這個團隊 (不包含設備儀器)？

3. 最後，綜合前述兩個問題的答案，問自己：「我要找的團隊，資深與資淺成員的比例該如何配置，團隊才能順利運作？」

這個團隊需要什麼樣職能的軟體工程師，才能成功打造出我的產品？

在回答這個問題之前，其實你需要先確定產品的定位策略為何？例如，是使用Linux還是Windows作為產品運行的平台？還是兩者都要支援？這影響了後續開發工具的選擇策略。

如果選擇了Linux做為產品的運行平台，那麼使用開源 (open source) 相關工具和程式庫 (libraries) 可能是較好的選擇。但若是選擇Windows做為產品的運行平台，則使用微軟的Visual Studio.NET和其支援的程式設計語言，可能更為有效率。

同樣的，如果產品需要附加資料庫系統，那麼不僅要考慮團隊對該資料庫系統的技術掌握能力，還可能要同時考慮到產品的售價，以及產品上線後，資料庫膨脹的速度和規模。另外，後續的支援服務等因素也很重要。

上述這些問題的答案，決定了你要找的開發團隊應該具備那些技能與知識，才能將產品順利打造出來，後續也才有能力維護。

我有多少預算可以用在雇用這個團隊？

我的經驗當中，有的公司會直接告訴你，你可以找幾個工程師，至於這些工程師會需要多少預算，等你找到人再說。而有些公司的做法則是，只給你預算，人數你自己決定。

不論是哪一種預算法，你最好把它轉換成一種虛擬的概念：「我能雇用多少生產力」。

資深的工程師往往比較有經驗，照道理說，應該比較有生產力，可是一定比較貴。而資淺的工程師經驗通常是較為不足，需要較多的教育訓練，還有，比較長的學習曲線/時間。雖然資淺人員的生產力因此可能較低，但通常也比較便宜。

那到底該如何配置資深與資淺人員的比例，才能讓團隊運作順暢呢？有沒有又便宜，又具備高生產力的雙贏策略呢？

資深與資淺成員的比例該如何配置，團隊才能順利運作？

其實，這沒有標準答案 (廢話)。

如果預算有限，無法讓我的整個團隊都配置為資深工程師，那我的做法會是，先找一個資深的工程師進來，再找二到三位資淺的工程師進來。接著，再找下個資深工程師進來，再找二到三位資淺的工程師進來。以此類推。這樣做有以下的幾個理由。

1. 好人才出現的時機永遠不會如你所預期。

往往是你想要的時候，沒有出現。一旦你找到人了之後，好人才的履歷才突然出現在你手上。為了因應這種現象，我通常不會把人找齊 (就是把headcount用盡)。而是先找齊一輪資深與資淺人員，配置成為一個可以開工的小團隊。例如，一定要先找到一位資深工程師，才能再找進來其他的資淺工程師加入他的小團隊。剩下的headcount再慢慢消化，等待有能的有緣人出現。

2. 先有了一個資深工程師的加入，你的團隊就開始有人可以規劃和架設開發環境、研讀需求和技術文件、制定前期的程式架構、制定團隊合作的工作守則等。這些都是整個團隊可以開工的重要基礎工作。

例如，程式碼版本管控系統 (source code control system) 的架設、每日程式碼整合產出待測產品系統 (daily build server) 的架設、瑕疵追蹤系統 (bug tracking system) 的架設、產品的程式主架構設計 (該有那些子系統、子系統該有哪些物件、物件該用何種design pattern、物件之間的互動模型等) ，以及程式碼的命名規則、撰寫風格/慣例 (coding style/convention) 等。 

3. 有資深工程師在，就不必擔心後續聘雇進來的資淺人員沒有人指導他們，搞得團隊人愈多，效率反而愈差，流程反而愈亂。

也許你會問那為何是二到三位資淺人員就配置一位資深人員呢？不能更多資淺人員配一位資深人員嗎？

根據我的經驗和觀察，通常一位資深工程師能同時帶領兩位資淺工程師就已經是非常拚了。因為，資深工程師除了自己的工作之外，還得扮演好管理者 (lead) 和導師 (mentor) 的角色。而後者將會耗費掉這位資深人員大量的時間和精力。

比方說，資深人員需要提供資淺人員教育訓練。例如，如何使用開發環境、有那些規矩要遵守等。資深人員也需要協助資淺人員快速融入團隊和公司。資深人員需要review資淺人員撰寫的程式碼，查看這些程式碼是否有符合團隊的coding style，讓團隊成員都看得懂他人寫的程式，方便維護。資深人員更需要透過code review來為程式碼的品質把關，揪出那些因為思慮欠周而潛藏的嚴重bug。像最常見，也最耗費團隊精力處理的隨機當機 (random crash) 和記憶體流失 (memory leak) 等問題。

有了這樣的策略，團隊就可以在一邊建立的過程當中，一邊型塑團隊的紀律和文化。團隊經理將能有更多的時間，好好地為團隊獵才。

本文轉貼自：威廉網紙（原文連結）