延伸閱讀
0 →1 ? 1 →100 ? 軟體顧問到底在顧什麼？：https://revteltech.pse.is/sw-consult-what
軟體開發一個很迷人的地方是可以在架空的世界（電腦世界）中重新思考、解構並處理真實世界的問題。但要怎樣真正有效的解決問題就很看各家功力了。
這篇文章我們暫且放下溝通及流程規劃的議題，聚焦來看看純粹領域差異造成的困難以及該怎麼面對。
混搭風 … 過往接觸過超過 10 個領域
回顧過往曾經觸碰過的領域真的滿多，茲列舉幾個- 導航系統上的感測器軟體開發及測試
- 睡眠偵測 IoT 設備的系統架構規劃
- 備孕產品的 APP 內容設計及開發
- 獨角獸等級的電商 APP 開發
- 港區物流的後端流程系統規劃開發
- 美股看盤 APP 的開發及產品設計
- 隨選電系的電商及後端架構規劃
- 印刷領域 ERP 及電商邏輯規劃
其實還可以往下列舉，對我來說每次的課題都是學習及挑戰。
跨越這麼多領域不會累嗎？當然還是會的。但生活總是要過，只能試著搞定他囉！
設法有效率認知去模型領域 — 參考後端設計方法
每個不同領域都有自己的特性及知識背景，過往我會從三個角度下去思考跟掌握：
- 靜態的背景知識
每個領域必然有屬於自己的一組底層知識結構，散見在名詞定義等地方。先將這部分掌握可以快速理解在這個知識體系中哪些部分是重要的。比如在電商領域中庫存就是一個重要概念，不同的庫存模型一定程度反映了這個商業系統的收費及販售框架。 - 動態的運作邏輯
系統必然是動態的，基於背景資訊之間的互動描述了這個系統的複雜度及運作圖像。比如基於庫存這件關鍵字下去觀察，其外圍的保留及消減邏輯便是這個電商系統的重要流程。 - 連結的隱性流程
系統畢竟是人和軟體的綜合體，藉由 1 跟 2 的分析之後下一步便是要觀察真實運作時與其互動的 SOP 到底長怎樣。一樣回到庫存管理的邏輯來看，營運人員怎麼在多通路間分派這些庫存反映了許多事，如員工訓練流程及該產品在真實世界的特性。
在這裡大家有沒有發現這裡的分析跟後端在思考架構時很像？資料庫關聯的設計、跨表間的互動及API 的覆蓋方式便是如此。
其實方法還是很多的，但明確找個自己的思考底層框架非常重要。
不夠深入怎麼辦？套入一些流程方法論來面對
講到這裡可能會有人好奇，一個好用的系統必然有其特殊的邏輯存在，這些部分甚至是外人非常難以理解的，那我們要怎麼可以如原生一般的來發現及解決這些事情呢？
其實每件事情都是越來越複雜的，就如同我們過往在學習的歷程中也是由淺入深。面對自己的理解及系統的覆蓋率不夠深入的問題，首要的原則是接受它的不完美。
這時候一些如敏捷開發之類的思考方式很能幫忙這段，敏捷的意思不是快，但它能很好的協助你逐步的在過程修正系統並和外部環境融洽的結合。甚至基於一個好的流程節奏，放心的做一些 workaround 也無所謂，只要知道何時會修復、該朝哪邊修復，這些個不一定完美的 workaround 反而可以很好的看出資源的限制、知識的局限以及當下最重要的問題。
混搭混出新滋味 — 或許你的問題早就被解決了
最後來講一個在這些跨域規劃及開發中有趣的地方，很有可能你要面對的問題在其他領域已經被解決了。
之所以可能發生這件事情我想大概是因為人畢竟只有兩手兩腳，面對問題的解決方法存在某些共性。在剝除掉一些特有的表層邏輯之後，其內在機理可能都很類似。
這裡舉個例子，先前在協助醫療系統設計的時候有個目標是要適當的將每天蒐整而來的醫療紀錄交由不同層級的醫師及技師進行校正，當中還穿插演算法的自動標註。這裡該如何設計整個框架呢？
在深入思考後我發覺他跟過往接觸過的兩個任務很接近
- 翻轉教育的教師批改系統 — 這裡有完整的權限管理架構
- 線上課程系統的互動設計 — 這裡有完整的資訊分享設計
如此一來自然能有比較高的把握度去規劃系統使用情境及框架了！
終極目標是建構起一個通用的思考範式
其實做這些事情看起來很雜，但背後的目的卻可能是能一以貫之的：搭建起一個屬於自己的認識世界的方式以及解決問題的框架。
這個世界總是有解決不完的問題，身為程式設計師的我們面對的這些挑戰就是不斷在解構及重建的過程。也是因為這樣軟體開發才是這麼的有趣。
