如何做好客製化軟體委外開發
你問對問題了嗎？
客戶最近請教了我三個與「客製化軟體委外開發」相關的問題：
- 如何評估預算？
- 如何看懂廠商給的規格書？
- 廠商要是沒有辦法準時交付，我該怎麼辦？
對上述的問題，我回答如下：
- 評估預算應該從最重要的資訊來評估：ROI (return on investment)。無論是已經上軌道的公司或是新創，要做客製化軟體開發，都會有想要解決的問題，比方說，節省一定的人事成本、縮短銷售時程 (sale closing time) 等等，也就是會有所謂的預期效益 (return) 。而基於效益而評估出來的預算，自然就是投資 (investment)。
- 廠商給的規格書方面：在軟體來講，規格書有很多種。有幾種的規格書，是設計來給軟體開發人員看的，比方說 UML 圖、資料庫的 schema 等等，它描述的是軟體的實作細節 (implementation details)。如果是給發案的業主看的，叫做「軟體需求說明」(Software requirements specification 或 SRS)，它描述的是軟體的功能 (purpose) 。這邊做個類比，如果你恰好有一間房子要做裝潢，施工的裝潢公司會有不同的說明文件：給業主看的，是房子內的配置、外觀的設計圖，這種近似於 SRS。另一方面，給施工的水電、水泥工看的，則是另一種文件，它描述的是實作細節 (implementation)。實務上，也許不在少數的軟體開發人員或是公司，他們給業主看的文件，就是直接拿描述實作細節的規格書給業主看，也因此讓業主產生一種「規格書」都無法理解的印象。
- 為了避免延時交付、或是軟體品質問題，可以在合約裡明定責任的歸屬，彷彿這是一個法律與責任歸屬的問題。然而，如果定了合約、定了罰則就可以有效解決這些問題，那業界常見的 84% 的軟體專案延遲交付，這又是怎麼來的？
其實，上述這些問題，相信絕對不是只有我的這位客戶有而已。因為我有遇到幾位的潛在客戶，來找我談生意時，他們的問法基本上都長成這樣子：
- 我想要做一個，跟 A 公司一樣的 OOO 軟體。
- 你估價多少錢呢？
於是，如果軟體外包商單純照客戶的提問來回答，照上述提問的軌道進行溝通，廠商提出的規格書很可能就真的是描述實作細節的文件 (畢竟功能需求，業主就已經指定，要跟 A 公司的 OOO 一樣嘛！)。
而業主拿到了估價與規格書之後，就立刻產生了最初的問題：
- 這個估價是合理的嗎？我要不要殺價？要不要貨比三家？
- 這個規格書我怎麼看不懂啊？咦，好像是設計圖，那我如果拿去給其它家廠商看，他們會報一個比較便宜的價格給我嗎？
- 我該選哪一家廠商呢？我想選最便宜的，但是，會不會品質很糟或是延時交付呢？
而上述這種方式達成的結果，往往不會是成功的專案，而結果十之八九就會像業界的常見的現象：軟體專案，成功是例外，失敗是常態。
客製化軟體不是解決方案 (solution)、而是解決方案的放大器 (amplifier)
曾有一位客戶委任我做財務領域相關的軟體，一開始他提的規格需求就是用「跟 A 公司的 OOO 一樣，然後在這邊改一點點」的方式來描述。我告知他，「A 公司的 OOO 看起來是一個團隊做了兩年的成果，不像是你的預算可以負擔的。」由於這位客戶本人對於 Excel 相當熟練，我給了他一個建議：「把你想要做的東西，先用 Excel 拉出一個概念雛型，然後，我們再來討論把這個做成客製化軟體大概要多少錢？」3 個月後，這位客戶重新思考了他的問題 (problem domain)，並且給了我一個含有十個分頁的 Excel 檔案，而我也在 3 個月後，將專案準時交付。
在上述的案例裡，業主一開始也是用「跟 A 公司的 OOO 一樣，然後在這邊改一點點」的方式來提需求。這種提出需求的溝通方式，其根本問題在於：「A 公司的 OOO ，是 A 公司為了 其特有的問題，設計的解決方案。」然而，業主的問題十之八九，會與 A 公司的問題有一定的出入，在還沒有分析問題，針對業主的問題提出針對性的解決方案之前，就冒然委外開發一個「可能與問題不合用」的客製化軟體，這就是會導致失敗的根本要素。
比較好的做法是：「業主必須承擔溝通的責任，與廠商一起去對自己的問題 (domain problem) 做分析與研究，來提出解決方案 (solution)」此處的「解決方案」可能是各種不同的形式，最常見的形式應該是 Software requirements specification。然而，在上述的例子，解決方案就是一個 Excel 檔案。當然，如果用 Excel 檔來服務大量的用戶，問題一定很多，所以如果要服務大量的用戶，當然還是要把 Excel 版本的軟體，改成 web 版的 SaaS 服務。 SaaS 服務，就可以視為是 Excel 版本軟體的放大版 (amplified version)。
在我的經驗，如果業主有針對自己的問題做出深入分析之後，往往會發現，自己真正需要的解決方案可以比原先自己口頭描述的簡單許多。解決方案變簡單了，價格自然就可以降下來，交付時間也可以大幅縮短。此外，前述業界常見的軟體延遲交付比例 84% ，造成的原因排行前兩名，分別是「需求不明確」與「需求變動」。某種程度來講，「需求不明確」與「需求變動」往往也是導因於，最初就沒有針對業主的問題，做足夠的研究與分析。
