科技創業週報 #222:Slack 引進新技術的流程分享

| |

《科技創業週報》是由 Star Rocket 於每週三發送的免費電子報,內容涵蓋創新故事與觀點、產品開發技術與經驗的分享、值得一聽的 Podcast 節目與歷久彌新的經典好文。

每則選文都會加上編輯精心撰寫的引文,非常推薦給工程師、產品經理、設計師,或者是所有對科技產業感興趣的讀者訂閱。(訂閱連結附於文末)

哈囉讀者:

上週六是每四年才會出現一次的閏日 2/29,不知道大家有沒有在社群媒體上發文呢?(然後四年後才會收到回顧通知 XD)但也因為閏日所帶來的例外狀況,許多程式服務就出現了 bug:

像是美國知名的股票交易平台 Robinhood,在 2/29 之後的兩個工作天,就發生大規模的系統不穩定。雖然他們表示系統不穩定並非因為閏年,但是也有網友指出四年前的同一時間,Robinhood 系統也曾不穩,暗指這四年來他們並未針對這問題做改進。

若想知道閏日在今年為科技業帶來哪些災難,任職於微軟的工程師 Matt Johnson-Pint,有整理一篇在 2020 年因閏日而發生的 bug 列表。而他的部落格中也有一篇頗有意思的文章,在討論閏日 bug 的生命週期。XD

by Matt
[中] PCMan/在大公司或新創公司工作,會發展出不一樣的技能

不少讀者可能常常在思考要去新創公司還是大公司的經典求職問題,而知名的自由軟體開發者 PCMan,在回覆 PTT 軟體工作版(Soft_Job)上的文章〈如果可以,真的建議不要再去創業公司了〉,就以親身經驗分析大公司跟新創公司的工作環境的異同。

像是新創的步調較快,雖然資源跟時間有時感覺不夠,需要高度彈性、抗壓性,但有較多的機會帶領專案;相反地,大公司雖然制度完善,軟體工程的工作方式與程式碼品質也比較紮實,是學習基本功的好地方,但缺點是個人能展現能力的空間有限。因此 PCMan 也在文末強調:「不同的訓練,有不同的價值,應該兩者並用互補,而不是爭大公司或小公司哪個技術好。」
[podcast] 星箭廣播 EP45|科技圈重要文件特輯 2:網路女王 Mary Meeker 與她的年度趨勢報告

繼《星箭廣播》43 集之後,這回我們要來聊聊另一份每年都在科技圈獲得高度關注的文件:Mary Meeker 的年度網路趨勢報告。

我們除了跟大家介紹 Mary Meeker 其人,還會告訴大家去哪裡找到這些報告、報告裡有什麼、看不懂那些縮寫該怎麼辦⋯⋯ 當然,還有聽眾關心的問題:我該讀 Mary Meeker 的報告嗎?閱讀這些報告我可以得到什麼?
[中] Andy Chang/有關前端技術的那些 UX 事 – 口罩地圖篇(GIS)

本文作者 Andy 是位前端工程師,這段時間也有參與口罩地圖的社群開發。在這篇文章中,他針對在這次開發口罩地圖的時候他所面臨到的問題:一次讀取過多藥局的地點資訊,導致網頁效能低落。他在文中就從前端開發者的角度,提出在 UX 上能帶來明顯改善,且技術層面也辦得到的解決方案。

作者在文中不僅整理出其他開發者所使用的取捨方式,像是使用熱點圖聚合相近的藥局,或者只呈現離使用者最短距離的藥局;他也一併提出在開發過程中,針對程式效能與 UI 呈現上的思考思路。
[podcast] 資深科技記者對談,一本關於 Facebook 的書是如何寫成?

資深科技記者 Steven Levy 最近出版了《Facebook:The Inside Story》這本深度爬梳 Facebook 發展故事的書籍,並在出版後引起科技圈的熱烈討論。而他日前在《Recode Decode》也接受 Recode 的共同創辦人 Kara Swisher 專訪,分享有關這本書的寫作過程與內容。

