iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 9
2

每天寫文除了寫文本身很花時間以外,想題目我覺得也很花時間。還好,今天的題目剛好昨天就想好了。可喜可賀。今天就來聊聊 MVP 和 Product,也會把一半的重點放在昨天提到的問題「技術債是可以不還的嗎?」這件事上。

Product,也就是產品,這名詞應該比較沒有疑慮,以軟體業這行,簡單來說當然就是要拿去賣的軟體。那什麼是 MVP 呢?MVP 是 minimum viable product 的縮寫,用中文來說就是最簡可行產品。顧名思義,MVP 就是可能只有預想中產品的部分功能,但確恰好可以表達該產品核心概念,所以說是最簡可行產品。為什麼不要直接做 Product 呢?因為直接投入研發的成本是較高的,若是這個功能或特色其實不受市場歡迎,那麼這些成本就會變成打水漂。所以就有了成本比較低的 MVP,先用 MVP 拿去市場做驗證,若是可行就可以做成 Product 正式拿去賣,若是不行就及早收手改做下一個 MVP,避免資源浪費在沒有價值的產品上。

那為什麼 MVP 研發成本會比較低呢?正如前面所述,MVP 只會含有部分功能,一些比較無關緊要的功能就會選擇先不做,比如說登入功能只有支援帳號密碼,不支援OAuth,甚至連忘記密碼等功能都沒有、又比如說,在業務功能上,只做好具重要的部分,就像是音樂播放器只做好播放功能,還不支援推薦歌曲。在界面上可能也會先用現成的框架與配色,而不會做出特別的設計。諸如此類,先只實作最核心的功能,確定這個特色是受到市場青睞的,再正式投入研發。

另外,欠下技術債也是 MVP 研發成本低的原因。除了因為 MVP 的使用者少,比較不用先考慮的效能問題,或是先不考慮未來的可擴充性,所以不用特別客製化好的架構外,另一個重要的原因就是 MVP 很常是驗證完市場就封存的專案,並在展開下一個 MVP,要趕緊找到商機,搶在對手前面推出產品。如此的替換率高、趕時程,程式設計師寫出來的程式碼也不會被稱為優美,甚至充滿了各種壞味道,就因為知道這個專案會被封存,才能比較放心的欠下這一卡車的技術債。

沒錯,到這裡就呼應了昨天尾聲的問題:「技術債是可以不還的嗎?」。事實上 MVP 就是一種可以考慮不還技術債的情境,因為這個專案在完成他的任務後就不會再繼續維護了,是屬於生命週期較短的專案,而當軟體不再被使用時,欠下的債理所當然也就不用還了。MVP 是如此,而舉凡在生命週期較短的專案中欠下的技術債,都是屬於可以考慮不還的,畢竟耗費時間在重構上,可能軟體都已經結束階段性目的或是市場了。有些情況,就是公司必須不斷搶在對手前面推出產品,但這些產品的生命週期都不常,可能賺完第一波,後面的效益就不大了,公司就會放棄這個產品,往下一個標的前進。如果這時候還跟老闆說要花時間把產品重構,那老闆大概會對你大聲咆哮,說你搞不清楚狀況。

但是,事情不一定都會這麼理想。雖然可以因為是 MVP 所以欠下一屁股技術債,但最怕的就是老闆因為 MVP 大受好評,就乾脆當作產品來賣了,一旦這個決策落實了,就會是研發團隊噩夢的開始。所以老闆和研發團隊都必須理解 MVP 和 Product 的差別,以及現在研發的是哪個。若是 MVP 驗證得到良好的回饋,要推出相關產品,就必須讓研發團隊基於驗證得到的結果,再寫一個具有可維護性的 Product,而不是拿現成的 MVP 來用。不然好不容易得到的回饋,卻因為直接拿 MVP 來用,導致後面 Bug 叢生、效能低落、研發成本過高,讓市場失望、搞砸信譽,實在是功虧一簣。


上一篇
其實技術債是可以被管理的
下一篇
程式碼風格要點在於一致,而不是優劣
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言