圖片來源

這篇要談的不是最小可行性產品的MVP(Minimum Viable Product), 也不是一般說的概念驗證POC(Proof of Concept), 而是承接上一篇講的Hybrid Project Management, 會繼續延伸出專案規畫時的一個問題, 既然合約會將專案總時程固定下來, 那我怎麼知道中間階段需要幾個Iteration來完成軟體開發? 怎樣才能知道整體專案時程要預估多久才合理? 所以我想談談我自創的MVPOC = Maximum Value Proof of Concept, 即最大價值的概念驗證, 唯有在POC階段就將可能的風險, 或是最不熟悉的Domain Know-How盡量釐清, 讓概念驗證的產出不只是用來證明技術可行性, 同時更應該要具備可"有效"評估專案範疇, 時程, 成本的價值, 釐清關鍵步驟或盲點(也有點像是預先找出可能的Critical Path), 才不會只是隨便Demo一下只為了能成案, 但真正成案了之後卻又感覺是打腫臉充胖子, 沒有預期到的技術與非技術風險一大堆, 最後還賠了夫人又折兵的一點利潤都沒有, 越做越痛苦~

但越詳細的POC也代表了越多的投入, 我個人覺得這要取捨, 一開始可能花費較高, 或是找那種POC階段也願意付費的專案, 但若是持續深耕在同一類型的專案上, 就會逐步降低做概念驗證的成本, 因為類似的軟硬體可以共用或套用, 同時也越來越熟悉相類似的專案評估時所需要注意的項目有哪些? 技術與非技術的面向都要考慮在內, 因為這也是血淋淋的經驗教訓, 因為過去有某個feature要開發, RD好死不死只挑了一個最簡單的Target做POC, 結果認為非常可行, 而且技術投入不高, 結果正式開案後, 實際Target有五種, 除了POC的那種之外, 其餘都很難搞, 結果最後搞得人仰馬翻, 重新檢討起來, 或許可以找更有經驗的人先評估要POC哪個Target ? 又或是簡化流程後, 多嘗試幾個Target, 以免錯估情勢, 總之, 絕對不要小看POC的價值, 因為這是評估後續專案展開是否有風險的關鍵步驟, 也因為只能有小部分的投入, 所以要謹慎地選擇投入POC的範疇, 選擇做能有效成案, 同時兼具專案評估的關鍵部分來執行!