zonble

我很常使用國泰優惠這款 app。

國泰世華是我的主要往來銀行,也是我主要信用卡的發卡銀行,也就或多或少累積了些消費點數,這個點數叫「小樹點」,有了點數也就難免想去兌換些東西。辦公室樓下有一家星巴克,所以在上班前,或是用過午餐之後,三不五時就會去換杯無糖的熱拿鐵,用咖啡因還有熱騰騰的奶泡提振下精神,舒緩一下在電腦前久坐的酸痛,好繼續面對接下來的勞動。

想來杯咖啡的時候,我的習慣是,先走進店家門口,然後拿出手機,打開國泰優惠 app。在首頁上,我可以看到一排各種品牌的圖示,像是星巴克、小七、麥當勞等等,而我想選擇的星巴克往往是在第一個。點下某個品牌之後,就是這個品牌可以兌換的優惠,以星巴克來說,就是熱美式、冰美式、熱拿鐵、冰拿鐵、焦糖瑪奇朵等各種咖啡。我選下熱拿鐵之後,就會產生一張電子票券,拿去讓櫃台人員掃描一下票券上的條碼,我就可以準備等著店家完成我的咖啡。

然後有天,我以同樣的步調推開星巴克的大門,拿出手機想要用點數兌換咖啡,我才發現,手機上的國泰優惠 app 已經自動升級到最新版本,而對我來說,這個改版的最大特色,就是讓我很難找到我想要兌換的商品。

首頁上原本熟悉的那一排各個品牌的圖示不見了,取而代之的是一排的本月主打活動的廣告橫幅,還有好幾條「小樹點使用說明」、「新功能讓小樹點」的宣傳橫幅。各種優惠與可以兌換的商品,放到 app 的第二個分頁中,這個分頁叫做「花點」,優惠活動也不再以品牌區分,而是用商品類型區分,像是「咖啡精選」、「現金票券」、「美食餐飲」、「品味居家」等等,在每個分類之下,則是將所有品牌的商品一次展開。

在 2022 年五月一日的現在,國泰優惠 app 的咖啡精選分類下,總共有 112 個商品,在我的手機上,一次可以顯示四個商品,也就是說,這個分區的內容總共有 28 頁。

在這個分類下,我可以按照時間或是點數/金額高低排序,但不管使用哪種排序方式,我想要找杯星巴克的熱拿鐵,中間大概都會經過其他便利商店的咖啡商品、某些品牌的咖啡豆、還有全自動咖啡機、不鏽鋼手搖磨豆機、充電攜帶型磨豆機、咖啡吧檯墊、手沖壺、冰滴咖啡壺、手動牛奶攪拌器…

如果這個設計的目的是讓我可以因此瀏覽到更多的商品,目的的確是達成了,我也可以想像我的瀏覽行為可以產生哪些商業上可能有用的數字,可能有人會在某份投影片上面,寫著軟體介面調整前後的效益差別,像是原本某些商品都沒有曝光的機會,在新的設計上,這些全自動咖啡機、手沖壺的曝光次數增加了多少。可是呢,我現在人就在星巴克裡頭,我要的就是可以趕在下一場會議之前,可以用最少的步驟拿杯咖啡擠進電梯裡上樓,一個領死薪水的平凡上班族有這樣的期待,應該不算太過分吧?

仔細一看,這個 app 還是有依照品牌列出優惠商品的功能,但是被用了小小的字樣,放在不起眼、容易被忽略的的右上角,這到底是多希望人們不要找到這個功能;而對於長久依賴在首頁上直接點選星巴克圖示的我來說,我完全不記得按照品牌列出優惠商的的功能叫做「品牌館」。

說到右上角這件事情,就得講一下 Google。Google 最近希望原本使用免費 G suite 的用戶轉換成 Google Workspace,這件事情本身就很讓人抗拒了,而如果你真的想付點小錢繼續使用 Workspace,整個付款過程一樣充滿挫折。

