從 60 個方案交付聊聊軟體開發經驗
2021/12/22閱讀時間約 4 分鐘
RevtelTech 忻旅科技 https://www.revtel.tech/
email：[email protected]
facebook：https://www.facebook.com/RevtelTech/
回顧過往，參與協作了超過 60 個軟體方案。
曾接觸過合作內容差異頗大，比如
- 規模自海外獨角獸到本土新創
- 內容從專案、產品到商業題目都有
- 技術涵括 Web、APP、IoT 和系統
- 遍及電商、物流、醫療、金融、展覽、印刷等多個領域
- 分工自純諮詢、部分協力、完整開發到後續維運都有
- 除開發及諮詢之外，也協助團隊組建
仔細看看也還蠻多面向的，未來好像可以就這些部分做些分享交流。但總會想到一件事，到底這些開發裡頭到底都在做些什麼？
應用軟體的開發在於擷取事物運行邏輯
出社會後經歷過大公司、新創公司到自己創業，總不免在思考過往訓練給了我什麼，這幾年才模模糊糊的感覺到軟體工程的訓練給了我一把拆解現實邏輯的手術刀。
軟體系統是在電腦那頭、虛擬世界中 重新模擬現實世界發生的流程並滿足現實需求 。比如飯店住房查詢的系統可以想像成在那一端有個虛擬助手替你查表，而先前的開發過程，則是在幫那位助手打造屬於他的工具（如記錄簿等)。
有趣的點也在於，既然是在虛擬世界重新建構流程，是以能 在一定程度上消減來自現實世界的種種限制 。以剛剛的住房虛擬助手為例，可控範圍內能讓館內人員直接跟客戶做互動來增進效率，但這在現實生活中卻會因為政治、組織架構或各種風險考量而無法實作。
考量到「 系統 = 人 + 軟體」，使得這會是一個不斷反覆抽離、拉近的思考過程，考驗在於如何適當把握抽象層次及實作深度。並且 幾乎永遠只有當前最佳解而未必存在全局最佳 。
強弩之末，勢不能穿魯縞
身為設計師是否常常覺得某些著名產品的體驗不好？比如該對齊沒對齊或重要功能拜放在很難找到的地方。
身為工程師是否常常覺得某些知名服務有 bug 或者順暢度不足？比如前景背景的推播順暢度或奇怪的死當狀態。
換個場景思考，是否常常覺得許多政治人物的言論或大公司的決策很荒誕而脫離現實？但要這麼理解， 如果某些事物的跟我們想的不一樣，除非能完全確認我們勝過那些團隊的集體智能，不然最有可能的其實是我們並沒有看到問題的真正本質及該處境的客觀限制。
強弩之末，勢不能穿魯縞。力所難及之處才是真正要挑戰的地方，重點應該在於如何把握每個時段的關鍵問題。當然，如何去看穿真實限制也會是個永恆課題。
試著找尋侷限性
對慣於大量吸收資訊的現代人來說，自多管道接觸資訊並不是什麼太困難的事情（反而篩選成了一個議題！）。想像一下上一輩人如何看待我們在同一時間自多渠道（如 Line、Facebook）吸收資訊，就可以約略感受資訊管理方式存在某種時代性的天花板。
要很小心的去覺察自己認知的隱性極限，方方面面的框架不只形塑了你的世界觀同時也成為了往前的制動器。
這種隱性天花板往往不只是盲點，更可能是一整個維度的丟失。
真正需要在意的是可控性
所以要如何看待真實世界的軟體系統設計？
回想下這些年很常在吵的課綱議題。過往我們的學習經驗，是由主管機關每隔一段時間修訂課綱，再讓各大出版商根據課綱填充內容。基於這種框架，我們就能相對明確的去討論是大方向不正確或是具體實作有問題。
軟體開發亦然。
自上而下的框架能很大程度作為總覆蓋面的方向指引（這裡會有很多方法論，暫且不談），藉由鎖住商務需求及商務時程兩個維度，能有效避免走錯方向。
可畢竟軟體開發是一個動態的雙向過程，所以也不要忘記自下而上的反饋。藉由這個反饋鎖住實作校正這個維度，能有效避免雖然方向對了，但卻挑錯路走的窘境。
追求的都是可控性。倘若開發時程的進行都能在巨觀及微觀尺度上被把握住，那風險自然就被降低了。
不要停止前進
說到底要告訴自己的也在於 不要停止前進 的這句老掉牙的話。知道的總是太少、可能性總是太多
為什麼會看到廣告
18會員
33內容數
留言0
查看全部
