Jayden Lin

筆者曾任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌

「這個年代,工程師誰不多少學點 AWS ?」

這次我讀的是旗標出版社的新書《AWS 職場實戰手冊》。

認識旗標出版社是在我大學的時候,系上學長們推薦我看的。當時我翻他們家的書,第一印象是:「字和圖都好大!」排版看得很舒爽。小朋友學閱讀從看大字大圖的童書開始,當年從旗標的書看起,也減輕了許多我初學程式的恐懼與不安,在當時網路學習資源不豐富的年代,真心地謝謝他們出版了這些好書。想當年我的 JSP (是 JavaServer Pages,不是呷尚寶早餐店) 就是看他們家的書學的。因此,在我今年六月收到旗標出版社的《AWS 職場實戰手冊》書評邀約,二話不說就答應了。

--

--

筆者曾任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌

最近看到許多相關的新聞,沒有第三方 Cookie 之後,用戶隱私會更有保障嗎?整個廣告環境會變得更好嗎? 在禁用之後,大型廣告商的護城河會提高,用戶email 會變成主要的追蹤手段,有能力做追蹤的大型廣告商依然不受影響。

為什麼會這樣說呢?其實跟技術的實作有關。

簡單來說,在技術上的解法,是在收集用戶行為的網頁裡面(e.g. 商品頁),埋一段JavaScript ,把用戶的「識別資料」用 JavaScript 轉發出來。通常識別資料是拿用戶的 email 做匿名化編碼後的結果,廣告商透過這個識別資料來分析用戶行為並投放廣告給用戶。

匿名化可以想像成買東西時領號碼牌,號碼牌就代表你,你本人被「匿名化」編碼成號碼牌的號碼,只有店家能「識別」這個號碼並投放對應的商品給你,就跟廣告商透過匿名化的 email 投放廣告一樣。在後第三方 Cookie 時代,大部分的廣告廠商都是這樣做的,不論是 Yahoo 推出的 ConnectID 或是 The Trade Desk 推出的 Unified ID 都是採用類似的做法。

但這樣做有什麼影響呢?

❶ Email 識別資料對小型網站不友善,很難做再行銷

識別資料大多是基於 email ,小型站需要在用戶登入的情況下,取得 email 再把用戶的行為資料發送到廣告商那裡,廣告商知道用戶逛過哪些商品,才可以投放廣告給用戶。然而,以小型電商網站舉例,用戶在瀏覽時通常不會登入,只有在結帳時才會登入。也就是說,在結帳時才發送 email 訊號給廣告商,但這麼做的意義並不大,因為你都買了,廣告商只能投放相關商品給你,精準度不見得好,例如:你已經買了相機,廣告商才收到你買相機的訊號,投放一堆相機商品或配件給你.你不見得想買。以 email 為主體的識別資料,在用戶閒逛期間不登入的情況下,小網站會失去大量用戶的行為資料,也會很難收集足夠的資料做「再行銷」(Retargeting)。

❷ 廣告商大者恆大

大型的廣告商 (e.g. Google, Yahoo, The Trade Desk 等等) 可以只透過用戶 email 識別資料,分析出適合的廣告版位做投放。這是因為大型的廣告商本來就有第三方 Cookie 時代收集的大量用戶行為資料,只要將用戶 email 識別資料跟以前收集的用戶資料做匹配就可以投放精準的廣告了。然而,新進的廣告商並沒有這些用戶資料做匹配。沒有資料做匹配的下場,就是廣告會投放得很不準,例如:我不養狗,卻投放給我狗飼料的廣告等等,新進的廣告商會愈來愈難生存。

除此之外,對大型廣告商來說,因為以前的用戶資料累積夠多,還能做到「不透過用戶 email 識別資料」。舉例來說,在不知道 email 的情況下,把用戶瀏覽商品頁的「內容」用 JavaScript 送出,廣告商根據這個人瀏覽網頁的情境 (Contextual) 來反查這個人是誰,進而投放廣告。這些都是新進廣告商不具備的優勢。

❸ 技術整合變困難

如果網站要整合廣告功能,為了配合不同廣告商的標準,要把用戶 email 交給不同的廣告商做匿名化,以前可能只要埋一段 JavaScript 就搞定,現在還要配合後端吐出用戶 email 做整合。

