外包應該怎麼做? 從"APP估價的最佳實作"省思

Contents

前幾天看到一篇Best Practices for Estimating App Cost (APP估價的最佳實作)，讓我想到朋友的接案經驗。他曾經到一家公司談案子，和業主談過產品功能後，朋友以他的經驗告訴業主這種產品很容易就有替代品，也告訴業主有可能的替代品是什麼，他可以顧問的形式幫他們琢磨整個產品的發展，業主謝謝他的告知，後面就沒有下文了。我問他知道有這樣的風險，為什麼還說呢？朋友說總覺不說靜靜接下來，自己賺到錢，但業主可能做出來後也賺不到錢，這讓他良心過意不去。

也曾聽說他談的另一個案子，對方要他一次報價，他認為這案子是新產品，連主導人都對細節不太清楚，比較好的談法是以每個月顧問費多少來談，而非一次報價趕快接到案子再說。業主要求還是要估價才可考慮，朋友在不得已下，給了個價錢，不過後來聽說竟然出現只有半價的競爭者搶到這案子。這樣子的外包接案在台灣屢見不鮮，我本以為國外Agile(敏捷)比台灣成熟，接案條件應該比台灣好吧。不過看了這篇後，發現原來歐美接案也是有跟我們這邊類似的情形，不過已經有人打破這種為了迎合業主，在”假設”情況下”真實”估價的接案方法。將一般專案的失敗率從統計的68% 降到20-30%。

根據The Standish Group 統計，只有 32% 的專案和預估相符，其他68% 都低於預估

這篇APP估價的最佳實作的做法是很好的範例。作者的公司是 APP 開發公司MLSDev，根據research held by clutch.co ，這家公司被列為歐洲 Top 10 行動 APP 開發公司。

作者說以前他們也是為了迎合業主，接的案子雖然多，但失敗率大，改變為誠實應對後，接的案子雖然變少了，但是業主很滿意，下次拿更大的案子來談，也締造口碑，老客戶介紹新客戶。他們用什麼方法進行呢？

以下我覺得不管您是發包的業主或您是接案的團隊都可以參考一下:

先問你一個問題:

如果有人請您安排一個烤肉Party，要你馬上估價，有可能嗎？

也許你可根據您的經驗說大概多少錢，不過真正的成本，如果你不知道

多少人要來參加
要不要娛樂活動
來party的人年齡
要不要雞尾酒或….哪一類的酒
哪些肉品

甚至更多的細節，相信你估出來的數字一定不準。 IT 專案比 Party 更複雜， MLSDev 遵循 Lean(精實)方法，先從小而精實，且完全透明的步驟來做。一個專案分成六階段進行，每個階段都採用Lean(精實)與Agile(敏捷)方法。

第一階段顧問階段

此階段需要了解業主的想法，釐清專案範疇以及看看是否有需要投入時間做不顯而易見的解決方案或創新的研究。此階段就進駐一大團隊和 Business Analyst(商業分析師/製作人)一起研擬與討論。如果沒有深入，只和業主簡單與連續幾小時訪談，雖可幫助 APP 開發估價精確些，但依此就算完成，仍落在迎合業主的接案方式，不建議這樣做。

故此階段在顧問結束後並沒有給客戶報價, 而是以下的產出:

文件：顧問報告
商業模式圖
有時會給業主完全不同的想法(如果研究發現市場已供給過剩充斥太多競爭者產品或業主的想法用現代的科技無法實現)

第二階段 UX設計

前一階段的產出對於業主來說是很好的開始，就算他們後來選擇另一家外包接案公司。 MLSDev 說90%不會發生業主另選他家的問題。

以下，神奇的事就開始了！設計師開始加入，他和其他專家包含開發工程師、其他設計師以及商業分析師共同合作。

此階段，將估計以下幾項的成本:

UX Wireframes
APP介面與介面關係圖設計

不用解釋您也知道以上這兩項對於步入下一階段的UI設計非常重要。 MLSDev的經驗是..如果你的UX做好了， UI就不會超出預算。

第三階段 UI設計

完全準備好了才到這一階段。 MLSDev在此階段已經和業主達成完全的共識。通常有可能做 UI 的工程師不會是前面 UX的工程師(雖然UX工程師常常有辦法做UI），如此能以另一個新鮮的觀點繼續這個專案。這對於專案發展很有幫助。

此階段估計以下成本:

競爭者產品的設計分析
提供多種版本的logo
提供所有主要介面的多種風格設計
互動樣板的開發
準備設計準則

這個階段非常非常重要。不只是UI設計師，開發工程師、其他設計師、專案經理、商業分析師、QA專員甚至終端用戶都要參與。也就是說此階段的工作需要所有相關利益方的通力合作且要盡量收集回饋。

階段四早期計畫

MLSDev 說這階段是最近才加入他們的流程，他們發現有很多次因為有做這一步，成本抓得更準確。此階段的成本估計包含大部份的技術事件。開發團隊和業主共同

確認MVP(The minimum viable product 最低可行性產品)，列出產品features(功能)
產出 product backlog(產品待辦目錄)，以user stories(使用者故事)和test cases(測試案例)形式條列所有app功能的清單
寫出test cases(測試案例)
開發技術規格(如有需要)
佈局專案架構

“The minimum viable product is that version of a new product
which allows a team to collect
the maximum amount of validated learning
about customers with the least effort.”
Eric Ries