看到這個標題，我想應該不少人都有苦澀的回憶，我這幾年的工作經驗中，也碰過幾次工程師人間蒸發導致技術開發難以接手的案例，聽說過類似的爛攤子也的確不少，不只是台灣，美國的團隊、大陸的團隊，我們都有遇過，通常創業者本身不懂技術或是對技術一知半解的狀況，就更容易被工程師唬得一愣一愣的。別以為這種事只有遇到外包才會發生，我也看過技術合夥人回印度後就人間蒸發的慘痛案例。
因此，最近幾年在跟創業者合作的同時，我都建議每個非技術背景的朋友，可以至少知道一些基礎，這樣當工程師發生問題的時候，就不致於發生不知道程式碼、資料庫不知在何處的窘境。為了將風險降到最低，以下我們將談談創業家在與工程師合作時需要注意的幾個重點。
防範風險前，先了解工程師對公司的期許
理所當然，我們都不希望讓工程師離開工作團隊，希望工程師能與公司一同成長、長久共事，所以我們可以先了解對大部分工程師來說，對公司的期許是什麼。
一般來說，我們都知道營運端的人需要技術端的人做出平台來讓公司運轉，而風險就在於技術端的人沒辦法如期完成工作，更嚴重一些則是無法交出一個像樣的平台，甚或是人間蒸發。所以這也是為什麼敏捷開發的理念，將產品開發的週期減短，也是減輕風險的一種方式。但是反過來，大家不知道有沒有想過，對技術端的人來說，風險在哪裡？這邊舉一個我最常用的例子，如果一個工程師在 Google 寫一行程式碼跟在任何一間新創公司寫一行程式碼，誰的價值比較高？這答案顯而易見，當然是 Google，因為使用者的量體大小，造成軟體平台的價值有所差異。也因此，對工程師來說，如果他有更好的機會做更大的發揮，本來就是他對於營運端的期許，發揮不如預期自然也成為風險。
一間公司成功的關鍵之一，就是降低人才的流動率，讓每個人的技能與經驗能夠不斷的累積而成長，也能完成對自己的期待。然而往往事與願違，或是對工程師來說，有更好的選擇，也因此管理技術的風險才會顯得如此的重要。
技術管理的風險在何處？如何將問題降到最低？
技術容易發生問題的地方，根據我們過去的經驗，簡單可分為幾種：
問題一：工程團隊因故無法完成或交付任務：這種狀況其實還可以細分為完成一半還是全數完成，以及工程師還有辦法聯絡到還是無法聯絡到，也因此我們在做管理的當下，一定要記得掌握一些基本的原則。
預防方法
- 程式碼一定要用 Git 管理，並且定期請工程師 Commit 程式碼，而且一定要寫 Commit Log。如果是做到一半的專案，至少會大概知道工程師寫到哪。
- 資料庫定期備份，雖然工程師有時候會做自動備份，但是有時候翻臉不認人的時候，還是有檔案存在自己電腦最實在。
- 所有的機台帳號密碼一定要有列表，如果交接後，請全數變更。這樣比較不怕工程師消失，就無法進入機台進行管理與備份。
- 最關鍵也最重要的就是要有技術文件，但是很多人其實並不了解要做哪些文件才算齊全，不過至少有張圖讓你了解你們用了幾台 Server，大概系統的架構長怎樣，API 規劃的文件是怎樣，這些基本的理解，最好還是要有一些文件去做紀錄和呈述。
問題二：資料庫發生問題或是不翼而飛：前陣子發生的血淋淋案例就是 Gitlab 的工程師不小心刪除機台的資料，更久之前台灣也有火燒機房的狀況，這些狀況都讓不少程式碼與資料庫付之一炬。
預防方法
- 資料庫備份其實也是一門學問，除了現在有很多雲端服務會提供自動備份硬碟，建議還是可以定期ㄧ個月手動異地備份一次。
- 進一步請工程師使用 Docker 進行管理，Docker 除了單純的程式與資料備份外，能夠更快地還原整體開發環境。
- 轉移 Schema 前一定要進行測試，很多資料的毀損與遺失，往往發生在 schema 改變的當下，也因此，每次轉移前的備份，決定是否要停機轉移等等，都是需要謹慎思考的問題。
我認為作為一間公司的創辦人，最好能夠自己稍作了解，或是跟著走一遭，畢竟資料銷毀的事，對很多 IT 公司來說，應該就是命脈了。
問題三：開發時間過久才發現大家想的不一樣。這問題有兩種，一種是工程師的能力與原本評估有落差，另一點則是溝通不良。溝通不良較為簡單處理。但以評估落差來說，對於聘外包或是內聘工程師的方案，其實各有不同的惱人問題，對外包來說，麻煩的是如果頭款已經支付，很難頭洗到一半停下來，而內聘工程師的話，則有是不是要 layoff 的困擾，這都是普遍可以見到的狀況。
預防方法
- 如果是溝通不良的問題，團隊可以用兩到三週的時間作為一個循環，讓工程團隊定期做一個簡單的 Demo，每一次的工作都不宜開出一個太大的模組，有別於以往長期專案的思維，凡事要做到盡善盡美的思維一定要改掉。反過來說，每一個小模組慢慢建立，從主要功能到輔助功能分批完成，可以有階段性的產出並且經歷測試，這點非常重要。
- 針對選擇聘請工程師或是外包團隊，很多人會問說怎麼可以確認工程師的程度？當然可以做 reference check 或是 code review，也許有些幫助。我這邊有個更不錯的經驗，在一次與美國公司合作，他們提供了約一週的工作項目，稱之為 working exercise，他們付了三個工程團隊各一週的工時費用，讓工程師去做一個小型模組，最後才決定誰是未來的合作夥伴，這種方法確實會大大降低與新工程師合作的風險。
很多人可能會想說，如果我們公司有良好的文化，有一大堆零食，有很好的福利，聘一個很厲害的工程師來，應該就不會遇到上述的這些問題了吧。
但事實上是，即使連 Google 這麼夢幻的公司，他們要寫的每一行程式碼之前，開發者都必須先交出文件（Design Guide），去闡述待開發模組的目的、功能、引用哪些 Library 等等，才能夠進行開發。良好的文件管理與測試習慣，絕對會是風險管理的最大幫手。
永遠要對最壞的狀況有所準備
這篇文章提到的內容，對很多技術管理者來說，可能是基本中的基本，不過對於新手創業家來說，卻是容易被忽略和受傷害的一環，有一些好的生意，卻遇到一些不在預期內的風險，最後造成了不好的結果，這是相當可惜的事。也因此，對於創業家來說，了解技術的風險，就像了解財務的風險一樣，都是需要學習的功課。我們都知道，給予一同創業的夥伴一個最好的環境，大家發揮所長一同邁向最完美的結果，是非常理想的情況，不過現實不見得如此美好，問題發生時，負責的人就必須跳下去親自滅火，如果能有時間、金錢的幫助，找到新的合作對象、救火隊，漂亮的打場勝仗，當然是最理想，但最害怕的，莫過於在公司資源快燒完時發現平台開發需要一切從零開始的悲劇，創業家們不可不慎，提前思考風險管理！
Image Credit: getapp.com