在了解這些技術原理之後,下次在新聞看到什麼「不使用 Cookie」 (其實是改用 JavaScript 發送用戶資訊) 或是可以根據情境做廣告信號判別 (其實是大廣告商可以從情境反查使用者),或是採用「某某 ID」 的技術 (其實 ID 背後是用戶 email),就可以大致知道背後是什麼原理運作的,讀出其中況味 :)

所以,沒有第三方 Cookie 之後,用戶隱私會更有保障嗎?整個廣告環境會變得更好嗎?我個人是抱持著懷疑的態度,就如前面所說的,大型廣告商的護城河會提高,用戶email 會變成主要的追蹤手段,有能力做追蹤的大型廣告商依然不受影響。與其高舉著保護用戶隱私的牌坊,還不如直白地當個真小人。與廣告共生,也許是這個年代,我們使用這麼多免費網路服務不得不付出的代價吧!

若是喜歡我分享的內容,可以訂閱我的粉絲團《程式猿吃香蕉🍌,在軟體開發的路上,一起分享交流,一起成長。

--

--

筆者曾任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌

前陣子受邀直播課程的關係,接觸了許多初入軟體產業的新鮮人,在 Q&A 時間,我被問到最多的問題便是:

「我該如何在職涯裡持續地成長?」

針對這個主題,我們可以向知名 NBA 球星 Kobe Bryant 學習,以下將分享一段 Kobe Bryant 的訪談,從影片裡我們可以看到一個世界級頂尖球員,是怎麼持續成長、發光發熱。然而,籃球的經驗與做法要怎麼套用在軟體開發職涯上呢?​這是這篇文章想要分享給你的 :)

▍Kobe 怎麼做?有策略地用弱項來比賽

切合本篇的題目:你什麼時候才要變強?Kobe 的答案是:把握時間在實戰比賽中,刻意鍛練自己的弱項,使弱項最終能變成你的強項。

這是什麼意思呢? Kobe 舉例,他 13 歲時,打籃球不擅長使用左手、不擅長後仰跳投、 也不擅長低位技巧,但他卻在比賽中強迫自己使用不擅長的進攻方式,用自己的弱項來打比賽 (Play to my weakness),因為,Kobe 看的不是短期的比賽勝負,而是長期的球技成長。

I played the longer game, because my game wasn’t about being better than you at 13.

— Kobe Bryant

簡單來說,Kobe 的目標並不是在 13 歲就贏過對手,而是將目標放在未來。反觀他高中的同儕對手,著眼於當下的勝負,只使用自己熟悉的打法贏球,等到 17 歲時,Kobe 的左手進攻、後仰跳投、以及低位技巧,經實戰的磨練,有了大幅進步,成為一位技巧全面 (well-rounded) 的選手,而同儕的球技卻停留在了 13 歲。

▍對軟體開發的啟示

Kobe 的經驗看似與軟體開發一點關係也沒有,但仔細想想,這些作法能給我們什麼啟示呢?以下幾點進行討論:

❶ 實戰經驗需要刻意安排

小時候,矇矇懂懂地聽數學老師說:數學不是「用看的」,要親自去算。長大後才深切體會到,實作跟理論總是存在差距,而這樣的差距只能靠實戰來弭平

以軟體開發來說,如果我們看書學了函數式編程(Functional programing)、領域驅動設計(Domain Driven Design)、測試驅動開發 (Test Driven Development) 等等高大尚的理論,卻沒有勇氣拿這些新技能來解決實際的問題。這就像是 Kobe 高中時的同儕,一直用自己習慣的方式打球,認為:

「這樣打就能贏球了啊」

「這樣寫程式就能交差了啊」

日復一日地,讓理論永遠是理論,自己的弱項永遠是弱項。你什麼時候才要變強?也成為了內心不敢直面的拷問。

另外,也有另一種的想法是:「書先唸起來放」等到用的時候再說。然而,沒有小規模的實戰過,到真實的戰場上你真的敢用嗎?就像 Kobe 招牌的後仰跳投,絕對不是先練著不用,而是從小到大,在每一次實打實的比賽中愈戰愈強。

在軟體開發實務中,使用新方法實作,甚至是刻意安排的。

雖然難免會犯錯,但只要縮小範圍,控制損失,這些實戰經驗都會讓你成長得更好。以我自己的例子來說,在樂天市場有機會在 React 剛推出時,使用在正式專案中,在 Yahoo 嘗試新的報表做法時,成為 Apache Druid 這項技術的早期使用者。這些刻意安排、跌跌撞撞的實戰經驗,都是成長的養分。

下一次,當發覺自己成長受限時,也許可以問問自己,是不是像 Kobe 的同儕一樣,使用自己熟悉的打球方式太久了?

