Sam Huang
Sam Huang

[ https://www.sam-huang.info/ ] 一扁帽,一壺酒,一溪雲,佔得人間一味愚,此心安處是吾鄉

軟體功能的厚度?— 從社群登入及推播說起

(编辑过)
踏入工程師生涯也十幾個年頭了,這些年工作主體逐漸從開發轉向諮詢規劃。遊走於兩者之間總會碰到一些相持不下的時刻,比如 PM 覺得某某功能很重要,可工程部門一直想要說服說這個做不了。處理得好就是雙贏,處理得不好往往就是不歡而散。

軟體系統開發顧問:
https://consult.revtel.tech/

踏入工程師生涯也十幾個年頭了,這些年工作主體逐漸從開發轉向諮詢規劃。遊走於兩者之間總會碰到一些相持不下的時刻,比如 PM 覺得某某功能很重要,可工程部門一直想要說服說這個做不了。處理得好就是雙贏,處理得不好往往就是不歡而散。

不斷在各個維度間找平衡及妥協 — 這就是真實世界的開發。延續著之前的分享「從 60 個方案交付聊聊軟體開發經驗」,這裏繼續來拋個磚。

工程始終來自於實踐,我們也試著慢慢去分享過往開發經驗,歡迎大家一起來討論~

RevtelTech

致力於打通線上線下最後一哩路medium.com

工程師視角 vs. 產品設計視角

當一個新的產品及服務放到你面前的時候,你是怎麼去理解一個產品的?

會想去找說明書來研究還是試著玩來去逼近整體圖像。前者追尋「how」比較接近工程師思維,而後者探討「what」可能更接近產品經理。這是個很簡略的敘述跟刻板的印象,但我想講的是一個事物有多種不同的觀看方式

那所以問題就來了,不管你怎麼去觀看,事物總是一步一步建構起來的,失之方向與失之細節是同等危險的

資訊技術快速進步,但本質性商務問題還是個個不同

二十年前如果能開發出網路相簿系統會是一件轟動市場的事情。但今天如果你要一個相簿,一兩天開發出雛形並不是太困難。

是什麼讓這件事難度下降?其實難度並沒有下降,只是技術進步,各式各樣的工具大幅度解決了通用問題 — 可本質的商務需求疑難卻依然還在 (試想一下,二十年前相簿系統,其需求規格和今天大不相同的)

站在巨人的肩膀確實能看得更遠,但不要忘記巨人不停在長高,如何站穩變成了一個現代開發避不開的問題。

以下我們就以兩個常見的需求來做些討論。

範例一:什麼是社群登入?

適當的使用社群登入能有效縮短用戶接入服務的難度,更能夠在一定程度上取得 email 這些進階資訊。看起來在建構帳戶系統時把 Google、Facebook 這些社群登入納入規格似乎是個不太需要討論的事情。

但我們來想一下當一個系統支援社群登入時代表了什麼其他意義?

  1. 社群登入其實是第三方整合,要注意維運的規劃
  2. 社群登入作為 Google 及 Facebook 提供的服務,相關規格及條款是掌握在他們手上的。所以導入之後就代表維運新增需要持續追蹤的任務。
  3. 社群登入可取得的資料不盡相同,要注意系統內如何統合不同來源的資料
  4. 如果你的服務會需要對應到真實世界的用戶身份(如號碼或 email),如果不同社群登入給的資料不同該怎麼辦?該如何以 UI/UX 設計收回缺失資料?
  5. 成熟的商業服務可能跨 WEB / APP 等多構面,要適當規劃開發方向
  6. 當今的軟體服務可能會在多種載體上提供服務,如 APP、Web 甚至純桌面程式。當你決定納入社群登入功能後,就要考慮多種載體如何整合的後續工程問題。(延伸:可以參考一下微前端 (micro-frontend)的概念)

範例二:什麼是 APP 推播?

如果請你列出 APP 有哪些 Web 不具備的能力,相信推播功能應該會是前幾名的答案(當然 Web 有自己的推播機制,但相對不成熟)。作為作業系統原生提供的通知機制,在很多情境中推播可以很好的起到黏住用戶及行銷推廣的目的。看起來整合這個功能也是勢在必行囉。

可當我們在提起推播功能整合時,到底又代表了什麼呢?

  1. 推播本質上是會員系統的擴充
  2. 蠻多開發者在關注推播功能時往往只注意價格及導入難度,卻忽略了其實推播是植基於會員系統之上的互動。所有會員系統可能遇到的議題都得在這裡注意,比如是否允許多裝置及如何控管帳號合併等。更有甚者,有多少系統因為用了 AWS 的推播功能而使整個會員系統得完全進到 AWS 生態系。
  3. 推播內容管理牽涉到後續行銷的流程
  4. 假如你的系統有多語系甚至希望做到不同載體有不同訊息,那後台系統該如何設計呢?這裡需要引入的視角是行銷及品牌經營,這些衍生的參與者該怎樣做需求釐清及控管也是個工程。
  5. 用戶對於推播的授權到哪個層級需要被討論
  6. 推播是把雙刃劍,對用戶來說它是資訊通知或是垃圾訊息取決於頻次即可控制的粒度。推播的底層單位是「則」,但架構在商業行為上卻往往是「情境」。該如何讓用戶能控制想看到的範圍也涉及系統設計及實作。

為山九仞,功虧一簣?

簡單地舉了兩個例子做個觀察,希望能讓大家從中看到一點什麼。

「系統上線後沒有 bug 只有 feature」這句話看似戲謔卻也在一定程度反應了現代工程開發的真實困境。很多軟體開發的坑是可以在初期防範於未然的,畢竟解決 bug 的最好方式就是別讓 bug 出現

平常跟協作方溝通時我常常將之稱為「功能的厚度」,指的是那些乍看之下簡單、深想卻覺得並不容易的狀況。事實上人力有時而窮,不可能做好完整規劃再出發(其實也不太可能算無遺策),只能靠時時注意這些潛在的功能影響面來確保一路平安。

而如何徹底解決這些問題 … 應該會是個永久的追尋,畢竟它來自於對服務價值及工程掌握度的永恆拉扯。但話又說回來,這也是軟體產品開發如此吸引人的原因不是嗎?

CC BY-NC-ND 2.0 版权声明

喜欢我的文章吗?
别忘了给点支持与赞赏,让我知道创作的路上有你陪伴。

加载中…

发布评论