像是因為 Levy 跟 Swisher 兩人都曾專訪過 Facebook 的 CEO Mark Zuckerberg,在節目中也針對 Zuckerberg 這幾年來的轉變交換了彼此的意見。Levy 也針對本書的內容不夠「真實」,對 Facebook 太「溫和」的論點(因為多數訪談是在 Facebook 同意的前提下進行)進行反駁。他們也針對書中的精彩片段進行討論(像是 Zuckerberg 的那本消失的筆記本),很推薦給對 Facebook 或 Zuckerberg 好奇的讀者朋友收聽。

🎧《Star Rocket 科技創業週報》的 Podcast 推薦播放列表,可以透過常用的 podcast 播放器直接訂閱!
[英] Homebrew 專案領導人:開源專案維護者別再燃燒自己,照亮他人

Mike McQuaid 是知名的開源套件管理工具 Homebrew 的專案領導人暨主力貢獻者,而他從自己超過十年的開源參與經驗中,得出一項很深的體悟就是:「開源專案維護者並沒有欠任何人什麼。」會這麼說是因為他發現到,許多開源貢獻者常常面臨過勞的問題:他們覺得有義務要儘速解決使用者所遇到的程式錯誤,但不斷犧牲自己照亮他人的結果,就是導致開源維護者最終失去熱情,並停止維護這項專案。

針對這點為開源圈的活絡帶來負面影響的問題,Mike McQuaid 在文末也提供給維護者、貢獻者與使用者幾項建議。而若對 Homebrew 開發故事有興趣的讀者,也歡迎閱讀我們之前寫過的一篇文章
[英] 如何成為一名優秀的技術管理者

許多的管理者往往會對工程師有各種負面的刻板印象,像是他們都很自我中心、反社會、很難管理⋯⋯但往往也因為這些先入為主的偏見,導致他們在帶領技術團隊時遇上重重困難。本文作者 Jeff Ello 曾任職於科技業,目前也是美國普度大學管理學院的教授暨 IT 副總監。

他表示,其實管理者應該要先擺脫這些刻板印象,並從技術層面的角度來觀察與思考與工程師的互動,也將工程師跟醫師作對比,指出兩者都是需要在該領域有一定專業,且仰賴持續聯繫與學習知識來維持專業。技術管理者只要尊重並理解工程師所關注的議題,就能有效管理技術團隊。
[英] 透過 DIET 法則,評估並展現設計團隊的價值

在產品開發的過程中,設計團隊的貢獻往往是最難以被評估的:工程師可以透過程式的效能或 bug 數量,PM 可以比較專案結果的完成度與達標程度,而行銷也有像是轉換率等指標。但是設計團隊對產品的貢獻,卻少見有明確的指標作為評估。

資深設計師、DesignOps 經理 Dave Cunningham,根據過往帶領設計團隊的經驗,在本文中中提出了 DIET(Design Impact Evaluation Tactic,設計影響評估手法)這項法則,鼓勵設計團隊在產品開發中的三個階段,針對各 5 個問題進行自評,讓設計團隊一方面能釐清自己對產品開發的貢獻,一方面也向其他成員證明設計所帶來的價值。
[英] 怎麼評估是否引進新技術?Slack 架構師的真實案例分享

在過去的週報中,編輯曾分享過購物平台 Shopify 如何評估採納新技術的時機點。而本文則是由 Slack 的系統架構師 Keith Adams 與 Johnny Rodgers 所寫,他們借用經典的「科技採納模型」(The Adoption Curve),將新技術引入 Slack 的過程分為探索、擴張與轉移三個階段,搭配實際在 Slack 發生的幾項新技術採納案例,如 React、Hacklang,或者是最終喊停的 LibSlack,分享他們認為在不同階段應採取的策略,以及要注意的事項。

文末他們也提供幾項建議給正在煩惱是否採用新技術的讀者。他們認為「在嘗試帶來改變時,要抱持著使用者中心的心態,來面對需要去理解與使用新系統的團隊。他們高興與否,是評估成功的唯一指標。」
.
Previous

《星箭廣播》46 集——你不知道的 @Twitter #創業故事

不想再被 Facebook、Google 追蹤?隱私助理 Jumbo 讓你一鍵清除紀錄

Next

發表留言

Share via
Copy link
Powered by Social Snap