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

更新於 發佈於 閱讀時間約 6 分鐘

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

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

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

raw-image


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

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

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

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

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

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

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

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

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

「人月神話」一書清楚闡述了軟體開發的本質性問題及附屬性問題

「人月神話」一書清楚闡述了軟體開發的本質性問題及附屬性問題

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

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

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

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

image from https://user65635.pse.is/3c43ts

範例二:什麼是 APP 推播?

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

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

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

image from https://pse.is/3b6hfx

為山九仞,功虧一簣?

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

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

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

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

















留言
avatar-img
留言分享你的想法!
avatar-img
Sam Huang的沙龍
18會員
33內容數
從超過 50 個合作經驗中擷取在系統開發、顧問及營運上的經驗及心得
Sam Huang的沙龍的其他內容
2023/12/05
沒有最正確的軟體架構,通常都需要隨著時間和發展階段進行修正和修改。系統最終會變成怎樣往往也和公司的管理方式及運作模式密切相關。 在過去的幾年裡,為應對需求,公司的軟體架構走向了 JAMSTACK 的風格。這裡分享一些關於這種架構的感受和經驗。
Thumbnail
2023/12/05
沒有最正確的軟體架構,通常都需要隨著時間和發展階段進行修正和修改。系統最終會變成怎樣往往也和公司的管理方式及運作模式密切相關。 在過去的幾年裡,為應對需求,公司的軟體架構走向了 JAMSTACK 的風格。這裡分享一些關於這種架構的感受和經驗。
Thumbnail
2023/11/29
作為程式開發者,每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常,就是像這樣子的 workaround 並沒有真正解決問題,只是徒留技術債,以後怎麼爆炸的都不知道。 workaround 聽起來真的是十惡不赦,不是嗎? 可凡存在必有道理,不如來聊聊 wor
Thumbnail
2023/11/29
作為程式開發者,每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常,就是像這樣子的 workaround 並沒有真正解決問題,只是徒留技術債,以後怎麼爆炸的都不知道。 workaround 聽起來真的是十惡不赦,不是嗎? 可凡存在必有道理,不如來聊聊 wor
Thumbnail
2023/09/23
「為什麼要維護?有 bug 你們就要負責啊,你們怎麼可以給我們有 bug 的東西!」 一瞬間我也是愣了一下,還差點被說服(?)。
Thumbnail
2023/09/23
「為什麼要維護?有 bug 你們就要負責啊,你們怎麼可以給我們有 bug 的東西!」 一瞬間我也是愣了一下,還差點被說服(?)。
Thumbnail
看更多
你可能也想看
Thumbnail
TOMICA第一波推出吉伊卡哇聯名小車車的時候馬上就被搶購一空,一直很扼腕當時沒有趕緊入手。前陣子閒來無事逛蝦皮,突然發現幾家商場都又開始重新上架,價格也都回到正常水準,估計是官方又再補了一批貨,想都沒想就立刻下單! 同文也跟大家分享近期蝦皮購物紀錄、好用推薦、蝦皮分潤計畫的聯盟行銷!
Thumbnail
TOMICA第一波推出吉伊卡哇聯名小車車的時候馬上就被搶購一空,一直很扼腕當時沒有趕緊入手。前陣子閒來無事逛蝦皮,突然發現幾家商場都又開始重新上架,價格也都回到正常水準,估計是官方又再補了一批貨,想都沒想就立刻下單! 同文也跟大家分享近期蝦皮購物紀錄、好用推薦、蝦皮分潤計畫的聯盟行銷!
Thumbnail
每年4月、5月都是最多稅要繳的月份,當然大部份的人都是有機會繳到「綜合所得稅」,只是相當相當多人還不知道,原來繳給政府的稅!可以透過一些有活動的銀行信用卡或電子支付來繳,從繳費中賺一點點小確幸!就是賺個1%~2%大家也是很開心的,因為你們把沒回饋變成有回饋,就是用卡的最高境界 所得稅線上申報
Thumbnail
每年4月、5月都是最多稅要繳的月份,當然大部份的人都是有機會繳到「綜合所得稅」,只是相當相當多人還不知道,原來繳給政府的稅!可以透過一些有活動的銀行信用卡或電子支付來繳,從繳費中賺一點點小確幸!就是賺個1%~2%大家也是很開心的,因為你們把沒回饋變成有回饋,就是用卡的最高境界 所得稅線上申報
Thumbnail
這是 30 天寫作挑戰的第 22 天。今天要分享的是:思考產品功能時,能提升思考品質的 Checklist 07–09
Thumbnail
這是 30 天寫作挑戰的第 22 天。今天要分享的是:思考產品功能時,能提升思考品質的 Checklist 07–09
Thumbnail
軟體開發是在虛擬的空間重新描述並解決現時的問題,多數時候並不存在正確答案。如何穿越這些不確定及未知就體現了開發者的功力以及對事物的把握度。 標題有點聳動,但且以這篇短文紀錄幾個印象比較深的、飛一陣後發現什麼節論都沒得到的可能作法(? 所以其實是要反著看 … 以下列舉三個常碰到的情況跟大家分享
Thumbnail
軟體開發是在虛擬的空間重新描述並解決現時的問題,多數時候並不存在正確答案。如何穿越這些不確定及未知就體現了開發者的功力以及對事物的把握度。 標題有點聳動,但且以這篇短文紀錄幾個印象比較深的、飛一陣後發現什麼節論都沒得到的可能作法(? 所以其實是要反著看 … 以下列舉三個常碰到的情況跟大家分享
Thumbnail
軟體開發一個很迷人的地方是可以在架空的世界(電腦世界)中重新思考、解構並處理真實世界的問題。但要怎樣真正有效的解決問題就很看各家功力了。 這篇文章我們暫且放下溝通及流程規劃的議題,聚焦來看看純粹領域差異造成的困難以及該怎麼面對。 回顧過往曾經觸碰過的領域真的滿多,茲列舉幾個
Thumbnail
軟體開發一個很迷人的地方是可以在架空的世界(電腦世界)中重新思考、解構並處理真實世界的問題。但要怎樣真正有效的解決問題就很看各家功力了。 這篇文章我們暫且放下溝通及流程規劃的議題,聚焦來看看純粹領域差異造成的困難以及該怎麼面對。 回顧過往曾經觸碰過的領域真的滿多,茲列舉幾個
Thumbnail
踏入工程師生涯也十幾個年頭了,這些年工作主體逐漸從開發轉向諮詢規劃。遊走於兩者之間總會碰到一些相持不下的時刻,比如 PM 覺得某某功能很重要,可工程部門一直想要說服說這個做不了。處理得好就是雙贏,處理得不好往往就是不歡而散。 當一個新的產品及服務放到你面前的時候,你是怎麼去理解一個產品的?
Thumbnail
踏入工程師生涯也十幾個年頭了,這些年工作主體逐漸從開發轉向諮詢規劃。遊走於兩者之間總會碰到一些相持不下的時刻,比如 PM 覺得某某功能很重要,可工程部門一直想要說服說這個做不了。處理得好就是雙贏,處理得不好往往就是不歡而散。 當一個新的產品及服務放到你面前的時候,你是怎麼去理解一個產品的?
Thumbnail
回顧過往,參與協作了超過 60 個軟體方案。 曾接觸過合作內容差異頗大,比如 仔細看看也還蠻多面向的,未來好像可以就這些部分做些分享交流。但總會想到一件事,到底這些開發裡頭到底都在做些什麼? 身為設計師是否常常覺得某些著名產品的體驗不好?比如該對齊沒對齊或重要功能拜放在很難找到的地方。
Thumbnail
回顧過往,參與協作了超過 60 個軟體方案。 曾接觸過合作內容差異頗大,比如 仔細看看也還蠻多面向的,未來好像可以就這些部分做些分享交流。但總會想到一件事,到底這些開發裡頭到底都在做些什麼? 身為設計師是否常常覺得某些著名產品的體驗不好?比如該對齊沒對齊或重要功能拜放在很難找到的地方。
Thumbnail
自春季末開始求職以來,大約也經過了半年,期間陸續接觸了近十間軟體企業,拓展了不少眼界。依循著前人「取之於社群,回饋於社群」的精神,我也希望能為產業貢獻一己之力,以一個求職者的視角,分享我親身體驗的軟體企業面試現況。
Thumbnail
自春季末開始求職以來,大約也經過了半年,期間陸續接觸了近十間軟體企業,拓展了不少眼界。依循著前人「取之於社群,回饋於社群」的精神,我也希望能為產業貢獻一己之力,以一個求職者的視角,分享我親身體驗的軟體企業面試現況。
Thumbnail
分享自己在B2B SaaS 產品公司的設計經驗,如何在不一樣的環境中,找到自己的價值。設計師在垂直產業中需要掌握的思考方向。
Thumbnail
分享自己在B2B SaaS 產品公司的設計經驗,如何在不一樣的環境中,找到自己的價值。設計師在垂直產業中需要掌握的思考方向。
Thumbnail
什麼樣的組織適合 “發動” 數位轉型?? 如果在台灣問這個問題,可以猜得到答案多半會是行銷相關的,其次才會是資訊相關的部門;為什麼會這樣說呢 ? 因為電子商務的行銷紅利雖然不如以往,但是對於電商相關的人才的需求極為強勁;從品牌端到平台端;從傳統零售到個人自
Thumbnail
什麼樣的組織適合 “發動” 數位轉型?? 如果在台灣問這個問題,可以猜得到答案多半會是行銷相關的,其次才會是資訊相關的部門;為什麼會這樣說呢 ? 因為電子商務的行銷紅利雖然不如以往,但是對於電商相關的人才的需求極為強勁;從品牌端到平台端;從傳統零售到個人自
Thumbnail
本系列文章前面的「資訊架構的三種基本角色」、「事前準備與內容提供者」、以及「評估資訊內容的影響力」三篇,都是關於資訊架構前期規劃的討論,所以本文想談談執行過程的思考,包括進行網站地圖(sitemap)、框線架構(wireframe)等設計時犯過哪些錯誤、以及更理想的作法。
Thumbnail
本系列文章前面的「資訊架構的三種基本角色」、「事前準備與內容提供者」、以及「評估資訊內容的影響力」三篇,都是關於資訊架構前期規劃的討論,所以本文想談談執行過程的思考,包括進行網站地圖(sitemap)、框線架構(wireframe)等設計時犯過哪些錯誤、以及更理想的作法。
Thumbnail
在前一篇〈資訊架構入門#1〉中,我們提到資訊架構的三個基本角色:使用者、資訊系統、以及資訊提供者;本文將繼續討論思考資訊架構的方式,希望讀者往後可以用新的方式來觀察使用的網站、app、甚至日常生活中各種數位產品的資訊架構。
Thumbnail
在前一篇〈資訊架構入門#1〉中,我們提到資訊架構的三個基本角色:使用者、資訊系統、以及資訊提供者;本文將繼續討論思考資訊架構的方式,希望讀者往後可以用新的方式來觀察使用的網站、app、甚至日常生活中各種數位產品的資訊架構。
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News