一句話總結

我的時間都去哪了？（2023 年版）

重點提要

• 我正在釐清自己在 TinyPilot 上把時間浪費在了哪些地方。
• 我發現自己又再度對電子郵件上癮了。
• 我打造了第一座伺服器機櫃。

目標成績單

每個月月初，我都會宣告當月想完成的目標。以下是這個月的達成情況：

與新的代工廠啟動一批生產

• 結果：第一批生產已經啟動。
• 評分：A

我已經和代工廠簽了採購單，第一批生產正式啟動。這將是公司有史以來最大的一次變動，讓人有點緊張。順利的話會很棒，搞砸的話就是災難。我當然希望是前者。

發布 TinyPilot Pro 2.6.0

• 結果：準時發布了 TinyPilot Pro 2.6.0。
• 評分：A

六月份的版本發布得很順利，但感覺有點平淡。過去兩個版本，我們的開發心力大多放在讓更新更簡單、更不容易出錯。這些改動讓軟體的可維護性大幅提升，只是在版本公告裡聽起來沒那麼吸引人。

達成 9.5 萬美元營收

• 結果：營收達到 9.3 萬美元。
• 評分：C

TinyPilot 這個月的營收大致持平。有一支新的評測影片上線了，但迴響平平，所以銷量不如預期。

TinyPilot 數據一覽

這個月幾乎所有指標都持平。其中一波行銷操作沒什麼效果，但我手上還有其他正在醞釀的計畫，仍抱持樂觀。

TinyPilot 的廣告效益大幅下滑。五月時，每投入 1 美元廣告費能帶來 3.64 美元營收；到了六月，每 1 美元廣告費只能帶來 2.62 美元營收。考量到 2.62 美元的營收中約有 0.90 美元是材料成本，廣告整體仍有獲利，只是利潤變薄了。

我會再給廣告一個月的觀察期。如果成效沒有改善，就會和 TinyPilot 的行銷顧問約時間，看看能怎麼調整。

我的時間都去哪了？

在最近一場獨立創辦人聚會上，我提到自己最大的挑戰，是找不到時間去做那些重要但不緊急的任務。

其他與會者很驚訝。為什麼我不能把所有事情自動化或交辦出去？到底有哪些事非得我親自處理不可？

去年我曾試著檢視自己如何運用時間，覺得很有幫助，所以今年想再做一次。

以下就是身為 TinyPilot 創辦人，占據我最多時間的幾項工作。

任務一：協調各項變動

當 TinyPilot 的團隊超過兩個人後，我意識到自己的主要職責之一，就是協調各種變動。

TinyPilot 同時在多個面向成長：我們改進軟體、改進硬體、導入新的供應商、增加團隊成員等等。

對業務某一塊的改動，往往會產生漣漪效應，影響到其他部分。隨著 TinyPilot 的人員與複雜度增加，這種連鎖影響也變得更頻繁、更顯著。

我該如何減少在這上面花的時間？

有些聚會的朋友建議我乾脆請一位經理。但事情沒那麼簡單。

TinyPilot 有三個團隊，每隊兩到三人不等：軟體開發、技術支援工程，以及客服／在地營運。三個團隊的職責大致互不重疊。

如果我只請一個人來管其中一個團隊，省不了多少時間。如果要請一個人管全部三個團隊，他就得有帶領軟體團隊的經驗，年薪大概至少要 12.5 萬美元。加上其他成本，雇用這樣一個人的總花費一年至少要 20 萬美元，等於會把 TinyPilot 目前的獲利全部吃掉。

我想得到最好的解法，還是跟去年一樣：同時進行的專案少一點，並尋找更多可以交辦的機會。

有些工作我會自己攬下來，是因為注意到其中有無法交辦的部分。舉例來說，如果一項工作包含 A、B、C 三個子任務，而 B 需要我代表 TinyPilot 簽約，我就會想：「喔，這只有我能做。」但在這種情況下，其實我還是可以把 A 和 C 交出去，只是常常忘了考慮這個選項。

另一個解法是把更多工作交給外部廠商，減少 TinyPilot 自己要做的事。今年，我們不再自行出貨，把物流轉給第三方物流（3PL）廠商。雖然這讓處理特殊狀況變得比較困難，但也讓我們徹底省掉了好幾類原本要自己處理的工作。

任務二：維繫與第三方物流（3PL）夥伴的關係

我本來以為轉移到 3PL 廠商的工作，前期會最吃重。我知道挑選廠商、完成轉換會很辛苦，但以為之後就能一帆風順。

結果發現，後續還有一長串零碎的流程要跟 3PL 廠商一一釐清：

• 庫存從我們辦公室運往 3PL 倉庫的途中，要怎麼追蹤？
• 要怎麼確認 3PL 在倉庫裡沒有搞丟庫存？
• 當 3PL 寄錯商品時，要怎麼處理？
• 想要當日出貨的客戶，要怎麼處理？

這些問題都能解決，但新的狀況不斷冒出來，所以我花了很多時間在思考 3PL 的事。

