科技創業週報 #292:我當工程師這十年的體悟

| |

Hihi 各位讀者,

我冒著被氣死以及砸壞電腦的風險為大家隆重介紹 User Inyerface,這是比利時設計公司 Bagaar 的企劃:打造令人抓狂的註冊登入流程,真的,超級,痛苦!我光要進入 Step 1 就被惹毛——Please click HERE to GO to the next page,到底要我點大寫、底線還是變色的地方啦!如此荒謬的設計還一直跳出計時視窗催催催 “ Hurry up, time is ticking!” 會不會人太差😠

這麼惱人的網站絕對不能只有我被氣到,各位體驗完每個會讓你理智線斷裂的細節後,保證會對人性化設計感恩惜福!

⚠️服用說明書:高溫炎熱,小心上火🔥

Julie
.
[英] Paul Graham 談「如何努力工作」

Paul Graham 最近寫了一篇文章談「如何努力工作」(How to Hard Work)。他先拆解了成就偉大事業的三個要素:天賦、練習和努力,雖說具備其中任意兩點你大概就可以把事情做得很不錯,但若要做到最好則缺一不可。而天賦問題我們既無法控制,也不太能改善,所以能做的事情就很清楚了:努力工作。難道沒有任何方法靠著聰明才智躲避努力工作這件事嗎?PG 認為答案就是沒有。

PG 認為「努力工作」並不是一個開關或旋鈕這麼簡單,而是種複雜的動態系統。他結合自身經驗、來自對別人(Bill Gates、Patrick Collison 和數學家 G. H. Hardy 等)的觀察,建議讀者要把「努力工作」做對之前,應該先了解你要努力的「工作」到底長什麼樣子 ,並由此衍生出幾個他認為很困難的問題:如何辨識真正的工作?要花多少時間投入?才能與興趣跟想要努力的課題相稱嗎?(要確定自己的興趣比發現才能要困難得多,前者的種類太多了。)如何衡量自己做得好不好?(如果領域很新,可能連什麼是「好成果」都不知道。)以及何時該放棄並且轉換領域。(有太多案例顯示人們會誤判自己工作的重要性。)

[Podcast] 星箭廣播 EP114 | 這樣聽音樂更好玩:聊聊幾個(其實是很多)有趣的專案和 app

你喜歡聽音樂嗎?繼 108 集〈聊聊我們怎麼聽音樂〉之後,我們要再來聊聊幾個讓聽音樂這件事情更有樂趣的網站和 app。首先是跟別人一起聽音樂,相信不少聽眾最近都悶壞了,Liz 會介紹一個跟朋友/網友一起聽音樂的網站「JQBX」(聽說過去一段時間多了很多新的台灣使用者),還有讓你自製「混音帶」的服務。在社交之外,Julie 會介紹兩個探索新音樂的網站,而且都跟地圖有關:Radio Garden 和 Radiooooo(五個 O!),後者還在地圖上加入年代的維度。

接著 Julie 跟 Liz 會介紹一些很有趣的音樂專案,包括一個有點惡搞的「How Bad Is Your Spotify?」歡迎大家去試試看 XD 而 Titan 想要介紹幾個跟歌詞有關的網站,除了他很愛的 Genius 之外,還有他最近發現、專攻台語歌詞的網站。最後三位主持人會跟大家聊聊幾個聽音樂的話題,例如日本麥當勞的歌單、數位音樂的 meta data 問題。

[英] 「北極星」只能有一顆嗎?Airbnb 前產品經理教你如何制定北極星指標

如果你正在打造「成長型」的產品,制定「北極星指標」是很重要的一步,正如其名,這個指標的作用是為公司導航,避免走上歧路。曾任 Airbnb 產品經理的 Lenny Rachitsky 寫了一篇堪稱北極星指標入門大全的指南,案例、框架、手段一應俱全。

他收集了40 間公司的北極星指標,例如 Airbnb 的北極星指標是「過夜數」,Spotify 則是「付費訂閱人數」以及「活躍使用者數」,而在 podcast 方面則是「聆聽時長」。他並詳細說明這些公司採取不同北極星指標的原因,以及建議使用「jobs to be done」的概念來訂北極星指標;他也提到人們常有的疑問:北極星只能有「一顆」嗎?
[中] Keith Yang/Tech Design Review: 軟體架構設計審查

