有想法之後接下來就是執行的階段，在我過去的工作經驗中，大多數的客戶確實有想法也準備開始執行，這些想法會隨著時間跟討論細節的完善逐漸增加，最後就會變成一個完整的產品，然而這樣就違背了產品原型的目的。
產品原型
大多數情況下，我們會認為產品原型是一個「完整可用」的東西叫做產品原型，然而這樣的系統即使是在數個月內也是難以開發完成，在開發軟體的過程中除了功能之外還需要測試跟調整。
也因此，在科技業很常說的 MVP（Minimum Value Product，最小可行產品）指的是只具備核心功能的原型，很多時候可能是沒有撰寫程式或者使用 Low-Code（低代碼）工具來完成的，主要是去驗證商業模式的可行性。要做到這點實際上是很困難的，因為我們必須不斷的刪減想法去找到最為核心的問題，有時候我們可能刪減到最後發現並沒有這樣的東西，最後就只能去尋找其他方案。
敏捷開發
要討論到 MVP 的話很常會一起出現的是敏捷開發（Agile）這個詞，大多數時候我們看到這個單字都會覺得是「很快」的意思，然而在一些業界前輩的討論中更偏向用適應這個單字去討論，如果從字義上來看 Agile 還有靈活的意思。
簡單來說，敏捷開發並非「開發快」而是「反應快」的概念，如果安排太多功能、想法要去實行，就會讓開發的不斷的被各種東西卡住，正確的應用這樣的觀念是縮短檢討（Review）的過程，根據現況不斷的調整我們要實現的功能，這也是比較為大眾所知的 Scrum 會採取一到兩週的 Sprint（衝刺）來安排，讓原本數月才會檢查一次的流程縮短到一到兩週。
從這點來看，大多數公司對敏捷開發的推行難以實踐的問題時企業文化上的，當負責人無法說服其他人接受這樣的想法、協調不同單位的需求跟優先度，敏捷開發就會因此被各方「硬插進來」的要求卡住，進而讓重要功能的進度延宕。
資源有限
回到我跟爸爸的專案上，因為我們幾乎是沒有任何資源，我平常也有自己的工作、創業的任務等等，要在有限的時間跟基本上是沒有資金的狀況下開發，就必須完全落實 MVP 和敏捷兩個精神，否則是很難實踐的。
因此我們在最初期只做了關鍵的功能，掃描 QRCode、自動計算回饋金額、顯示結果。
接著，爸爸就把這樣的東西拿去給他的潛在客戶嘗試以及使用，並且找到重要的功能回饋回來，並且根據每一次的回饋進行調整。
接下來經過一個月的調整跟打磨，最終上線的版本則是套用了簡單的版型、支援顯示回饋的紀錄、可以邀請朋友等等功能。
至於更新，我們會將一兩個小功能討論好優先順序，接下來再完成以及測試後，直接的釋出到正式版本上，也就是每次都少量修改來構成較大的功能，同時增加釋出的頻率來不斷對應需求。
這系列的文章未來會不定期的根據近況更新在開發過程中發生的一些事情。
封面圖片使用 Unsplash 上 Alexander Andrews 的作品