我該如何減少在這上面花的時間？

這塊是我應該更放手交給團隊的地方。

我已經開始請 TinyPilot 的在地團隊更積極地參與 3PL 的對接，目前看來有效。

以前遇到像是防止 3PL 搞丟庫存這類問題，我會自己定義一套稽核他們庫存報表的方式。現在我改成請在地團隊的成員去想辦法，而不是事事都由我來訂。

任務三：參與軟體開發

我花很多時間參與 TinyPilot 的軟體開發，因為那是我最喜歡的部分。即使現在寫程式的時間不多，我內心仍是個開發者。

有幾個小時空檔時，我常會拿來修個小 bug 或整理一下程式碼。但有時看似微小的改動卻會膨脹成好幾天的工作量。

我該如何減少在這上面花的時間？

這題很難，因為最直接的答案就是：「Michael 應該別再寫程式了。」

但我就是喜歡寫程式……

更實際的作法，是我在接開發任務時要更保守。我應該把自己的開發工作限於：

• 改善開發體驗的事，例如更好的文件、更完善的測試，或新的便利腳本
• 那些因為我有歷史脈絡或公司內部背景，由我來做會比交代給別人做更有效率的改動
• 實驗性質的改動，成功就有收穫，失敗也能直接丟棄

任務四：審閱文件

除了日常的客戶支援，技術支援團隊也會撰寫文件和教學。我對對外的文件特別要求，所以花很多時間審閱團隊的稿件，並針對風格、清晰度和技術用語給予回饋。

審閱文件不用花太多實際工時，卻非常耗費專注力。我光是要把自己的文章寫清楚就覺得很費神，要去讀別人的文章並指出哪裡缺漏或不清楚，就更吃力了。

我常常變成文件工作的瓶頸，因為即使有一個小時的空檔可以看新的教學，也常常沒有足夠的心力給出有用的回饋。

我該如何減少在這上面花的時間？

最簡單的改變，是更仰賴同儕審查。在開發團隊裡，軟體工程師有 90% 的程式碼都是彼此審查，不需要經過我。英文寫作要維持一致的風格比程式碼更難，但我覺得文件編修有 80% 可以靠同儕審查完成。

另一個該做的調整，是在指派文件工作時考量自己的餘裕。以前我會一口氣在技術支援團隊的工作清單裡排上三篇教學，結果自己卻沒辦法一次審完。我應該把文件工作排得更分散，留給自己足夠的審閱時間。

擺脫電子郵件成癮

過去幾年，我一直在「和電子郵件保持健康關係」和「對電子郵件上癮、沒有效率」之間來回擺盪。

我是怎麼把好好的收信習慣搞丟的？

一旦養成健康的收信習慣，通常要維持並不難。真正會把我拉出正軌的，往往是某個事件讓我有正當理由緊盯信箱不放。

最近，負責生產 TinyPilot 金屬外殼的廠商延遲交貨，導致我們的外殼用完了。缺外殼非常麻煩，因為就無法組裝新裝置。這意味著我得手忙腳亂地幫在地團隊重新安排工作，而且這些臨時任務還得是那種幾天後（希望）外殼到貨時，可以馬上放下、切換回去的。

在像外殼短缺這種情況下，確實有必要緊盯電子郵件。如果中國的廠商在週五晚上寄信給我，而我放到週一早上才回，他們要到中國時間的週二早上才會看到。這就是三天的延誤，等於在地團隊又得多三天無法組裝新裝置。

問題在於，緊急狀況結束後，我仍會保留頻繁收信的習慣。而且當我收信卻沒看到急事時，還是會渴望那種多巴胺的刺激，於是就去滑社群媒體。那從來沒有好處。本來只是想花 30 秒收個信，結果卻花了 10 到 30 分鐘在無止盡地滑手機。

解法一：只在排定的時間收信

以往要擺脫不良的收信習慣，我的方法是把一整天明確地規劃出來。

每天早上，我會把工作時間切成 30 分鐘為單位的區塊，並決定每個時段要做什麼。為了避免忍不住一直收信，我會排定專門讀信、回信的時間，而不是讓收信這件事整天在背景嗡嗡作響。

我得逼自己重新養成這個習慣。一旦進入節奏就很容易維持，難的是重新開始。過去的經驗是，只要硬撐過前幾天，之後就會變得比較輕鬆，也更有成就感，不再需要靠意志力苦撐。

解法二：鼓勵事後回饋

寫這段話的當下是早上 10 點，到目前為止我都忍住沒收信。但心裡卻有種強烈的感覺，覺得自己正在卡住別人的工作。

會有這種感覺，是因為團隊成員常常會請我針對客服工單給意見，而這正是我平常鼓勵他們做的。

我漸漸意識到，同事把客服工單升級給我，會讓我的收件匣變得更具時效壓力。原本工單只是在等兩位支援工程師其中一人有空，現在卻卡在我和那位升級給我的工程師身上。於是我就覺得必須盡快回覆，否則會讓客戶等上好幾天。

