從 60 個方案交付聊聊軟體開發經驗
閱讀時間約 4 分鐘
RevtelTech 忻旅科技 https://www.revtel.tech/
email：contact@revteltech.com
facebook：https://www.facebook.com/RevtelTech/
回顧過往，參與協作了超過 60 個軟體方案。
曾接觸過合作內容差異頗大，比如
- 規模自海外獨角獸到本土新創
- 內容從專案、產品到商業題目都有
- 技術涵括 Web、APP、IoT 和系統
- 遍及電商、物流、醫療、金融、展覽、印刷等多個領域
- 分工自純諮詢、部分協力、完整開發到後續維運都有
- 除開發及諮詢之外，也協助團隊組建
仔細看看也還蠻多面向的，未來好像可以就這些部分做些分享交流。但總會想到一件事，到底這些開發裡頭到底都在做些什麼？
應用軟體的開發在於擷取事物運行邏輯
出社會後經歷過大公司、新創公司到自己創業，總不免在思考過往訓練給了我什麼，這幾年才模模糊糊的感覺到軟體工程的訓練給了我一把拆解現實邏輯的手術刀。
軟體系統是在電腦那頭、虛擬世界中 重新模擬現實世界發生的流程並滿足現實需求 。比如飯店住房查詢的系統可以想像成在那一端有個虛擬助手替你查表，而先前的開發過程，則是在幫那位助手打造屬於他的工具（如記錄簿等)。
有趣的點也在於，既然是在虛擬世界重新建構流程，是以能 在一定程度上消減來自現實世界的種種限制 。以剛剛的住房虛擬助手為例，可控範圍內能讓館內人員直接跟客戶做互動來增進效率，但這在現實生活中卻會因為政治、組織架構或各種風險考量而無法實作。
考量到「 系統 = 人 + 軟體」，使得這會是一個不斷反覆抽離、拉近的思考過程，考驗在於如何適當把握抽象層次及實作深度。並且 幾乎永遠只有當前最佳解而未必存在全局最佳 。
強弩之末，勢不能穿魯縞
身為設計師是否常常覺得某些著名產品的體驗不好？比如該對齊沒對齊或重要功能拜放在很難找到的地方。
身為工程師是否常常覺得某些知名服務有 bug 或者順暢度不足？比如前景背景的推播順暢度或奇怪的死當狀態。
換個場景思考，是否常常覺得許多政治人物的言論或大公司的決策很荒誕而脫離現實？但要這麼理解， 如果某些事物的跟我們想的不一樣，除非能完全確認我們勝過那些團隊的集體智能，不然最有可能的其實是我們並沒有看到問題的真正本質及該處境的客觀限制。
強弩之末，勢不能穿魯縞。力所難及之處才是真正要挑戰的地方，重點應該在於如何把握每個時段的關鍵問題。當然，如何去看穿真實限制也會是個永恆課題。
試著找尋侷限性
對慣於大量吸收資訊的現代人來說，自多管道接觸資訊並不是什麼太困難的事情（反而篩選成了一個議題！）。想像一下上一輩人如何看待我們在同一時間自多渠道（如 Line、Facebook）吸收資訊，就可以約略感受資訊管理方式存在某種時代性的天花板。
要很小心的去覺察自己認知的隱性極限，方方面面的框架不只形塑了你的世界觀同時也成為了往前的制動器。
這種隱性天花板往往不只是盲點，更可能是一整個維度的丟失。
真正需要在意的是可控性
所以要如何看待真實世界的軟體系統設計？
回想下這些年很常在吵的課綱議題。過往我們的學習經驗，是由主管機關每隔一段時間修訂課綱，再讓各大出版商根據課綱填充內容。基於這種框架，我們就能相對明確的去討論是大方向不正確或是具體實作有問題。
軟體開發亦然。
自上而下的框架能很大程度作為總覆蓋面的方向指引（這裡會有很多方法論，暫且不談），藉由鎖住商務需求及商務時程兩個維度，能有效避免走錯方向。
可畢竟軟體開發是一個動態的雙向過程，所以也不要忘記自下而上的反饋。藉由這個反饋鎖住實作校正這個維度，能有效避免雖然方向對了，但卻挑錯路走的窘境。
追求的都是可控性。倘若開發時程的進行都能在巨觀及微觀尺度上被把握住，那風險自然就被降低了。
不要停止前進
說到底要告訴自己的也在於 不要停止前進 的這句老掉牙的話。知道的總是太少、可能性總是太多
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
在先前文中，有提到我在 2020 年時任職軟體新創公司時，意識到自己在行銷領域的有限性與不確定性，轉而想投入與產品開發有相關的角色，其中最一開始我想要轉職的並不是軟體工程師，而是 UIUX 設計師⋯⋯
親愛的讀者
感謝你提出這個富有挑戰性且極具時代感的問題。程式設計，這門技術宛如一把打開數位世界的鑰匙，讓人得以探索無限的可能性。在這個科技日新月異的時代，程式設計的魅力不僅僅在於其實用性，還在於它能夠改變我們看待問題和解決問題的方式。
然而，你提問的核心不僅是程式設計本身，而是它是否能成為你
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
相較於接案公司，說到自有軟體產品的企業，普遍大家會自動套上粉紅濾鏡，覺得產品公司就是比較好，不像接案毛利低、又常常有時程壓力。
在網路上也可以找到各式各樣的文章告訴你接案公司的各種地獄故事，覺得如果有選擇的話，可以做產品就不要接案，就連以前的我也都有一顆產品夢。
但事實真的是這樣嗎？
ERP系統導入，有兩種常見的方式:
1。 專案開發，或者說完全客製，也就是成立專案，招一批人，量身訂做寫出公司使用的ERP系統。
2。 套裝軟體，像SAP、Oracle和Microsoft都提供ERP系統，顧問負責導入與規劃客製功能，因為套裝ERP系統不儘然所有功能都符合企業的需求，所以有些需求
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
先來幫大家複習一下我的轉職歷程，簡短來說，我是先到了一間軟體公司負責軟體的中英翻譯、行銷，讓我對打造軟體產品起了濃厚的興趣。
轉職前端後，我在台灣北部知名的接案公司待了一年半，後續開啟我的自有產品開發之路，以撰寫文章當下的現狀來說，我在一間台灣知名老牌的財經平台寫了八個月的軟體產品後，投入到⋯⋯
在先前文中，有提到我在 2020 年時任職軟體新創公司時，意識到自己在行銷領域的有限性與不確定性，轉而想投入與產品開發有相關的角色，其中最一開始我想要轉職的並不是軟體工程師，而是 UIUX 設計師⋯⋯
親愛的讀者
感謝你提出這個富有挑戰性且極具時代感的問題。程式設計，這門技術宛如一把打開數位世界的鑰匙，讓人得以探索無限的可能性。在這個科技日新月異的時代，程式設計的魅力不僅僅在於其實用性，還在於它能夠改變我們看待問題和解決問題的方式。
然而，你提問的核心不僅是程式設計本身，而是它是否能成為你
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
相較於接案公司，說到自有軟體產品的企業，普遍大家會自動套上粉紅濾鏡，覺得產品公司就是比較好，不像接案毛利低、又常常有時程壓力。
在網路上也可以找到各式各樣的文章告訴你接案公司的各種地獄故事，覺得如果有選擇的話，可以做產品就不要接案，就連以前的我也都有一顆產品夢。
但事實真的是這樣嗎？
ERP系統導入，有兩種常見的方式:
1。 專案開發，或者說完全客製，也就是成立專案，招一批人，量身訂做寫出公司使用的ERP系統。
2。 套裝軟體，像SAP、Oracle和Microsoft都提供ERP系統，顧問負責導入與規劃客製功能，因為套裝ERP系統不儘然所有功能都符合企業的需求，所以有些需求
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
先來幫大家複習一下我的轉職歷程，簡短來說，我是先到了一間軟體公司負責軟體的中英翻譯、行銷，讓我對打造軟體產品起了濃厚的興趣。
轉職前端後，我在台灣北部知名的接案公司待了一年半，後續開啟我的自有產品開發之路，以撰寫文章當下的現狀來說，我在一間台灣知名老牌的財經平台寫了八個月的軟體產品後，投入到⋯⋯