前幾天看到一篇Best Practices for Estimating App Cost  (APP估價的最佳實作),讓我想到朋友的接案經驗。 他曾經到一家公司談案子, 和業主談過產品功能後, 朋友以他的經驗告訴業主這種產品很容易就有替代品, 也告訴業主有可能的替代品是什麼, 他可以顧問的形式幫他們琢磨整個產品的發展, 業主謝謝他的告知, 後面就沒有下文了。 我問他知道有這樣的風險, 為什麼還說呢?  朋友說總覺不說靜靜接下來, 自己賺到錢, 但業主可能做出來後也賺不到錢, 這讓他良心過意不去。
也曾聽說他談的另一個案子, 對方要他一次報價, 他認為這案子是新產品, 連主導人都對細節不太清楚, 比較好的談法是以每個月顧問費多少來談, 而非一次報價趕快接到案子再說。  業主要求還是要估價才可考慮, 朋友在不得已下, 給了個價錢, 不過後來聽說竟然出現只有半價的競爭者搶到這案子。   這樣子的外包接案在台灣屢見不鮮, 我本以為國外Agile(敏捷)比台灣成熟, 接案條件應該比台灣好吧。  不過看了這篇後, 發現原來歐美接案也是有跟我們這邊類似的情形, 不過已經有人打破這種為了迎合業主, 在"假設"情況下"真實"估價的接案方法。 將一般專案的失敗率從統計的68% 降到20-30%。
Standish Group Research

根據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 開發估價精確些, 但依此就算完成, 仍落在迎合業主的接案方式, 不建議這樣做。

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

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

Business Canvas

第二階段 UX設計

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

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

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

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

UX Examples

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

第三階段 UI設計

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

此階段估計以下成本:

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

UI Example

這個階段非常非常重要。 不只是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

階段五 發展MVP

此階段接近完成點。 MLSDev在此時將請業主回頭審視之前一起做的一切, 通常業主都會很滿意。  這階段的開發估計最複雜且龐大。這裏重度仰賴前面階段的工作確實完成。  事實上, 連此階段的估價動作也都列在 backlog 的 user stories 和 test cases中。

這階段APP開發成本的估計包含:

  • QA專員的工作
  • 專案經理的工作(有可能是ScrumMaster, 也有可能要包含 Product Owner,如果業主沒時間做 Product Owner)
  • 時間成本,如團隊要做的 Scrum 會議
  • DevOps工程師的工作

Backlog

階段6  後續的開發與支援

此階段從產品成功上市後起算。 這時候, 市場應該已經回饋很多資訊, 此將影響整個產品的未來走向。 這些都不是在專案起始階段就可以預知的。

此階段 MLSdev 通常以月計畫或當 backlog 的代辦工作已充滿新的有趣賣點時一起估價。

看了以上的六個階段, 如果你的產品或服務不是行動 APP 開發, 應該也可以臨摹, 想像出分幾個階段做別種產品的分段計畫了吧!

作者說如果你是業主, 你應該拒絕那一開始沒問清楚就跟你打包票估價的人。  MLSDev 自從採用這種理念接案, 他們做的不再是一般的outsourcing, 而是outsharing。   期待台灣能有更多這種理念的業主與接案者, 讓誠實與精益的態度成為大家的共識。

也許你會有興趣

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

 

 

 

 

Join the conversation! 3 Comments

  1. 階段四的早期計畫的Product Backlog中文譯應該是產品"待"辦目錄, 請參考

    按讚數

    回應
  2. […] 外包應該怎麼做? 從App估價的最佳實作省思 無論您是做產品, 接案, 文中提到的幾個階段都值得好好考量, 這篇文章來自歐洲一家專門在接App的公司分享出來的, 國外也有同樣的問題, 月亮沒有比較圓, 但是這家公司採用了敏捷開發的手法, 最後他們的生意反而變好了, 而且也獲得客戶的信任. 希望這篇文章可以改善一下國內接案削價競爭, 亂壓期限的風氣. 如果您覺得這篇文章講有道理, 幫我們分享出去吧! […]

    按讚數

    回應

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

分類

產品開發管理, 軟體工程, 專案管理, 敏捷開發