創業家不可不知的軟體開發風險管理

看到這個標題,我想應該不少人都有苦澀的回憶,我這幾年的工作經驗中,也碰過幾次工程師人間蒸發導致技術開發難以接手的案例,聽說過類似的爛攤子也的確不少,不只是台灣,美國的團隊、大陸的團隊,我們都有遇過,通常創業者本身不懂技術或是對技術一知半解的狀況,就更容易被工程師唬得一愣一愣的。別以為這種事只有遇到外包才會發生,我也看過技術合夥人回印度後就人間蒸發的慘痛案例。

因此,最近幾年在跟創業者合作的同時,我都建議每個非技術背景的朋友,可以至少知道一些基礎,這樣當工程師發生問題的時候,就不致於發生不知道程式碼、資料庫不知在何處的窘境。為了將風險降到最低,以下我們將談談創業家在與工程師合作時需要注意的幾個重點。

防範風險前,先了解工程師對公司的期許

理所當然,我們都不希望讓工程師離開工作團隊,希望工程師能與公司一同成長、長久共事,所以我們可以先了解對大部分工程師來說,對公司的期許是什麼。

一般來說,我們都知道營運端的人需要技術端的人做出平台來讓公司運轉,而風險就在於技術端的人沒辦法如期完成工作,更嚴重一些則是無法交出一個像樣的平台,甚或是人間蒸發。所以這也是為什麼敏捷開發的理念,將產品開發的週期減短,也是減輕風險的一種方式。但是反過來,大家不知道有沒有想過,對技術端的人來說,風險在哪裡?這邊舉一個我最常用的例子,如果一個工程師在 Google 寫一行程式碼跟在任何一間新創公司寫一行程式碼,誰的價值比較高?這答案顯而易見,當然是 Google,因為使用者的量體大小,造成軟體平台的價值有所差異。也因此,對工程師來說,如果他有更好的機會做更大的發揮,本來就是他對於營運端的期許,發揮不如預期自然也成為風險。

一間公司成功的關鍵之一,就是降低人才的流動率,讓每個人的技能與經驗能夠不斷的累積而成長,也能完成對自己的期待。然而往往事與願違,或是對工程師來說,有更好的選擇,也因此管理技術的風險才會顯得如此的重要。

技術管理的風險在何處?如何將問題降到最低?

技術容易發生問題的地方,根據我們過去的經驗,簡單可分為幾種:

問題一:工程團隊因故無法完成或交付任務:這種狀況其實還可以細分為完成一半還是全數完成,以及工程師還有辦法聯絡到還是無法聯絡到,也因此我們在做管理的當下,一定要記得掌握一些基本的原則。

預防方法

  1. 程式碼一定要用 Git 管理,並且定期請工程師 Commit 程式碼,而且一定要寫 Commit Log。如果是做到一半的專案,至少會大概知道工程師寫到哪。
  2. 資料庫定期備份,雖然工程師有時候會做自動備份,但是有時候翻臉不認人的時候,還是有檔案存在自己電腦最實在。
  3. 所有的機台帳號密碼一定要有列表,如果交接後,請全數變更。這樣比較不怕工程師消失,就無法進入機台進行管理與備份。
  4. 最關鍵也最重要的就是要有技術文件,但是很多人其實並不了解要做哪些文件才算齊全,不過至少有張圖讓你了解你們用了幾台 Server,大概系統的架構長怎樣,API 規劃的文件是怎樣,這些基本的理解,最好還是要有一些文件去做紀錄和呈述。

問題二:資料庫發生問題或是不翼而飛:前陣子發生的血淋淋案例就是 Gitlab 的工程師不小心刪除機台的資料,更久之前台灣也有火燒機房的狀況,這些狀況都讓不少程式碼與資料庫付之一炬。

預防方法

  1. 資料庫備份其實也是一門學問,除了現在有很多雲端服務會提供自動備份硬碟,建議還是可以定期ㄧ個月手動異地備份一次。
  2. 進一步請工程師使用 Docker 進行管理,Docker 除了單純的程式與資料備份外,能夠更快地還原整體開發環境。
  3. 轉移 Schema 前一定要進行測試,很多資料的毀損與遺失,往往發生在 schema 改變的當下,也因此,每次轉移前的備份,決定是否要停機轉移等等,都是需要謹慎思考的問題。

我認為作為一間公司的創辦人,最好能夠自己稍作了解,或是跟著走一遭,畢竟資料銷毀的事,對很多 IT 公司來說,應該就是命脈了。 問題三:開發時間過久才發現大家想的不一樣。這問題有兩種,一種是工程師的能力與原本評估有落差,另一點則是溝通不良。溝通不良較為簡單處理。但以評估落差來說,對於聘外包或是內聘工程師的方案,其實各有不同的惱人問題,對外包來說,麻煩的是如果頭款已經支付,很難頭洗到一半停下來,而內聘工程師的話,則有是不是要 layoff 的困擾,這都是普遍可以見到的狀況。

預防方法

  1. 如果是溝通不良的問題,團隊可以用兩到三週的時間作為一個循環,讓工程團隊定期做一個簡單的 Demo,每一次的工作都不宜開出一個太大的模組,有別於以往長期專案的思維,凡事要做到盡善盡美的思維一定要改掉。反過來說,每一個小模組慢慢建立,從主要功能到輔助功能分批完成,可以有階段性的產出並且經歷測試,這點非常重要。
  2. 針對選擇聘請工程師或是外包團隊,很多人會問說怎麼可以確認工程師的程度?當然可以做 reference check 或是 code review,也許有些幫助。我這邊有個更不錯的經驗,在一次與美國公司合作,他們提供了約一週的工作項目,稱之為 working exercise,他們付了三個工程團隊各一週的工時費用,讓工程師去做一個小型模組,最後才決定誰是未來的合作夥伴,這種方法確實會大大降低與新工程師合作的風險。

很多人可能會想說,如果我們公司有良好的文化,有一大堆零食,有很好的福利,聘一個很厲害的工程師來,應該就不會遇到上述的這些問題了吧。

但事實上是,即使連 Google 這麼夢幻的公司,他們要寫的每一行程式碼之前,開發者都必須先交出文件(Design Guide),去闡述待開發模組的目的、功能、引用哪些 Library 等等,才能夠進行開發。良好的文件管理與測試習慣,絕對會是風險管理的最大幫手。

永遠要對最壞的狀況有所準備

這篇文章提到的內容,對很多技術管理者來說,可能是基本中的基本,不過對於新手創業家來說,卻是容易被忽略和受傷害的一環,有一些好的生意,卻遇到一些不在預期內的風險,最後造成了不好的結果,這是相當可惜的事。也因此,對於創業家來說,了解技術的風險,就像了解財務的風險一樣,都是需要學習的功課。我們都知道,給予一同創業的夥伴一個最好的環境,大家發揮所長一同邁向最完美的結果,是非常理想的情況,不過現實不見得如此美好,問題發生時,負責的人就必須跳下去親自滅火,如果能有時間、金錢的幫助,找到新的合作對象、救火隊,漂亮的打場勝仗,當然是最理想,但最害怕的,莫過於在公司資源快燒完時發現平台開發需要一切從零開始的悲劇,創業家們不可不慎,提前思考風險管理! Image Credit: getapp.com