Hi 讀者，
颱風來襲，希望大家都平安。昨天我看了 The Browser Company 旗下 Arc 瀏覽器的產品發表會（影片），在他們一貫有點「怪」的風格中宣布 Arc 將會新增五個結合 AI 的功能，稱為「Max」，其中有幾個相當有意思，例如讓 AI 把分頁名稱和下載檔案改成比較好辨識的名字。不知道各位讀者有沒有在用這款相對而言比較新的瀏覽器？你覺得它好用嗎？有沒有試用過這些新的 AI 功能了？歡迎跟我們分享你的心得。
考慮到再過兩天就是國慶連假，我們推薦大家篇幅比較長的文章（誤）。我很喜歡 Dare Obasanjo 談論企業文化與策略衝突的文章裡提到的說法：公司的文化由兩件事決定：受到鼓勵的正面行為，以及被容忍的負面行為。這非常具體，你甚至不用去想那些名詞或形容詞。另為我也非常推薦 Obasanjo 文章引用的，關於「黑莓機為了應對 iPhone 而採取的策略為何會失敗？」的文章，該文是 2013 年九月底刊登，距離今天正好 10 年。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] Titan／無聲當真勝有聲？非同步溝通的五個迷思
原文連結｜閱讀時間：10-15 分鐘
我們在《RISE-UP 科技人才升級週報》第 6 期推薦過一篇文章〈Managing the chaos of context switching〉，探討軟體開發者常常遭遇的情境轉換問題，或者白話一點說：工作被打斷。文中指出一旦分心之後要回到原本的專注程度，所需的時間可能長達 23 分鐘。面對這類問題，常見的作法是盡可能採取非同步溝通（asynchronous communication）方式，減少「需要大家同時在場」的情況（例如會議、面對面溝通），增加每個人的時間彈性，讓大家可以安排塊狀時間給深度工作。有些公司大力推動非同步溝通，例如 37signals 就主張非同步應該要遠多於同步溝通。
然而人們對於非同步溝通的模式有幾個迷思，實際運用時如果沒有察覺，輕則影響效率，嚴重的話可能會阻礙團隊合作，造成大家的痛苦。本文並非要反對非同步溝通，而是想要藉由這五個迷思，探討非同步溝通在實務上可能的盲點與應對方式。我們也會在文末會附上一個簡易的檢查清單，讀者看看自己是否遭遇疑似非同步溝通迷思的狀況。
[英] Dare Obasanjo／當你的策略與企業文化打架時會發生什麼事？
當一家企業面臨生死存亡關頭時，採用的策略與原有企業文化衝突時，會發生什麼事？這是一篇 2020 年的文章，原文標題是〈Culture Eats Strategy for Breakfast〉（[企業]文化可以輕易擊敗策略），作者是長期關注產品開發與科技新聞、在 X 上有大量 follower 的帳號 Dare Obasanjo。*他指出，許多企業或產品領導者都明白採取正確策略的重要性，包含深入了解所處的市場與客戶⋯⋯ 但是比較少人注意到策略與組織文化一致的重要性，因為市場變化很快，組織的文化通常是停滯（stagnant）的。當這些企業或產品被新冒出來的對手顛覆（disrupted）時，都知道要改變策略，問題是他們無法克服組織文化以及原有做生意的方式所帶來的障礙。換言之，當你要做出重大的策略改變時，很可能要也要重塑組織文化。
文章比較了 RIM（後來改名為 BlackBerry，與其代表性產品黑莓機同名）與 Google 兩家公司看到 iPhone 發表之後所做的改變，指出黑莓公司的新策略與既有商業模式、人才與組織結構等等有所衝突，例如黑莓公司的主要客戶其實是電信公司、企業與政府，並不是一般消費者，但是為了順應市場所採取的策略（推出觸控螢幕手機、新的作業系統等等）最終與企業文化不相容：例如黑莓公司的產品團隊，包含共同創辦人與執行長 Mike Lazaridis 都認為客戶要的是鍵盤和長效的電力，不是完整的網頁瀏覽、不是 app（會造成電信公司的流量負擔、企業員工會分心、更耗電⋯⋯），他們打造不出來夠好的產品，推出時幾也延誤太久，再加上組織結構問題（黑莓公司採共同執行長制，兩位執行長對於策略的意見有嚴重分歧）⋯⋯黑莓公司後來的故事大家都知道了。
至於 Google 陣營是怎麼調整 Android 呢？原文有兩張圖片，分別是 iPhone 推出前與推出後的 Android，不過圖片已無法載入，建議讀者可以參考 Internet Archive 的版本。。我們很推薦讀者閱讀 Dare Obasanjo 在文章引用加拿大媒體 The Globe and Mail（環球郵報）寫的〈How BlackBerry blew it: The inside story〉（黑莓的失敗：內幕故事）。
* Dare Obasanjo 似乎把重心放在 Threads、Mastodon 和 Bluesky 等平台，在 X 上的發文變得很少。想追蹤他的讀者可以注意一下。
[中] 蔡學鏞／建模的重要性
原文連結｜閱讀時間：5 分鐘
本文作者是蔡學鏞，文章主要談論架構師兩大核心能力之一的建模（modeling）（另一個是抽象（abstracting））。作者認為模型在軟體開發中提供兩大價值，一是作為溝通工具，可以將複雜或模糊的想法或概念變得容易理解，「模型就是你對軟體專案的設計（包括系統設計和架構設計）」；二是模型相較於真實世界，較容易做出變化，成本也低許多，可以在實作前提供參考，對此作者寫道：「模型的變化，就是你對於軟體的重整（重新工程化）的設計。」
蔡學鏞在文中指出，由於模型就是去蕪存菁地去描述一件事物，有助於傳遞想法，善用模型可以讓人的思考更加清晰。他特別點出在建模前一定要搞清楚目的，否則只會得到一個「受到污染的模型」。文章最後他也提出建模的兩個重要原則，並且搭配簡單的例子去說明。對於「抽象」能力議題有興趣的讀者，可以去找系列文章的續篇來閱讀。
[英] Lenny Rachitsky／沒有專職 PM、不靠數據，Linear 怎麼打造產品？
原文連結｜閱讀時間：15 分鐘
本文作者是我們先前介紹過的 Lenny Rachitsky，他說本文的主角、專為軟體開發者設計的產品開發管理工具軟體「Linear」是最多讀者希望可以在「團隊如何打造產品」系列文章讀到的案例，可見其產品受到業界關注的程度，文章包含的議題很廣，從他們怎麼制定計劃、開發功能的流程、組織設計、人才招募等等。
Rachitsky 先在文章開頭列出六點 Linear 團隊作法的特殊之處，例如：
- 沒有好幾個產品經理，只有一位產品主管。產品經理的職責被分散到工程和設計團隊身上。（這樣做有好有壞。）
- 沒有長期的跨功能團隊（cross-functional team）。他們會針對某個專案組成團隊，完成後就解散。
- 沒有那種根據衡量指標設定的目標。只有一個公司層級的北極星指標。
- 不做 A/B 測試。決策方式主要依賴品味（taste）和觀點（opinion）。
關於第三點和第四點，最近幾年開始有些新創公司似乎在做事方法上與上一個世代略有不同，對於數據的執著沒那麼高，例如我在編者的話提到的 The Browser Company，他們宣稱自己只關注一項衡量指標（使用者一週是否有五天會打開 Arc 瀏覽器），他們想要最佳化的是「使用者的感受（feeling）」。
不過讀完這篇文章我也有些疑問，以「不做 A/B 測試」這點來說，不知道 Linear 未來的客戶在數量和類型增加之後，還能繼續靠「品味」和「觀點」來設計產品嗎？
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
