用最少的程式製作 PoC（概念驗證）

「什麼時候會有訂飲料系統呢？」從加入五倍紅寶石軟體開發到現在已經過了五年，每次都會有人提出來，接下來就不了了之。我們是一間九成以上都是工程師的公司，理論上像這樣的系統不應該那麼困難才對，為什麼就是沒辦法做出來呢？

半個月前剛好有同事自告奮勇說要來嘗試，剛好路過時就看到同事們在畫 ERD（Entity-Relation-Diagram，物件關係圖）我心想，這下糟糕了！

幾年前，我也是這樣自告奮勇的去製作，很明顯地就在這個動作的下一個步驟馬上遇到問題，接下來的結局是我們又再次等到有人提起這件事情，然後不斷的重複。

不論是自己做的玩具、客戶的專案，我們大多會遇到的就是想要盡可能的把東西完善、功能要豐富才算是一個完整的專案，然而這就是很多時候我們開發時間非常久、成本非常高的原因之一。

實際上，從 MVP（Minimum Viable Product，最小可行產品）的角度來看，我們的目標是要能夠完成一個有價值的產品，同時這個產品還必須是最小的。現實生活中一次就成功的機率不大，因此我們需要製作 PoC（Proof of Concept，概念驗證）來驗證，直到測試出可以驗證產品價值的概念為止。

以訂飲料系統來說，至少要有品項、訂單以及可以讓同事填寫資訊的功能才算是最基本的功能，使用工作上習慣的開發框架來製作似乎是非常合理的事情，而且我們已經把功能限縮到「最基本」的狀況，這樣難道還不夠「少」嗎？

確實，我們工作擅長使用的 Ruby on Rails 依舊還是軟體業界中開發網站數一數二快速的開發框架，很少的功能搭配上一個優秀的框架，確實可以快速的去製作出一個系統。

其實，我們還有更好的方法。最簡單的就是用 Google 表單製作一個簡單的表格，然後讓大家填寫，實際上問題就很快地被解決了而且沒有什麼困難。

假設我們已經想到這樣的做法依舊還是希望有一個系統，就表示這個工具還有可以改進的地方，可能是要處理的業務變複雜、工作量變大等等，等到這個時候我們才有必要加入程式的部分。

近年熱門的 No Code、Low Code 工具，實際上就是提供了這個層級的問題。我們可以想像，未來的工程師應該具備怎樣的能力，是不是就是在 Low Code 之上普通人無法處理的問題，才會需要我們。像是使用 Serverless 技術，或者開發完整的 Web Application 等等複雜、能夠對應大規模使用的情境，若是我們無法抵達這個層級，勢必會在未來被淘汰。

實際上，我們會希望有訂飲料系統就是希望能整合公司內部的通訊軟體、限制同事填寫等等，或者改善每次都要製作表單的人工問題。

那麼，下一步該怎麼做？拿出 Ruby on Rails 回到一開始造成「沒有下文」的狀況嗎？我給同事的建議是使用 Google 的 Spreadshet 搭配 App Script 功能，我們可以利用 Spreadsheet 的功能讓負責訂飲料的同事快速的編輯品項，同時也很好的統計，以及能夠利用 App Script 的網頁發布功能製作簡單的訂單畫面。

在這幾年工作的經驗中，最熱門的就是「敏捷開發」的概念，從很新的概念變成一個軟體公司必備的概念，然而這樣的概念實際上運作起來是怎樣呢？我認為其中一個就是小步的前進，盡可能地用最少的力氣去實驗一個「概念」（像是訂飲料）然後在這個前提下，繼續往下尋找可以改進的地方，並且繼續改善直到一個產品的雛形出現甚至能夠盈利。

事實上，這也是工程師很習慣一開始就用「程式」解決問題所造成的狀況，我們逐漸地失去一些有創意的方式去解決問題，很多時候也許換個做法、方案就能解決問題甚至改善用程式去處理的限制。

同時，當概念跟規格足夠清晰的時候，我們反而更容易地用更少、更優雅的方式去寫一段程式，還能夠同時具備彈性跟可維護性，然而這樣的程式大多是透過多年經驗累積起來的知識，想要加速這樣的流程就只能在有限的時間內爭取更多的嘗試，因此控制規模跟製作的時間就變得重要。

封面圖片使用 Unsplash 上 Isaac Benhesed 的作品，如果有想聽的主題可以透過匿名提問告訴我。