或許你也聽說過專案到最後一刻才來改規格與實作的災難,所以 iCHEF 工程團隊在產品開發的流程中,藉由分享實作前的架構設計,讓團隊先體驗、提前溝通並發現可能的驚奇(驚嚇?),確保品質之外,「pull request 也更容易被 approve 了。」

作者在本文說的架構設計類似於技術審查(Technical Review),主要是為了溝通與探索技術實作的最終模樣,通常沒那麼正式,他分享在什麼時機和階段開始做、怎麼進行,而且幾次下來體驗到架構設計經驗的好處包括:提早發現遺漏重要情境或規格因外部關鍵因素需要重新設計,都免去後續的心力損耗等等。
[英] 想獲得有品質的回饋,先準備好你的問題與心態

尋求回饋的過程是一場折磨,對提問方來說尤其如此。由於自尊、脆弱的心理,導致害怕收到回饋。產品設計師 Hoang Nguyen 在本文中給了幾個建議:怎麼有效地接收到高品質的回饋,同時在一來一往之間,促進提問者與回饋者同理對方的態度。

其中一個常見的問題是,接收到負面的回饋時,設計者(提問者)也許會不自主升起「防禦心態」,為自己辯護,接著淪為個人品味之爭。Hoang Nguyen 建議,更好的作法是站在解決問題的角度解釋,例如,當回饋者提出「這設計看起來很單調」,「為了形塑品牌高雅的調性,我將色彩限縮在三種,你覺得橘色應該再突顯一點嗎?」的回應,就比「這是簡約風」來得好。
[英] GitHub 買了我的 App,但我買回它又賣掉它

這是一個有點曲折離奇的故事,John Nunemaker 回顧了他因興趣使然開發的簡報產品「Speaker Deck」兩度轉手的歷程。

2011 年 John Nunemaker 帶著「Speaker Deck」在 RubyConf 首次亮相,GitHub CEO Chris Wanstrath 親自寫信求收購,讓他歡欣不已。但加入 GitHub 後產品卻成了孤兒,接著又被公司放上待售清單,最終他決定自己買回自己的產品,而且為它做了幾番整修。但最終因又因有其他產品在身,缺乏多餘心力照護,所以又賣給了能夠好好呵護它的朋友。

John Nunemaker 的行文趣味生動,但也時而夾雜他學到的技巧,例如在收到第一次收購報價時先按捺不動、保持沉默是在對話或談判時的超能力。
[中] 黃翎/進入顧問公司 Design Agency 之後,可以期待的兩件事 🥰

「In-house 和 Agency 有什麼區別?該怎麼選?」這題是 AJA 大予創意 UI 設計師黃翎在 UIUX 設計講座最常被台下學生問到的題目之一,所以她從自身角度分享進入顧問公司的優點和缺點,幫助還在觀望的求職者們來做評估~

總體來說,在台灣設計顧問公司能接觸多樣設計題目,新專案就等於一個新領域,且能了解 to C 和 to B 的產品情境差異,是新手設計師快速建立自身 UX 資料庫很好的機會;除了比 In-house 設計師更常面對「跨公司」合作,內部團隊也會隨專案彈性調整規模,需要適應不同角色。最後黃翎認為,設計顧問公司適合具有三種特質的人⋯⋯🤫
[中] Yang Hsing Lin/當工程師十年的心得感想

本文作者 Yang Hsing Lin 回首當工程師十年的心得,他在每份工作都會設定不同目標,像是「在沒有特定 title 下,成為一個 10x 工程師」,進入另一間公司、開始帶團隊後,目標則轉變為「塑造一個『沒有我也可以自我成長的團隊』」。他發現 TDD、Feedback Loop 這些工程領域的概念也能運用在引導團隊上。

實踐目標的過程中,自我學習是很關鍵的一環。他設計了一個由「專業相關性」以及「理論 vs. 實作」兩個維度組成的矩陣,決定學習的內容跟深淺。最後他也提到自己如何使用科學思維解決商業或生活中的其他問題。無論是不是工程師,這篇文章都相當值得閱讀~
.

(文章代表圖:Photo by 青 晨 on Unsplash

本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
Previous

《星箭廣播》115 集——獨立萬歲!一個人的媒體王國

發佈留言

Share via
Copy link
Powered by Social Snap