Hi 讀者，
請問你有沒有計算過個人或公司訂閱了多少 SaaS 產品？有時候會不會覺得「啊，真的是訂太多了、吃不消」？開發 Basecamp 與 HEY Email 的軟體公司 37signals 上週宣佈要挑戰現有商用軟體的 SaaS 模式，預告推出名為「ONCE」的產品線，系列產品將會是一次性購買，讓客戶「擁有」、可自行 hosting 的軟體。
儘管我早就知道 37signals 兩位創辦人 Jason Fried 和 David Heinemeier Hansson（DHH）素來以寫作聞名，讀完 ONCE 網頁上的短文還是很想說：啊，他們真會寫。我想請問各位讀者，你們認同文中說的「SaaS still makes sense for many products, but its grip will slip.（許多產品仍適用 SaaS 模式，但其優勢將會衰退。）」嗎？
（Btw, 如果大家喜歡我們的電子報，歡迎多多分享。）
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] Bernard Chan／持續演化的「應用數據分析職能地圖」可以怎麼應用？
原文連結｜閱讀時間：5-10 分鐘
先前我們在介紹 ALPHA Camp 設計的「數據分析職能地圖」時，有提到這是一張持續演化的地圖。最近 Bernard 與團隊不僅將原本的地圖更新，還在四個象限第一層的「商業應用」「理論與素養」「技術與工具」「影響力」與第二層的 12 個子項目之外，近一步展開了地圖的第三層。
我們也將第二層地圖的 12 個子項目製成表格，做了更近一步的說明，不管是對個人職涯發展或是釐清組織內部數據人才分佈有需求的讀者，都歡迎你點擊連結閱讀原文。除了更新這份職能地圖，我們也在文章後半段整理了兩位產、學界專家的意見回饋，包含當老闆丟問題給你時，可以怎麼運用這張地圖去拆解、應對，感興趣的讀者別錯過了。
[英] Stephen Wolfram／為什麼我們公司要直播產品設計會議？
原文連結｜閱讀時間：15-20 分鐘
想像一下，有天老闆宣布「以後產品設計會議都要公開直播」，那會是什麼感覺？乍看之下似乎很反直覺，但還真的有人這麼做。這是一篇 2017 年的文章，科學家、Mathematica 與 Wolfram Language 發明人 Stephen Wolfram 分享他們是如何在 Wolfram Research 公司進行這樣的會議，以及這樣做有什麼好處。本文發表的時候，他們已經在 Twitch 直播過 40 次，六年之後的今天，「Live CEOing」系列影片已經突破 730 集。（YouTube 影片連結）
Stephen Wolfram 從 1991 年起就在當「遠距 CEO」，常常被問說他平常是怎麼工作，因此乾脆就直播工作的會議給大家看，也可以貫徹「thinking in public」的精神。直播畫面通常都是他的電腦螢幕搭配語音會議（他們覺得視訊鏡頭用途不大），主題涵蓋範圍很廣，例如新的函式、軟體工程⋯⋯就連 icon 顏色的討論也包含在內。直播的會議跟以前的差別只在於他們會簡短地告訴觀眾今天會議的主題，以及開放聊天室讓觀眾發言。（真是大膽的決定）
Stephen Wolfram 在文中提到幾個很有意思的觀點：他認為觀眾可以透過直播看到一個產品設計的討論與決策過程，你會看到想法怎麼被提出來討論、被拒絕，有時你會感覺到大家是不是卡住了，但終究問題可以被解決。更重要的是直播之後你可以回放影片，去找出大家是怎麼開始把事情弄清楚的。有時外部的領域專家們也會跑來看直播，甚至給予寶貴的意見。Stephen Wolfram 有一次錄 podcast 談到這件事還不忘開玩笑說：大家知道會議會被直播，可能也會更專注。（笑）1
[英] Addy Osmani／情境轉換的真實代價以及因應之道
原文連結｜閱讀時間：10 分鐘
本文談的是軟體開發者和團隊如何應對「context switching」（不是電腦術語裡的那個意思，在此可以理解為從一項任務切換到另一項工作，或許可以翻譯成「情境轉換」），作者 Addy Osmani 是現任 Google Chrome 的 DX 主管。他在文中分析了情境轉換的真實成本、帶來的壞處與好處（對，這也是有好處的），最後提供多項應實用的應對方案。
一項研究顯示，分心之後可能需要高達 23 分鐘才能恢復專注。當你從 A 工作切換到 B 工作，注意力其實還有一部分留在 A 工作，任務切換的狀況反覆出現時，就像你的手機開太多 app，不僅運作起來會卡頓，電量還會消耗得很快。最終你的「認知電池」會被消耗殆盡，所有的工作都會做不好。
頻繁切換脈絡除了耗損時間和注意力，工作出錯的可能性會提高，情緒也會受到影響。作者還指出，情境轉換不只會導致你的工作被延後，假如同事或別的團隊必須等待你正在開發的功能，每一次你工作被打斷，代表他們也會遭殃。
Addy Osmani 建議，如果有人打斷你，先問他們背景資訊：這個問題重要嗎？緊急嗎？又或者可以用視覺上的方式來表達目前不宜被打擾，例如在辦公桌旁邊放個醒目的牌子、戴起耳機、標記 Slack 狀態⋯⋯ 如果你覺得工作上常常被打斷，可以試試看本文的建議，或是向主管反映，而主管應該注意工作環境是否有這種問題，並且努力幫大家排除。
[英] Michael Siliski／如何設定好目標？好的目標應具備這五項特徵
原文連結｜閱讀時間：15 分鐘
本文是我的同事 Karen 推薦。作者 Michael Siliski 是資深產品人，在 Google、Ｘ（Twitter）、Stripe 等公司任職近 15 年。這篇文章的重點不在於設定目標的流程（文末會提到一些，作者也有提供許多參考資訊的連結），而是從主管角度出發，聚焦在：1. 為何要設定目標？2. 好的目標長什麼樣子？3. 根據（作者的）經驗法則，可以怎麼測試你的目標設得好不好，第四部分則是常見問答。
文章從設定目標的目的開始談起，Michael Siliski 認為目標就是對於成功結果的陳述，制定、執行計畫可以達到目標，但那些計劃本身並不是目標。你必須從結果來思考。（或許有點像人家說的「以終為始」？）而好的目標長什麼樣子？作者在文中列出五大項特徵：1. 聚焦、簡潔、好記；2. 客觀、可評量；3. 挑戰性與可行性兼具；4. 客戶導向；5. 狀態而非行動。以第三點來說，作者自己的經驗法則是成功率 70% 的目標是不錯的選擇，但若是務必達成的目標也必須讓大家知道。Michael Siliski 還提到，設定團隊或是部門目標時千萬不要按照職能（例如工程等）來設定，真正的成功應仰賴所有人共同努力來交付成果。
文章後段提供了七個用來測試你的目標「好不好」的指引，例如你有設定「工程目標」嗎？（有的話就不對了。）最後作者也回答了十幾個常見的問題，並且分享他對 OKR 的看法。有一題問說：我的目標如果不容易衡量怎麼辦？Michael Siliski 認為無論如何一定要設定指標（metrics），就算是代理（proxy）指標也好，他引用美國數學家、統計學家John Tukey 的話：「針對正確問題提出近似的答案就算有點模糊，也比針對錯誤問題提出精確答案好很多。」
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