在付款業面上,Google 用巨大的版面,在畫面的正中央,讓你選擇要使用彈性月付方案還是年繳方案,說明要繳交在不同時間段要繳交多少金額,你花了時間想清楚要用哪個方案之後,選擇了「下一步」按鈕,進入實際付款頁面,而到了下一頁,你發現,Google 只讓你輸入美國的付款地址,你完全不知道發生什麼事,你從 Google 的客服頁面上,也找不到怎樣才能讓你輸入在台灣的付款地址以及使用台灣信用卡的說明。

你花了很久的時間才發現,一樣是在不起眼的右上角,有一個「國家」與「貨幣單位」的選項,你在進入這頁的時候,視線直接被正中央的 “Choose your payment plan” 字樣吸引了,你根本就沒注意到右上角有這麼一塊。但是,如果你不在這頁先選好你在哪個國家或地區,還有要用什麼貨幣單位的話,你到了下一頁就沒辦法使用台灣的地址與信用卡。

--

--

最近在工作中累積了一些小小的心得。根據格式塔心理學,人類的大腦往往會將眼前所看到的事物看待成一個整體,並且形塑了對於世界的認知;可是呢,一個 App 工程師在撰寫跟 UI Layout 有關的程式碼的時候,就得小心是否被這種心理所迷惑了。

這麼說吧,當你拿到一份來自 Sketch 或是 Figma 的設計稿,打開編輯器或是 IDE,開始要撰寫程式碼的時候,你要注意的不只是畫面當中有些什麼,也需要注意畫面中那些空白的部份。很多時候,你以為不屬於一個整體的,其實應該要寫成一個整體;至於一些看起來像是個整體的,其實又應該寫成分開的元件。

最近在工作中寫了一個 app,裡頭的畫面像這樣。

我們來看一下下方這一塊的 UI。

--

--

一項專案或是產品之所以要有 PM,從字義上來看,就是因為專案或產品需要管理。根據維基百科,管理是「一定的組織或企業內根據一定的決策、規章進行協調活動,以達到某個明確的目標」,商業組織的明確目標就是效益的最大化,我們想要避免的,是浪費。 在開發過程中,我們想要確保所有的時間與金錢都真的用在優先的工作上,我們希望團隊成員之間不會互相空等,公司不會在空轉。而如果 PM 心中沒有成本觀念,會變成怎樣呢? 我想,從這篇文章中可以看到一些有趣的事情。文章作者是位 PM,第一部份講的是如何處理客訴案件。 作者說到,用戶在透過客服管道反映問題的時候,工程團隊往往要一些基本的細節,才更能夠掌握問題到底出在什麼地方,而這位 PM 的想法是「老實說,你覺得用戶會回答嗎?」「但期待我們能一起面對現實,不要等著資訊完備才開始解決問題。現實情況就是得在資訊不完備的情況下,盡量去搜集,需要主動解決問題?」 這個邏輯很跳躍。資訊不完備的情況下,要盡量蒐集資訊是沒錯的,但是所有重要的訊息與線索都在用戶身上,你不從用戶身上下手,然後把工程團隊推到漫漫毫無邊際的無知之洋當中;這真的很像是有人發病了,你覺得病人一定不會老實說,所以就直接放棄疫調,然後在足跡沒有踏到的地方做普篩,足跡踏到的地方也不見得去了,中間你可能還會遇到一堆偽陰、偽陽,最後你也不知道什麼時候可以解決問題。

一項專案或是產品之所以要有 PM,從字義上來看,就是因為專案或產品需要管理。根據維基百科,管理是「一定的組織或企業內根據一定的決策、規章進行協調活動,以達到某個明確的目標」,商業組織的明確目標就是效益的最大化,我們想要避免的,是浪費。

在開發過程中,我們想要確保所有的時間與金錢都真的用在優先的工作上,我們希望團隊成員之間不會互相空等,公司不會在空轉。而如果 PM 心中沒有成本觀念,會變成怎樣呢?

我想,從這篇文章中可以看到一些有趣的事情。文章作者是位 PM,第一部份講的是如何處理客訴案件。

作者說到,用戶在透過客服管道反映問題的時候,工程團隊往往要一些基本的細節,才更能夠掌握問題到底出在什麼地方,而這位 PM 的想法是「老實說,你覺得用戶會回答嗎?」「但期待我們能一起面對現實,不要等著資訊完備才開始解決問題。現實情況就是得在資訊不完備的情況下,盡量去搜集,需要主動解決問題?」

