用最少的程式製作 PoC(概念驗證)

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

過度設計

半個月前剛好有同事自告奮勇說要來嘗試,剛好路過時就看到同事們在畫 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 的網頁發布功能製作簡單的訂單畫面。
實際成品畫面

小步前進

在這幾年工作的經驗中,最熱門的就是「敏捷開發」的概念,從很新的概念變成一個軟體公司必備的概念,然而這樣的概念實際上運作起來是怎樣呢?我認為其中一個就是小步的前進,盡可能地用最少的力氣去實驗一個「概念」(像是訂飲料)然後在這個前提下,繼續往下尋找可以改進的地方,並且繼續改善直到一個產品的雛形出現甚至能夠盈利。
事實上,這也是工程師很習慣一開始就用「程式」解決問題所造成的狀況,我們逐漸地失去一些有創意的方式去解決問題,很多時候也許換個做法、方案就能解決問題甚至改善用程式去處理的限制。
同時,當概念跟規格足夠清晰的時候,我們反而更容易地用更少、更優雅的方式去寫一段程式,還能夠同時具備彈性跟可維護性,然而這樣的程式大多是透過多年經驗累積起來的知識,想要加速這樣的流程就只能在有限的時間內爭取更多的嘗試,因此控制規模跟製作的時間就變得重要。
給同事的下一個任務——優化介面,未來有機會可以談談工程師也能做的介面設計

封面圖片使用 UnsplashIsaac Benhesed 的作品,如果有想聽的主題可以透過匿名提問告訴我。
為什麼會看到廣告
52會員
40內容數
軟體工程師逐漸變成一個熱門的職業,當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢?這系列的專欄會分享日常工作中的經驗以及一些案例分析,讓我們一起努力成為一位更優秀的軟體工程師吧!
留言0
查看全部
發表第一個留言支持創作者!