Hi 讀者，
最近我發現了一個很有意思的網站「Ink & Switch」，該站的成員認為雖然電腦在藝術、科學、思考和自我提升等各方面對人類的幫助非常大，但是今日主流的平台發展方向與創意人士背道而馳，因此這個名為 Ink & Switch 的獨立研究機構想要深入探究這個問題。網站刊登出很多文章，或者說是研究報告更恰當，例如〈Embark: Dynamic documents for making plans〉（Embark：為制定計劃所設計的動態文件）、〈Upwelling：Combining real-time collaboration with version control for writers〉（Upwelling：結合即時協作與版本控制，專為寫作者設計[的編輯器]），有些內容還有搭配作者講解的影片，有興趣的讀者可以找來看看。
我們在上一期推薦了 Airbnb 創辦人暨執行長 Brian Chesky 談管理變革的 podcast，我的同事 Karen 則是近一步推薦一篇文章（請看第三篇），文章的兩位作者針對 Chesky 的說法提出一些疑問，我認為是很好的平衡，歡迎讀者跟我們分享你的看法。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] 黃昱嘉／發展數據分析職涯，值得你訂閱的四份電子報
原文連結｜閱讀時間：10-15 分鐘
我們曾在〈發展科技職涯，值得你訂閱的三份電子報〉與〈產品人不可錯過的電子報〉兩篇文章分別推薦過適合軟體工程師與產品經理等科技領域工作者訂閱的電子報。本文要推薦四個數據分析相關主題的電子報，這些內容涵蓋不同面向，有的適合大眾閱讀，有些適合數據分析領域的專業人士，還有一份則是關於資料工程的最新資訊。
假如這些內容還不夠，作者另外推薦兩個內容豐富的部落格，以及另外四個算是「延伸閱讀」的電子報，相信應可滿足各位讀者的需求。其中《The Pudding》我個人相當喜歡，不僅文章主題適合大眾閱讀，還輔以精緻的動畫與圖表，告訴讀者一個又一個有趣的故事，例如「流行歌的歌詞是不是愈來愈重複？」「K-pop 團體的人數與組成變化」「男女褲子的口袋尺寸」——這些被他們稱之為「visual essay（視覺化小論文）」，也很值得專業讀者參考。
[英] Luke Hsiao／為自己的房子寫技術文件
原文連結｜閱讀時間：5 分鐘
你有想過為自己的家寫一套文件嗎？我相信有些讀者已經為自己的房子建立了某種程度的文件系統。本文作者 Luke Hsiao 是一位軟體工程師，在買房之後發現自己對於房子其實有很多疑問，例如：地毯安裝多久了？我該怎麼關閉自來水總管？灑水系統怎麼安裝的？有幾個灑水頭？它們在哪裡？我的洗碗機是什麼型號？使用手冊在哪？裝潢的油漆是什麼顏色？這些問題 Hsiao 一概不清楚，因此他一邊查一邊想，不如為自己的家寫一套技術文件。
Hsiao 決定參照系統化的技術文件框架 Diátaxis，該框架建議文件可以分為四種：學習導向的教學（tutorials）、任務導向的操作指南（how-to guide）、資訊導向的技術參考文件（technical reference）和理解導向的說明文件（explanation）。在這四類文件之外，Hsiao 決定再加上一個重要的文件：changelog，用來記錄他擁有房子後所做的重要改變，例如管路修繕、安裝地毯、升級灑水系統等等。
那要怎麼執行呢？雖然 Hsiao 認為不管是活頁夾筆記本、Google Docs 或是影片都可以，但他個人希望可以是一個網站，讓他可以在各種裝置上查詢所需資訊。最後他選擇自己很愛的 Material for Mkdocs，並且展示了目錄結構與設定檔。相信讀者可以猜到 Hsiao 的心得：他愛死這套系統了，除了家人也覺得方便，他甚至還說自己有點期待未來可以將文件移交給下一任屋主。（但我猜他不會想收到客服信吧？XD）
[英] John Cutler、Melissa Perri／我們對於 Brian Chesky 的「新 Airbnb」有些疑問
原文連結｜閱讀時間：10-15 分鐘
我們在上一期鄭重推薦了 Airbnb 共同創辦人暨執行長 Brian Chesky 在 Lenny’s Podcast 上談到他怎麼在 Airbnb 推動管理變革，我的同事 Karen 則是進一步分享這篇文章，作者是兩位資深的科技人 John Cutler 與 Melissa Perri（巧的是他們也擔任過 Lenny 的節目來賓），他們在文中分享了聽完該集節目產生的諸多疑問和思考，特別是從策略和管理角度，他們想知道哪些狀況導致 Chesky 做出這些決定（取消產品經理角色、將決策權收回集中、身為 CEO 更加深入參與產品細節與產品審核會議等等）。
兩位作者認為在思考 Chesky 講的內容時有必要要將背景與脈絡加入，於是他們先談到 Chesky 的背景（例如職涯大部分時間都在 Airbnb）、他與另一位創辦人（產品長 Joe Gebbia）怎麼工作⋯⋯ 接著談到 Airbnb 的狀態，Cutler 與 Perri 很好奇當時 Airbnb 的狀況與發展策略、關於 Chesky 發現公司狀況不對時的細節，因為根據兩人的經驗，這可能已經醞釀很長的時間，甚至足以成為組織內部的風暴。（Chesky 有在節目中提到時間點，但細節比較模糊。）Cutler 與 Perri 用「戰時」與「承平時期」的領導框架來看待問題，但你在 Chesky 的談話中看不出有這種框架。
Cutler 與 Perri 同樣針對 Chesky 談到的「組織架構」和「產品管理和賦權」議題提出許多問題，他們認為 Chesky 似乎對於「賦權」（empowerment）有所誤解，而且好像有點把賦權跟授權（delegation）混著講。兩人在文中深入拆解 Chesky 的談話內容，相當適合資深的工作者閱讀，不知道各位讀者在收聽/觀看 Chesky 的談話時，心中是否也有許多疑問？歡迎跟我們分享。
[中] 陳威帆／組織設計的兩難：目標導向還是功能導向？
原文連結｜閱讀時間：10-15 分鐘
延續上一期 Brian Chesky 談到 Airbnb 的組織架構議題，本文作者陳威帆是台灣數位設計公司「四合願」（Fourdesire）共同創辦人暨執行長，他在文中深入探討組織設計的兩大類型：目標導向團隊（goal-oriented team）與功能導向團隊（function-oriented team）。（Chesky 則是稱為 divisional company 和 functional company。）舉例來說，如果公司的組織設計是目標導向團隊，就是由多個有著各自目標的產品團隊組成，每個團隊從工程、設計、行銷到銷售都包辦；功能導向團隊則是將擁有同類型能力與專業技術的成員放在同一個部門，將資源整合起來解決特定專業問題，成為組織的一個特定功能，例如工程團隊。
本文除了探討兩種類型的特性與優缺點，將重點擺在如何運用這兩種組織設計的特性，去應對公司經營在不同時期、面臨不同問題時該如何搭配運用。陳威帆在文中引用英特爾（Intel）前執行長葛洛夫在著作《葛洛夫給經理人的第一堂課》中說的：「經理人不斷的在這兩種極端的組織架構間尋找最佳組合。」所以正確答案往往不是選定其中一種後就再也不改變，或是兩者中有一種更優異，而是一種混合結果，讓「目標導向團隊會靈活地去解決棘手的商業問題、而功能導向團隊則能夠有效利用企業資源創造價值。」事實上，我們在前一週提到的蘋果公司組織設計也不是單純的功能導向，例如他們就針對研發多年的產品「Vision Pro」成立專責部門，讀者可以參考這篇彭博社的報導。
陳威帆在文中提供讀者在設計團隊配置時可以思考的問題方向，甚至進一步探討多維度的結構，說明一位成員是有可能具備雙重身分的，只要主要、次要角色比例得當，組織可以更靈活地去解決問題。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