這個邏輯很跳躍。資訊不完備的情況下,要盡量蒐集資訊是沒錯的,但是所有重要的訊息與線索都在用戶身上,你不從用戶身上下手,然後把工程團隊推到漫漫毫無邊際的無知之洋當中;這真的很像是有人發病了,你覺得病人一定不會老實說,所以就直接放棄疫調,然後在足跡沒有踏到的地方做普篩,足跡踏到的地方也不見得去了,中間你可能還會遇到一堆偽陰、偽陽,最後你也不知道什麼時候可以解決問題。

而「老實說,你覺得用戶會回答嗎?」這種講法也很微妙-用戶一定不會回答嗎?為什麼一開始就假設用戶不會回答,然後直接放棄效率比較高、對整個公司可以避免浪費資源的路徑,明明有直路可以走,卻偏偏去走彎路。

一開始就假設用戶不會回答真的不像是面對現實,而更像是不願意去面對用戶,PM 與客服在面對客戶時有什麼社交障礙之類的。文中還對兩種工作方式舉辦了投票,讓大家選選那種方式會比較「舒服」,我只知道,不會用到我的資源,成本全部外部化,這會讓我很舒服。

我也很期待大家能夠一起面對現實,現實就是 — 資源是有限的

第二部分在講 PM 怎麼開票的問題。雖然這麼有點斷章取義,但我看到「老實說,PM 真的知道要開票要寫什麼內容嗎?」,還真是頂錯愕的。換個角度吧,你能夠換成別的角色,你能夠接受下面的說法嗎?

  • 身為 RD,真的知道要怎麼把 code 寫出來嗎?
  • 身為 QA,真的知道要測試什麼功能嗎?
  • 身為行銷,真的知道企劃書裡頭該把 TA 設定成誰呢?
  • 身為業務,真的知道要把產品賣給誰嗎?

答案是,每種角色都會遇到這些問題,任何人都有在職場上迷惘的時候,但是把自己的問題丟出來要別人解決,我很懷疑這是適當的作法。

這一段的邏輯說實在很亂,作者一開始說 PM 自己不知道怎麼開票,因為有太多的技術與設計細節 PM 不懂,所以 RD 與設計師可以自己開票做,然後提到有些 RD 與設計師說不知道怎麼開票,所以作者又開始教 RD 與設計師怎麼開票,變成了開票導師的角色;看起來開票這種事情真是難為 PM 了,PM 所擅長的,是怎麼指揮別人開票。

先不講這些。RD 與設計師的工作你不懂,沒問題,但是什麼工作都放給 RD 與設計師自己開票自己做,這個過程中,看起來 PM 也完全放棄了對成本的控管。

設計師想重新設計一套視覺語言,你不懂視覺沒問題, RD 想要做重構,你不懂工程沒關係,但是你還是得關心每件工作的背後都是成本,但是這個工作會投入多少人天,在此時此刻該不該做?會不會影響交付時程?會不會跟其他工作衝突?你從老闆那邊拿到了多少資源的授權?還是你取得了什麼外部資源可以幫助團隊?你在團隊的工作中看到了什麼不必要的浪費?

所以我們來看最後面的問題:

PM 說:“這個討論完畢後,我會開票給 designer 跟 engineer ”

但其實 PM 根本不知道內容要寫什麼,只能寫個大概

→ 那請 designer 跟 engineer 自行開票是不是更好?

一點都不好。你想要吃飯,你不用會做飯,但你起碼得告知你什麼時候要吃,你有多少錢可以用在這頓飯上,你覺得起碼要怎樣的東西才能吃,廚師才知道可以運用什麼食材,該在什麼時候準備,開票是部門之間對成本的約定,讓其他人自行開票,就是放棄控管成本。

最後,我相信有很多 PM 是真的很想把事情做好。不過,在自己到底應該扮演什麼角色,都搞不清楚的狀況下,也真的只有用想的而已。

--

--