有個我們從沒試過的方法是「平行升級」。與其讓工單停下來等我的回饋，我應該鼓勵同事在向我徵詢意見的同時，繼續和客戶保持互動。

解法三：讓團隊更善用同儕審查

我在談文件審閱時提過同儕審查，但我應該在各種工作中尋找更多同儕審查的機會。這能讓大家和同事一起成長，也能減少那些非得卡在我身上才能繼續的工作。

業餘專案

打造我的第一座家用伺服器機櫃

自從打造了我的第一台 homelab 伺服器後，我的辦公室就堆積了越來越多的伺服器和網路設備。

我的未婚妻指出，我的辦公室會變髒，是因為到處都是線，讓人不想吸地。我當時還想：「什麼？這線的數量很正常吧。」但仔細一看，才發現真的有點多……

我想到可以靠打造一座伺服器機櫃讓我們兩個都開心。我能享受一個有趣的 homelab 專案，她也能享受所有線材收納在同一個機櫃裡的整齊感。

於是，我打造了第一座家用伺服器機櫃。過程很有趣，也真的讓一切整齊許多。所有設備垂直堆疊後，地上的線變少了，而且整座機櫃裝有輪子，方便移動清潔。

這是我第一次使用網管型交換器和 VLAN。一開始我覺得 VLAN 很麻煩、很難除錯。現在掌握基本操作後，反而很喜歡，甚至想把所有東西都劃進 VLAN。

我正在撰寫一篇更完整的文章，分享我是如何挑選各種零件、又犯了哪些錯誤，敬請期待。

學習 Nix

Nix 過去一年一直都在我覺得有趣的技術清單的最前頭，所以我最近花了些時間深入了解它。

我寫了關於初學 Nix 心得的筆記，沒想到在 Hacker News 和 Twitter 上獲得不少關注。Nix 社群裡也有人主動聯繫我，願意幫我解決卡關的地方。

這樣的迴響鼓勵我在嘗試還不熟悉的技術時，多把筆記記錄下來。

用 Go 打造自己的驗證函式庫

2018 年剛開始做網頁應用程式時，我不想自己處理驗證，所以總是使用第三方服務。

第三方驗證服務用起來還可以，但限制了我開源專案的推廣。其他開發者只有在使用和我相同的驗證服務時，才能部署我的應用程式。

第三方驗證的另一個問題是，會讓端對端測試變慢、變得更不可靠，也更複雜。

在最近的專案 ScreenJournal 中，我想找個不用第三方服務就能做驗證的方法。我先調查了有哪些可用的驗證函式庫。我的需求是：

1. 必須是開源的。
2. 必須使用 Go，也就是我目前開發網頁應用程式的首選語言。
3. 必須是能編進應用程式裡的函式庫，而不是需要另外跑的獨立服務。
4. 必須支援以 SQLite 作為資料儲存。

goth（前身為 gomniauth）似乎是最熱門的驗證函式庫，但它違反了第 (3) 點，因為它依賴外部的第三方服務。

另一個熱門的 Go 驗證方案是 authboss。它符合我所有的需求，但文件相當簡略。我後來發現那是作者刻意做的選擇，為了減少支援請求。

我花了一個下午試著用 authboss 做一個簡單的網頁應用程式，但連最基本的功能都跑不起來。越了解 authboss，就越覺得它不符合我的需求。它似乎期望整合者不只用它來做驗證，還要用它來處理頁面渲染和 URL 路徑路由，這已經超出我對驗證函式庫的期待了。

現在，我試著打造自己的可重複使用驗證函式庫。我不是想把它做成熱門的開源套件，只是想省去在每個業餘專案之間複製貼上驗證程式碼的麻煩。

目前它唯一能做的就是檢查使用者密碼是否正確。還稱不上可重複使用，因為呼叫端仍得自己產生密碼雜湊——而我希望這件事由驗證函式庫來做。

開發可重複使用的驗證函式庫是個有趣的挑戰，因為它逼我去用平常不太會用到的 Go 特性。這也很考驗我的架構能力，因為我得在「讓函式庫更簡單」和「對不同驗證方式保持彈性」之間權衡取捨。

總結

完成了什麼？

• 與代工廠合作，啟動 TinyPilot Voyager 2a 的首批生產。
• 打造了第一座家用伺服器機櫃。
• 學會了 Nix 與 NixOS 的基礎。

學到的教訓

• 在善用創辦人時間方面，還有幾個可以更有效率的地方：
  • 尋找更多能交辦工作的機會，並把大型工作拆解得更易於交辦。
  • 在承接開發任務時更保守。
  • 更刻意地安排處理電子郵件的時間。
  • 鼓勵團隊成員多加利用同儕審查。
• 伺服器機櫃對 homelab 愛好者及其另一半來說都很有趣。

下個月的目標

• 達成 9.8 萬美元的銷售營收。
• 讓 TinyPilot 轉移到代工廠的進度保持在軌道上。
• 花在電子郵件上的時間占比低於 40%。