踏入工程師生涯也十幾個年頭了，這些年工作主體逐漸從開發轉向諮詢規劃。遊走於兩者之間總會碰到一些相持不下的時刻，比如 PM 覺得某某功能很重要，可工程部門一直想要說服說這個做不了。處理得好就是雙贏，處理得不好往往就是不歡而散。
不斷在各個維度間找平衡及妥協 — 這就是真實世界的開發。延續著之前的分享「從 60 個方案交付聊聊軟體開發經驗」，這裏繼續來拋個磚。
工程始終來自於實踐，我們也試著慢慢去分享過往開發經驗，歡迎大家一起來討論～
工程師視角 vs. 產品設計視角
當一個新的產品及服務放到你面前的時候，你是怎麼去理解一個產品的？
會想去找說明書來研究還是試著玩來去逼近整體圖像。前者追尋「how」比較接近工程師思維，而後者探討「what」可能更接近產品經理。這是個很簡略的敘述跟刻板的印象，但我想講的是一個事物有多種不同的觀看方式。
那所以問題就來了，不管你怎麼去觀看，事物總是一步一步建構起來的，失之方向與失之細節是同等危險的。
資訊技術快速進步，但本質性商務問題還是個個不同
二十年前如果能開發出網路相簿系統會是一件轟動市場的事情。但今天如果你要一個相簿，一兩天開發出雛形並不是太困難。
是什麼讓這件事難度下降？其實難度並沒有下降，只是技術進步，各式各樣的工具大幅度解決了通用問題 — 可本質的商務需求疑難卻依然還在 (試想一下，二十年前相簿系統，其需求規格和今天大不相同的)
站在巨人的肩膀確實能看得更遠，但不要忘記巨人不停在長高，如何站穩變成了一個現代開發避不開的問題。
以下我們就以兩個常見的需求來做些討論。
範例一：什麼是社群登入？
適當的使用社群登入能有效縮短用戶接入服務的難度，更能夠在一定程度上取得 email 這些進階資訊。看起來在建構帳戶系統時把 Google、Facebook 這些社群登入納入規格似乎是個不太需要討論的事情。
但我們來想一下當一個系統支援社群登入時代表了什麼其他意義？
- 社群登入其實是第三方整合，要注意維運的規劃
社群登入作為 Google 及 Facebook 提供的服務，相關規格及條款是掌握在他們手上的。所以導入之後就代表維運新增需要持續追蹤的任務。 - 社群登入可取得的資料不盡相同，要注意系統內如何統合不同來源的資料
如果你的服務會需要對應到真實世界的用戶身份(如號碼或 email)，如果不同社群登入給的資料不同該怎麼辦？該如何以 UI/UX 設計收回缺失資料？ - 成熟的商業服務可能跨 WEB / APP 等多構面，要適當規劃開發方向
當今的軟體服務可能會在多種載體上提供服務，如 APP、Web 甚至純桌面程式。當你決定納入社群登入功能後，就要考慮多種載體如何整合的後續工程問題。(延伸：可以參考一下微前端 (micro-frontend)的概念)
範例二：什麼是 APP 推播？
如果請你列出 APP 有哪些 Web 不具備的能力，相信推播功能應該會是前幾名的答案(當然 Web 有自己的推播機制，但相對不成熟)。作為作業系統原生提供的通知機制，在很多情境中推播可以很好的起到黏住用戶及行銷推廣的目的。看起來整合這個功能也是勢在必行囉。
可當我們在提起推播功能整合時，到底又代表了什麼呢？
- 推播本質上是會員系統的擴充
蠻多開發者在關注推播功能時往往只注意價格及導入難度，卻忽略了其實推播是植基於會員系統之上的互動。所有會員系統可能遇到的議題都得在這裡注意，比如是否允許多裝置及如何控管帳號合併等。更有甚者，有多少系統因為用了 AWS 的推播功能而使整個會員系統得完全進到 AWS 生態系。 - 推播內容管理牽涉到後續行銷的流程
假如你的系統有多語系甚至希望做到不同載體有不同訊息，那後台系統該如何設計呢？這裡需要引入的視角是行銷及品牌經營，這些衍生的參與者該怎樣做需求釐清及控管也是個工程。 - 用戶對於推播的授權到哪個層級需要被討論
推播是把雙刃劍，對用戶來說它是資訊通知或是垃圾訊息取決於頻次即可控制的粒度。推播的底層單位是「則」，但架構在商業行為上卻往往是「情境」。該如何讓用戶能控制想看到的範圍也涉及系統設計及實作。
為山九仞，功虧一簣？
簡單地舉了兩個例子做個觀察，希望能讓大家從中看到一點什麼。
「系統上線後沒有 bug 只有 feature」這句話看似戲謔卻也在一定程度反應了現代工程開發的真實困境。很多軟體開發的坑是可以在初期防範於未然的，畢竟解決 bug 的最好方式就是別讓 bug 出現。
平常跟協作方溝通時我常常將之稱為「功能的厚度」，指的是那些乍看之下簡單、深想卻覺得並不容易的狀況。事實上人力有時而窮，不可能做好完整規劃再出發(其實也不太可能算無遺策)，只能靠時時注意這些潛在的功能影響面來確保一路平安。
而如何徹底解決這些問題 … 應該會是個永久的追尋，畢竟它來自於對服務價值及工程掌握度的永恆拉扯。但話又說回來，這也是軟體產品開發如此吸引人的原因不是嗎？
