今天要討論一個比較嚴肅的議題：績效與人事管理。
新創團隊，尤其是創辦人第一次創業的新創團隊，通常在籌資後碰到的第一個問題就是不知道如何有效管理新舊員工的職責與績效。到底甚麼時候應該賦予員工更多的責任？何時應該提供員工額外的受訓機會？又何時（在最壞的情況下）應該好聚好散？
由於篇幅和範疇的關係，本文將以軟體工程師為討論對象。希望能夠針對分析不同工程師的個性來幫助創辦人決定如何協助旗下工程師工作更有效率。
在做任何決策之前，第一件事情就是要先了解一位員工（軟體工程師）的個性與思考模式。在外，許多人喜歡把軟體工程師全部混為一談，更有人以為駭客、軟體工程師、解決方案設計師與ＣＴＯ（技術總監）等角色可以隨意互換，只要找到會寫程式的人就萬事ＯＫ。
事實上，有些工程師喜歡嘗試、追求新鮮感，有些工程師則是深思熟慮、追求產品的穩固（Robustness），有些工程師對客戶很有興趣，有些工程師喜歡專心開發不希望從事管理職。軟體工程師除了使用的語言和工具不同外，每個人的習慣和個性不同，自然也適合不同的軟體開發工作。
以下根據背景和性格作粗略的分類（互不相斥）：
駭客
駭客（Hacker）一詞因為媒體的喧染而讓許多人對這詞有負面印象。英文「Hack」一詞就是「亂砍」的意思，應用在技術上，就是在沒有完善理論基礎的情況下，靠獨自摸索、拼拼湊湊來解決問題。說穿了，就是實作。由於資安方面的問題很多都是實作而非理論主導，因此後來許多人印象中的駭客都是搞入侵的。事實上，駭客可以是任何獨自開發、勇於嘗試的程式設計師的稱謂。
而所謂駭客，通常帶有一種特質，那就是對於技術面有濃厚的興趣，並且對於新技術勇於嘗試。許多駭客平常沒事喜歡掛在論壇上看技術文章，不然就是自己動手寫個小專案來玩玩新技術。因此，許多駭客都是自學自成。
駭客作為員工，優點是內部動力堅強，而且在尋找解答時效率驚人。缺點呢？駭客由於喜歡探索，通常缺點就是三分鐘熱度，常常在摸摸新技術後寫了個小專案就想要換跑道，對於專案管理、測試、品管和團隊溝通都沒有甚麼耐性。由於許多駭客的自我管理和規劃能力都未有效開發，若硬要求，常常會使其失去興趣而效率越漸低落。
資工畢業生
讀資工系出身的畢業生，若上課沒有太混的話，其對於軟體開發的演算法、資料結構、系統、網路、各產業應用等都應該有基本的認識。
聘請資工系畢業生作為員工，相對於自學自成的駭客而言，出身資工系的軟體人才的理論知識較完整，可塑性亦高很多。而本科畢業生資歷尚淺，比較容易管理，也比較願意聽命與積極學習。論缺點，資工系畢業生由於出自傳統教育體系，不見得每個人都對技術有濃厚的興趣，較少會像駭客一樣自動自發地去充實自己。
資深工程師
說到資深工程師，這邊指的員工要有能力設計軟體架構，並為其估算開發時間，並有效地與同事溝通程式元件之間的資料介面設計。由此可見，資深工程師對於軟體的開發流程相當有經驗，因此能妥善規劃而少出錯。
若駭客的本質是「靈活」，那資深工程師的本質就是「穩重」。駭客常因為新技術的酷炫而想出一些稀奇古怪的點子，但是資深工程師了解軟體工程的痛處不在開發，而在維護守恆，因此在考慮技術、語言與工具的時候，會更全面性地去評估成熟度、開發效率和維護成本。
資深工程師優點很明顯，而缺點就是缺乏畢業生的可塑性，也缺乏駭客的冒險精神。
解決方案設計師
說到軟體解決方案，除了軟體架構設計和實際開發過程以外，還有一大部分的人文與商業因素。雖說這些通常是市場研究和人因工程的領域，有些軟體人才本身就有濃厚的人文與商業素養，在此暫且稱之為解決方案設計師。
以角色而論，解決方案設計師除了本身的開發能力以外，自己本身也喜歡思考用戶的使用問題，甚至會思考如何解讀行銷數據．這類人才最適合與公司內部不同（技術與非技術性）職務的人溝通。（這類人才也最適合升任產品經理或技術總監）
一般而言，解決方案設計師的優點在於其思考模式具全向性，比起其他技術人才更能夠執掌產品的整體開發。論缺點，此類人才通常視技術為媒介而非目的，因此不會像駭客一般去探索新技術。故此，解決方案設計師開發的效率通常不比其他技術人才。
說到這裡，我們要了解，以上人格特質並不相斥，沒有一技術人才僅擁有單一特質，因此在觀察時要格外細心。
人盡其才，才盡其職，職盡其能，能盡其用
了解員工的人格特質，用意正是在於尋找適合該員工的職務。打個比方，若一員工是駭客型人才，那與其要求他去作開發流程（Dev Ops）規劃，不如讓他做 Full stack prototyping ；同理，沉迷於技術的駭客常常對於人文互動沒有太大的興趣，因此也不要強迫他每天出去跟客戶見面。
對於職務的可能分配，以下是個人淺見：
對於除了快速 Prototyping 職務以外，他們較適合前端介面、行動介面、資訊安全等以實作知識為主的工作，讓駭客人才可以善盡其探索的精神去解決理論無法直接解決的問題。駭客人才較不適合需要穩定性和量化的工作，才能滿足其對新鮮感的需求。
績效管理設計
一旦決定員工的職責，下一步就是要明確定義績效管理的標準。
大部分的新創團隊都沒做到這點，不管是不知道該做還是不知道怎麼做，沒有績效管理最後很容易造成員工無法完善開發自己的潛能並完成工作，最後拖累整個團隊。由於新創團隊相對於成熟公司改變速度太快，因此很難用單一量性目標（e.g. 專案數量、開發時間、客戶成長率等）去進行績效評估。因此，應該考慮以階段性目標作為績效標準，而平時則透過專案管理來了解員工進度，但不用個別專案進度的量性指標來作為評估標準。
何謂階段性目標呢？
假設你的團隊在設計一客用物聯網產品，預計一年後上市。第一階段可能為期三個月，預期設計出軟體模擬器來測試硬體產品的雲端後台與演算法。第二階段同樣三個月則致力於開發硬體裝置，並完成製造 Prototype。第三階段同樣三個月，進一步精進 Prototype，並進行使用者測試。最後三個月觀察突發狀況，進行產品上市前最後補強。
在產品開發的每個階段，你都要為不同的人才設計不同的階段性績效目標。以第一階段來講，對於一位主導 Prototyping 的駭客型人才，你可能會要求他按時完成功能性目標；而對於一位資深工程師，你可能會要求他在 Prototype 的任何功能初版釋出後，開始進行測試並且確保兩個禮拜內達到單元性（Unit）的基本穩固度（Robustness）。
階段性目標可以幫助團隊了解個別職務角色是否有發揮其作用，一般來說，只要團隊整體開發時程沒有嚴重延誤，而個人也沒有嚴重疏失的話，通常不會雞蛋裡面挑骨頭。
若個人完成了階段性目標，請不要忘了在年終發放紅利（一個月或兩個月的薪資？僅供參考），來持續提振團隊的士氣。
績效提升方案
你可能會問，如果用階段性目標來評估員工績效，那去追蹤平時的每日專案進度要用來幹麼呢？問到重點了。
其實績效評估的用意不是在驗證良好績效，而用比較暗黑的言語直言，其實是在收集績效不良的證據，以防不時之需。
若今天公司內部一切順利，你根本不會去追究員工哪一天做了甚麼事情。但是，若員工績效低落，那屆時這些每日專案進度的資料就非常、非常重要了。
其實很多新創團隊員工效率被拖垮不是死在員工能力不佳，而是在於創辦人（或主管）沒有有效整體員工的進度紀錄，因此不知如何幫助員工提升績效。演到最後常常就是讓原本已經焦頭爛額的員工蒙受更大的心理壓力，或是冤枉資遣了有莫大潛力的好員工，不管是前者或後者對於新創公司而言都是很大的傷害。
假設你平時都有做好專案進度，那一員工績效出問題時，我們現在就能討論如何應對。（如果沒做好進度整理？那就先從這邊開始做起吧…）
在許多歐美國家，勞基法都有規定公司若要資遣員工必須要先給員工績效提升方案，並給員工90天（不等）的績效改進期。若90天過後仍未有起色，公司才能合理開除員工。
說到績效提升方案，不管是法律上如何規定，都是一不錯的做法。因為績效提升不只是奠定目標，更要針對員工的弱項進行訓練補強。換句話說，創辦人（或主管）必須要騰出自己的時間，來給員工進行職業訓練，幫助其成長以重新跟上團隊的腳步。
由於績效提升方案針對的是員工的個別工作習慣，通常奠定的目標不能再用階段性目標，而要明確去定義員工每日工作的問題。比如說，敝人過去團隊上曾碰過幾位駭客型的人物，常常工作時都只跟隨自己的腳步，而且沒有依賴關係（Dependency）和團隊協調的觀念（也不聽從主管的指揮），常常開發順序大亂，造成其他員工事情做完了還得等他。
面對這問題，主管便對這位員工進行自我時間管理和奠定優先順序的觀念訓練，要求這位員工每天在工作之前先將工作流程設計好，並且每日跟主管報備兩次，確保員工有依照計畫進行。若員工因此改進了工作效率，那90天後（也可適時縮短）則可以免除跟主管報備的需求。（按：沒碰過這種情況的人可能會覺得很好笑，但是這種情況還挺常見的，而且非常棘手，處理不好，常常會整個辦公室的人等這一位員工。）
另外一例子，可能是一員工常常把未妥善測試過或是有錯誤的程式碼上傳至團隊的 Repository，造成其他員工更新程式碼後無法持續工作。（按：這也不是開玩笑，真的有人很粗心）面對這種情況，主管可能要針對基本的測試概念（單元測試、整合測試、負載測試等）對員工進行訓練，並要求這位員工每天都要寫測試碼和寫開發日誌（甚至可以由主管進行 Code Review）。
好聚好散
一切順利的時候，績效提升方案過後員工便能升級打怪。但是總有一些時候，不管如何鼓勵、訓練、督導，有些人就是無法改變工作習慣。
若走到這一步，通常90天還沒結束大家心裡都已經明白了。作為創辦人（或主管），對這種情況其實也沒有甚麼特別的偏方，只要記得：１）盡量與即將離職的員工保持良好的關係，雙方心平氣和地溝通。
２）若有資遣費需求或要求，只要不誇張且公司負擔得起，寧願花這點錢，也不要增加這位員工離職前後對公司內部進行破壞的風險。
３）在員工離職前（至少）一個月，請找到公司內部（或新聘請）員工來接手該員工的職務。切忌在沒有備案的情況下，草率資遣員工，這只是為自己找麻煩。
４）在與員工會談時，記得要同步結束這位員工的所有帳號，以避免有人意氣用事對公司內務動手腳。
小結
今天討論簡單的新創團隊績效與人事管理，是因為新創公司在「衝、衝、衝！」之餘，時常在團隊建設上從簡，因此埋下許多地雷，未來造成許多爭端。
雖然新創團隊不需成熟公司那樣的績效評估機制，但是絕對不能不跟每一位員工溝通每人的職務與階段性目標，才不會產生誤會。只要一切秉持透明化原則前後一致，新創公司的制度即使簡單也能收事半功倍之效。
Image Source: Cape Chamber
