建立軟體研發團隊的策略三問

    https://www.flickr.com/photos/kishorephotography/6340343002/in/photolist-aEgV5E-nRXhpM-5nAwQM-bpJvDU-bCKzZp-8bbT2k-ecd9GD-q8AKMB-4BsLmy-cHQHxq-8vHAvg-5XJZGF-BA6oGa-4TupHc-h8vT3E-h86ZUn-cihGzJ-bpH8im-aUNSiX-8VEQLu-4xBDUH-9id953-76YRMW-etr9e-s1ac8c-rpJSvP-bpRAPU-pEetTL-qGEnu2-uoxU4J-a1K8U3-qQAUZq-5Lgd7Z-6t4FwG-cudPuG-nAPRuZ-bKLyk-dKqK6n-iVBcME-4RP6iU-jU5u9X-4wM3Cu-8FmMaN-6EXNWB-9AzWwN-i86CwA-nshCP9-92qQNV-bTcVhZ-opDtnP
    要怎麼從無到有建立軟體研發團隊?
    最近,有位朋友跟我討論了他的新創公司中的一些問題。這喚起了我塵封已久的一些類似經驗。

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

    要建立一個軟體研發團隊,你要問自己三個問題。
    1. 首先,這個團隊需要具備什麼樣職能的軟體工程師才能成功打造出我的產品?
    2. 其次,我有多少預算可以用在僱用這個團隊 (不包含設備儀器)?
    3. 最後,綜合前述兩個問題的答案,問自己:「我要找的團隊,資深與資淺成員的比例該如何配置,團隊才能順利運作?」
    這個團隊需要什麼樣職能的軟體工程師才能成功打造出我的產品?

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

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

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

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

    我有多少預算可以用在僱用這個團隊?

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

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

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

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

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

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

    如果預算有限,無法讓我的整個團隊都配置為資深工程師,那我的做法會是,先找一個資深的工程師進來,再找二到三位資淺的工程師進來。接著,再找下個資深工程師進來,再找二到三位資淺的工程師進來。餘此類推。這樣做有以下的幾個理由。
    • 好人才出現的時機永遠不會如你所預期。往往是你想要的時候,沒有出現。一旦你找到人了之後,好人才的履歷才突然出現在你手上。為了因應這種現象,我通常不會把人找齊 (就是把headcount用盡)。而是先找齊一輪資深與資淺人員,配置成為一個可以開工的小團隊。例如,一定要先找到一位資深工程師,才能再找進來其他的資淺工程師加入他的小團隊。剩下的headcount再慢慢消化,等待有能的有緣人出現。
    • 先有了一個資深工程師的加入,你的團隊就開始有人可以規劃和架設開發環境、研讀需求和技術文件、制定前期的程式架構、制定團隊合作的工作守則等。這些都是整個團隊可以開工的重要基礎工作。例如,程式碼版本管控系統 (source code control system) 的架設、每日程式碼整合產出待測產品系統 (daily build server) 的架設、瑕疵追蹤系統 (bug tracking system) 的架設、產品的程式主架構設計 (該有那些子系統、子系統該有哪些物件、物件該用何種design pattern、物件之間的互動模型等) ,以及程式碼的命名規則、撰寫風格/慣例 (coding style/convention) 等。 
    • 有資深工程師在,就不必擔心後續聘雇進來的資淺人員沒有人指導他們,搞得團隊人愈多,效率反而愈差,流程反而愈亂。
    也許你會問那為何是二到三位資淺人員就配置一位資深人員呢?不能更多資淺人員配一位資深人員嗎?

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

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

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