前陣子我在手上這台 Ubuntu 機器上裝了 IntelliJ,用 Snap 一下子就裝起來了,但馬上遇到了使用問題,包括:

  • 無法正常中文輸入法。基本上我用的是 Ubuntu 本身的配置,就是用 iBus 加上酷音輸入法,沒有改動什麼。在 IntelliJ 裡頭,如果打了一段注音,然後要進入組字階段之後,像是要打一個「中」字,你先打「ㄓㄨㄥ」,然後按下空白鍵,你會看到「中」這個字被送出,接著就再也打不出任何的注音字根了。
  • 字體:整個 UI 與編輯器的字體,都直接變成了兩倍大小。在 1929 * 1080 解析度下,我看到的是這樣的畫面:

在網路上搜尋了一下,看起來是跟著 IntelliJ 一起發行的 Java Runtime 有些問題,要修正問題,可以把 IntelliJ 要使用的 Java Runtime 換掉。我們可以安裝一套叫做 Choose Runtime 的 plug-in,然後用這個 Plug-in,選擇要使用那一套 Java Runtime。

--

--

偶然看見這個一篇文章—〈波蘭化的台灣:工程師該賺多少才合理?〉

我整理大意如下:我們認為台灣軟體工程師薪資偏低,那是因為台灣許多軟體工程師做的並不是有產值的工作、開發的並不是有產值的系統,在這個前提不改變的狀況下,即使有再多的國外企業、博奕產業開出較高的薪資挖角,也不會讓本土企業的老闆對台灣軟體工程師開出高薪。

那麼,這些沒有產值的系統是什麼呢?就是各種企業內部的行政系統,像是人事會計財務物流系統等。作者認為,工程師都耗費在日常營運、而不是開發核心業務,所以,企業營運應該改用國際通行的 SaaS 服務,讓工程師從日常營運中解放,讓軟體工程師專注在真正可以賺錢的系統上,整個改變軟體產業的體質,才是讓工程師可以加薪的根本之道。

姑且摘錄幾段(也是原文中用黑體字加強的地方):

現在國際上企業用SaaS的生態圈非常成熟, 很多過去的行政工作、基本資料分析和基礎軟體開發工作,其實今天只要懂得如何去串接SaaS系統,公司的基本營運流程和基礎資訊架構就已經完善了,根本不需要工程師去插手 …

…在美國的現代企業中,現在一位受過專業訓練的數位行銷人才可以透過SaaS去取代過去一個十人的行銷企劃團隊;一位財務總務主管透過SaaS也能夠取代過去五人左右的團隊;而今天美國的軟體工程師,透過與各類SaaS系統串接,其開發工作的價值可能是十年前五位工程師的商業價值 。

個人以為,這篇文章中有個假設,就是美國企業使用這些 SaaS 服務沒問題,所以台灣的企業用起來也一定沒問題,台灣企業不用這些 SaaS 就單純只是企業觀念落後以及老闆不長進。要讓工程師做更核心、更具有競爭力的工作,這個方向是對的,但是國外這些 SaaS 是不是一種解方—我抱持相當保留的態度。

我沒有什麼系統化的證據,但是在職場上,也是親身看過一些台灣企業導入國際 SaaS 系統失敗,花錢想要導入卻無法上線的案例。無論是人事財務系統,到了世界各地,總是得要適應當地的法令與規範,不然即使在國外多成熟,仍然會水土不服。

在台灣人事系統就得要加上一例一休、還有員工離職前要把還沒有放完的假換算成薪資這種讓每個月可能會出現預算外薪資支出的麻煩規則,財務系統也會有像是小數點之後四捨五入這種放眼望去可能只有台灣獨有的要求。

而以台灣的市場規模,這些國外服務也不見得會為了台灣額外開發功能;為了要符合法規,要不就是企業繼續自行開發作者所稱的那些低價值的彆腳系統,要不就是要創生本土的 SaaS 服務,而創業本身又充滿風險,而且,在創業有成績之前,也沒辦法將工程師的薪資提升到多少。

其實台灣有一些本土 SaaS 也值得肯定,像是 iChef 就幫許多餐廳解決了POS 需求以及開發票的問題,幫許多餐廳建置了資訊基礎建設。總感覺台灣在很多領域仍然非常需要各種本土 SaaS,但真要做起來也一定充滿各種艱難。

--

--

zonble

zonble

XDDDD - eXtreme Due Date Driven Development