❷ 長期策略對抗短期波動

在金融領域,以長期策略對抗短期波動是很常見的做法。有趣的是, Kobe 在打籃球這件事情上,竟也採用了同樣的做法。這裡的短期波動是指高中賽事的勝負,而長期策略是 Kobe 自我球技的提升。而這項策略同樣也可以套用在軟體開發領域。

在軟體開發領域,短期波動對個人來說,指的也許是一次開發任務、也許是一季的考績,如果我們只在意每次開發任務都要表現完美,不敢挑戰新的領域,例如:每次都開發同樣的模組、撰寫同樣的程式語言、只做主管關注的專案,雖然短期可能會得到不錯的考績,但長期下來技能反而受限了。

簡單來說就是:我們被「短期波動」的利益給綁架了。等到模組進入維護階段、程式語言過時、或是主管對專案的關注度消退,那麼技能上的短板便會一覽無遺。Kobe 高中時的同儕便是被短期的球賽勝負給綁架,而錯失了長期的發展。有句俗語可以說得很好:

不要在意一城一地的得失,學會盯著終點看

▍總結

乍聽之下,用自己的「弱項」來競技,很違反常理,但其中卻隱含深刻的智慧,包含怎麼刻意練習在實戰中成長,以及用長期的策略對抗短期的波動。

Kobe 是籃球界的頂尖人物,看似和軟體開發毫無關係,然而,跨領域概念間的借鑑是我很喜歡做的事情,從中可以迸發出許多有趣的思考,文末附上訪談的完整影片,希望看了也能對你有所啟發。

若是喜歡我分享的內容,可以訂閱我的粉絲團《程式猿吃香蕉🍌,在軟體開發的路上,一起分享交流,一起變得更強。

--

--

筆者曾任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌

現今軟體開發團隊時常以跨職能團隊的形式組成,先前我有撰寫一篇文章討論:跨職能團隊是什麼?有興趣的讀者可以參考一併閱讀:

這篇文章將進一步討論跨職能團隊的優點以在常見的誤區。

本篇內容:
✔ 跨職能團隊的優點
✔ 常見的錯誤觀念與問題:七大誤區

▍跨職能團隊的優點

1. 跨職能團隊能建立同理心 (Empathy)

將不同職能的人放在一個緊密溝通的團隊當中,會更能理解彼此的想法,進而建立同理心 (Empathy) ,相較於傳統的流水線般的工作流程,大家僅是專注把自己的工作完成,而忽略了專案中其他的觀點。

此外,根據 Google 近年對於高效率團隊的研究,同理心是一個高效率團隊成功的重要因素。

2.跨職能團隊可以有更有效的溝通

跨職能團隊可以將專案的里程碑 (Milestone) 視覺化,各部門可以知道整個專案目前有哪些任務正在進行當中,以及彼此會不會互相影響。如下圖所示,灰色的橫軸是時間軸,將各個部門的專案的里程碑以時間軸展開,促成更有效的溝通。此外,在實務的經驗上,將任務視覺化也有促進對話的效果。

--

--

筆者任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌

跨職能團隊 (Cross functional team) 是軟體業近年來非常流行的組織形式,由 PM 與設計師和工程師等不同職能的人一起設計與開發軟體,團隊中甚至是能包括公司外部的人,聽起來很不可思議,不同職能的人怎麼一起工作?這是這篇文章所要討論的。

本篇內容:
✔ 為什麼會有跨職能團隊?
✔ 跨職能團隊的定義與特色
✔ 跨職能團隊和傳統職能分工的差異

▍為什麼會有跨職能團隊?

跨職能團隊的出現,跟軟體開發方式的改變有很大的關係。

因為要能夠快速地回應市場變化軟體開發的方式改變了,人們開始以更短的週期來開發軟體,舉例來說:

  • Java 以往都是每兩年釋出新版本,在 2018 年改為每半年釋出新版本
  • Chrome 瀏覽器在 2021 年從每六週釋出新版本,改為每四週釋出新版本

以做網站為例,在過去的開發方式下,我們會先作完整的規劃,再以較長的週期進行開發 (如下圖的上方列所示),等到長長的周期 (黃色長箭頭所示) 結束之後,我們才會知道軟體的成果長什麼樣子,因為時間較長,所以當軟體釋出的時候,很有可能我們做出來的產品已經不符合市場的需要。

--

--

Jayden Lin

Jayden Lin

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

Following