Contents
本文由The Effective Engineer 作者Edmond Lau授權翻譯
「不游就淹死 (sink-or-swim)」, 這聽起來不是最鼓舞的話。 Ooyala的CTO,也是前Google聯合創始人, Sean也許可在我進入狀況後跟我說這話, 不過這話在我一到職跨入新創世界的第一天就明白告訴我- 不會有什麼救生圈,唯一可行的是不斷掙扎且最好學會如何以最快的速度生存。
從第一天我進入一個30幾歲的人開創的公司 Ooyala 1 , 我發現自己一直在龜速處理一個程式碼基底(codebase)。 這程式碼攪和著技術債(technical debt), 有一點文件說明, 沒什麼單元測試(unit tests),且用我不熟悉的以類似Java的語言ActionScript所寫的, 我只有兩個星期的時間建構上線一個已經承諾給影片出版者的功能, 一個能讓他們可以排程影片那時候可以上線上線的功能。 2 為了能準時完成, 我必須學習ActionScript, 馬上使用Ruby on Rails,熟悉Flash影片和圖形函式庫 ,除此之外還要追蹤一堆雜亂的程式碼,內含不明的變數如 “qqq” 以及讓人問號一堆的函式名稱如 “load2” 和 “load3”。
真的有需要為了新員工的到職投資時間?
新創公司有成千上萬的事需要完成, 且很多都在跟時間賽跑, 要在資金用盡前儘快建構產品、獲取使用者和客戶。 所以第一個問題為是否,與何時,挪出資源投入新員工的到職訓練才合理? 很多新創公司要嘛不管,,不然就是延遲對這方面做任何投資。 他們仰賴新進工程師自己去問問題, 搞清楚要做哪些事情。
有時這是有用的,但有可能會發生一些特定案例、缺漏、錯誤定義的風險:
- 掃掉一些不錯的人才,這些人也許給他們一點點指引就會很有生產力。 這對於已經花了很多精神與力氣招募人才的公司來說真的是非常可惜。
- 無法在短時間內辨識出低產出或不良雇用的員工, 因沒有足夠的時機來評量他們的工作或你可能一直懷疑需要在他們變得有生產力前給予他們機會。
- 新進員工生產力的成長所需要的時間比應有的還長,因此少了預期的生產力。
- 新進員工有較多的壓力與較少的幸福感, 尤其是從來沒在新創公司待過的員工更覺如此。
當你有越多新進人員, 這些風險將越高, 尤其是如果你偏愛招募沒有經驗的候選人, 如大學畢業生到你公司做他們第一個全職工作的話。
當團隊成長, 非正式的到職體驗不會隨著規模擴大。 不同的員工於不同時間為新進人員解說並沒有一個標準,如此這些分散的說明很有可能漏掉掉應該包含的有用資訊。 一位工程師有可能搞不清楚關鍵抽象(key abstraction),而這資訊對於工作其實很有幫助。 這有可能是因為他起初參與的專案都是周邊非關緊要的功能, 從來沒有機會去看核心程式的部分。 或者, 如果公司的期待目標沒有被清楚地傳達,一位新進人員有可能花太多時間去學習新的東西, 一個月內卻毫無實際的產出。 當一家新創公司還小,東西相對比較少,容易辨識出重點。 當公司稍微大一些, 產品、程式基底(codebase)都比較多了, 需要關照的事物也增加, 對於新人來說, 在沒有指引下, 將越來越難辨識出必須優先了解的課題。
到職流程是一個機會和新進人員溝通哪些是團隊最重視的, 指引新進人員學習與行動的方向。 設計一個好的到職流程將提升到職後的工作效率。 而且, 一開始就投資時間建立一個好的到職流程將持續效應, 隨著更多的人員僱用而加倍獲益。
設計到職流程
我在Quora的那段期間領導新進工程師的到職計畫開發, 負責定義工程方面師徒制(mentorship)的角色、組織與籌畫到職講習、協調製作教育訓練資料、主持導師(mentor)訓練工作坊。 從2011年的12月我開始這到職計畫,那時Charlie和我發覺我們將有10位新任全職工程師, 以及夏天即將報到的實習生。 當時我們的團隊約30人, 其中僅14位是工程師, 所以我們預知如果沒有好的到職流程, 到時將非常混亂。
起初成立Quora的到職計畫,我很明白要讓此流程比我曾經歷過的平順而且少些壓力。 在決定要做哪些素材、講習、輔導等事之前我必需先定義好一整組達到優質到職過程的目標。 設定好後然後去實現這些目標。 團隊成員分享他們過去的到職經驗中哪些是喜歡而哪些是不喜歡。 我也向外諮詢其他公司的工程師(包含我前公司Ooyala的朋友, 他們那時也開始建立他們的到職計畫)了解他們的到職經驗也探索哪些做法會有效用。
到職計畫的目標也許因不同新創公司而異。 以下將列出一些我認為新創公司新員工的到職過程應該達到的目標, 並告訴您針對每個目標我們在Quora做了哪些再造工程。
1. 加速提升新進員工生產力
新創公司大多急需人力資源,投入時間幫助新員工加速提升產能對於那些設計到職流程的人來說就是一個增加團隊生產力的短期打擊。 一位新進員工越早提升自己的生產力, 就可越快貢獻有用的產出。 長遠來看這將讓新創公司變得更好, 因為整體將完成更多, 對於新進員工來說也很有好處, 因為他/她也想證明自己對團隊是有生產力的。
在Quora我們用一種方法強調加速提升新進員工生產力的重要性, 我們指派一位導師(mentor)給每位新進工程師, 對新進人員的成敗負責。 我們建立彼此都了解的底線, 事實上, 強烈地鼓勵導師和其他團隊的夥伴從例行工作抽出時間訓練新進員工。 如此我們預期導師為了這加速提高生產力的訓練,在新進員工剛進來的頭幾個禮拜會失去25%或更多自己的生產力。 導師要做的工作範圍包含審查徒弟一開始寫好的程式碼, 挑選出日益廣泛和難度的專案, 概述徒弟應該趕上的技術以讓自己變得更有效率, 結對編程(pair programming)以便指導技巧與訣竅, 教導優先順序的策略, 或幫助找出與不同團隊成員工作的最好方法。
我在Quora時輔導不少人,而且我在第一天就跟我的徒弟明白點出讓他們快速有生產力的重要程度比完成我自己的工作還高。 這幫助我們之間有共同的目標-加速提升他們的生產力, 且讓他們能毫不猶豫地跟我問問題。
2. 傳遞新創公司的文化與價值觀
每一間新創公司的文化都不一樣。 也許新員工可以由招募、行銷資料以及和團隊成員的面試會議略知一二, 但到職流程將是確保新進員工瞭解團隊共識的價值觀很棒的機會。 這價值觀有可能是著重將事情完成的效能、資訊導向、團隊合作、高品質的產品與服務, 或是其他。 能有效在到職流程中傳達價值觀的先決條件當然是新創公司內部對於自己的文化、使命和價值觀已清楚的定義並達成共識。
例如在Quora, 產品本身很自然地營造學習的文化。 但事實上造成新加入者太過趨於學習, 尤其那些社會新鮮人, 以致不夠快速進入狀況完成任務。 為了確保新進工程師了解公司的步伐, 我們試著讓每位新進工程師在第一天透過推一個交付(push a commit)將自己加入團隊的頁面(譯注: 作者並沒有交代push a commit的內容), 並於第一週內要解決一個Bug並部署、完成一個小的新功能或做一個新的實驗。
這意味著要讓第一天的活動夠簡化,如此新進工程師能在第一天就有足夠的時間建置他/她的開發環境、做個簡單的程式碼變更、跑測試與交付變更。 同時也意味著導師(mentor)必須事先準備新進工程師可在到職一星期內完成或解決的Bug、功能或實驗。 由於我們自己的專案進度預估3和新進工程師真實花多久時間趕上進度很容易有不少的落差, 我一般提議導師挑選他/她認為自己有辦法於一天內完成的初階專案, 如果專案完成時間無法如他的預期, 還是有很高的機率在一週內完成。
3. 讓新進員工廣泛接觸成功所需的基礎
隨著新創公司成長,產品、團隊與程式碼基底也跟著成長, 也就是說新進工程師需要更費力地掃描出須知事物的資訊面積越來越大了。 在我的職業生涯中, 我也注意到那些對基礎工具與抽象(abstractions)清楚的工程師–不管是他們比較善於釐清應該了解的工作重點或曾有導師或初階專案鼓舞他們學到重點概念,經過數月後往往比其他人更有效率, 因為他們知道有哪些資源可用以及應用時機。 好的到職流程的重點在於保證每位新進工程師的起步一致且給予他們堅實的基礎, 如此每位新進工程師在初階專案或是導師指定的功課上所學到的東西不會有太大的差距。
在Quora我們運用兩種方法完成這樣的工程:
- 建置一系列新進工程師於到職兩週或三週內需參加的講習會~約10 個。 這些講習將介紹程式基底(codebase)、解釋git上的資料模型、告知所有的測試期望(testing expectations)、展示解bug (debugging) 與效能分析 (profiling) 工具, 並包含各種其他我們認為新進工程師應該於到職兩或三週內了解的重要事物。 對於最重要的事物, 如程式基底的介紹, 我會為每一次進來的新近工程師作安排, 即使那次只有一位新進人員, 其他較不重要者, 就可能等比較多人進來後一起講習。
- 編寫codelabs說明公司內產品的抽象層(abstractions)和輔助工具(tools)。 Codelabs 是我從Google學來的概念。 一個codelab為一份文件說明為何一個核心抽象層(abstractions)如何被設計出來, 展示要如何使用它, 演練程式基底(codebase)相關的部分, 並提供一套練習以確定學徒是否了解。 我先花三天的時間寫出第一份好的codelab做為後續發展的模型, 然後徵召團隊夥伴寫其他的codelabs, 這些codelab是每位工程師都應該知道與使用的核心抽象層(core abstractions)與輔助工具(tools)。
這些投資主要是參與的前期、一次性建立能重複使用資源的成本, 後續只需要將過時的資料更新, 以及對新進工程師舉辦實際的講習。
4. 運用社交讓新進人員融入團隊
比起其他地方,在新創公司你很有可能大多時間都和工作夥伴在一起。 這有助於鼓勵新進工程師融入團隊, 尤其是那些害羞比較安靜的人。
在早期的Quora, 我們主要仰賴導師(mentor)帶著新人介紹給工作夥伴。 後來有的團隊夥伴開始組織小組午餐, 讓新進工程師更有機會認識團隊其他夥伴。 此外,將新進人員集合分批於同一天到職, 也可幫助他們更有同志情感。
以上這些目標只是一些範例。 讓你思考有可能想在你的新創公司設計什麼樣的到職流程。 當公司成長, 到職訓練所想達到的目標也將隨著改變。 譬如, 根據和Facebook(同意! 如果你說她已經不是新創公司)負責集訓(Bootcamp)到職流程4的工程師透露, “讓新進工程師選擇他們想要加入的團隊”很重要。 在組織還沒有真正做好工程團隊的定義前,這不會是到職訓練的目標。
很重要的是我們要明白-建立到職流程,可以也應該是個互動的過程。 有可能你開始只是簡單地寫一份文件, 說明如何建立開發環境以便讓新進工程師在第一天就可以做程式碼的修改。 晚點你有可能發現並非所有的起始專案都能有同樣的加速提升新人生產力的效果, 需要更進一步給予清楚的指導原則, 說明如何挑出好的起始專案。 也許你注意到你一次又一次地演練同樣的程式碼基底(codebase)或同樣的架構, 那麼是否要為這主題準備個講習, 會更加有效率和效果呢?
每當你在設計到職流程時, 就想想你自身的經驗並詢問其他團隊或公司的人看看哪些有用、可以如何改善。 想想看新進工程師有可能在哪裡遇到困難, 你可給予什麼幫助讓他們很快地瞭解狀況趕上進度。 想想哪些重要的概念、工具與價值觀你真希望在剛進公司的時候就知道了。 只要有一些想法, 把最有價值的實現, 然後問問新進工程師和他們的導師夥伴, 看看這樣的改變是否有幫助。 一再重複這個流程, 希望這樣的到職計畫不會再給你的新進人員經歷和我在Ooyala一樣的緊張經驗。
原文How to Build a Good Onboarding Process for New Hires at a Startup
本文是作者於Quora上的回答 整理
關於這篇文章作者

Edmond 目前教導軟體工程師和技術經理如何有效率的建立有意義的影響力。
他是 Quip 早期的軟體工程師,曾經在 Quora、Google和 Ooyala 帶領軟體開發團隊。

內文中的註釋
- Ooyala focused on building an end-to-end platform to power online video for its customers, handling everything including transcoding, delivery, advertising, analytics, and other services. ↩
- “Schedule when your videos go on the air”, June 2008. ↩
- See my answers on What are some ways to improve your project estimation skills? and What is the best way to communicated to a software development team that they need to work more hours to hit a launch date? to understand why project estimation is hard. ↩
- How does Facebook engineering’s Bootcamp program work?↩
https://softnshare.wordpress.com/2016/08/19/softengineer80-20rule/