一句話總結

我的時間都花到哪去了？（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 的軟體開發，因為那是我最喜歡的部分。即使現在沒太多時間寫程式，我內心深處仍是一名開發者。

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

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

這個很難，因為顯而易見的解法是：「Michael（麥可）應該別再寫程式了。」

但我喜歡寫程式……

比較務實的解法是，我應該對自己承接的任務更保守一點。我應該把開發工作限制在以下幾類：

• 改善開發者體驗的項目，例如更好的文件、更完善的測試或新的便利腳本
• 憑藉我在公司內的歷史知識或背景脈絡，由我來實作會比交代他人更有效率的變更
• 實驗性質的變更，成功就有收穫，失敗也能直接捨棄

任務四：審閱文件

除了提供日常的客戶支援外，支援工程團隊也會撰寫文件與教學。我對外公開的文件特別講究，因此花了很多時間審閱團隊的文稿，並針對風格、清晰度與技術用語提供回饋。

審閱文件雖然不會占用太多實際時數，卻需要高度專注。我發現要把自己的寫作寫清楚就已經很耗費心力，要閱讀他人的文稿並清楚指出哪裡缺漏或含糊，對我來說更是困難。

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

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

我能做最簡單的改變是更依賴同儕審查。在開發團隊中，軟體工程師們有 90% 的程式碼是彼此審查，不需經我手。要在英文寫作上協調一致的風格比程式碼更難，但我認為約 80% 的文件編修可以在同儕審查中完成。

另一個該做的改變是，在指派文件任務時把自己的餘裕考慮進去。以前我會一次把三篇教學排進支援工程團隊的待辦清單，結果自己卻沒有餘力一次審完。我應該把文件任務分散安排，讓自己有時間審閱。

擺脫電子郵件成癮

過去幾年來，我在與電子郵件保持健康關係和對其成癮而缺乏生產力之間來回擺盪。

我是怎麼失去良好的電子郵件習慣的？

一旦養成健康的電子郵件習慣，通常就容易維持下去。通常讓我脫離健康習慣的，是某個事件給了我一個正當理由去緊盯電子郵件。

最近，負責製造 TinyPilot 金屬外殼的廠商交貨延遲，導致我們外殼用罄。外殼缺貨非常麻煩，因為會讓我們無法組裝新裝置。這意味著我得手忙腳亂地為本地團隊重新指派任務，而這些新任務必須是那種幾天後（希望能）拿到外殼時可以馬上放下的工作。

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

問題在於，緊急狀況結束後，我仍保留不斷查看電子郵件的習慣。而當我查看信箱發現沒有急事時，仍渴望多巴胺帶來的刺激，於是轉而去看社群媒體。那從來沒有效率可言。原本只是花 30 秒查看郵件的休息，最後卻變成花 10 到 30 分鐘無止境地滑動螢幕。

解法一：只在排定的時段收發電子郵件

過去我擺脫不良電子郵件習慣的方法，是把每天的行程明確地規劃出來。

每天早上，我會把工作日切成 30 分鐘為單位的區塊，並決定每個區塊要做什麼。為了避免強迫性地查看郵件，我會排定專門閱讀與回覆郵件的時間，而不是讓郵件成為整天揮之不去的背景雜音。

我需要強迫自己重新養成這個習慣。一旦進入節奏就容易維持，但要進入節奏卻很難。過去的經驗是，只要撐過最初幾天，之後就會變得輕鬆且有成就感，不再需要靠意志力硬撐。

解法二：鼓勵事後回饋

寫下這段文字時是早上 10 點，到目前為止我都忍住沒去查看電子郵件。但我心中仍有強烈的感覺，覺得自己正在耽誤工作進度。

會有這種感覺，是因為團隊夥伴經常會請我就客服工單提供回饋，而這正是我鼓勵他們做的。

我逐漸意識到，夥伴把客服工單上報給我，會讓我的收件匣變得更具時效壓力。原本工單只需要等待兩位支援工程師中的一位有空處理，現在卻卡在我以及那位上報給我的支援工程師身上。我因而覺得必須盡快回覆，以免讓客戶等上好幾天。

有一個我們從未嘗試過的做法是「平行上報」。與其讓客服工單停下來等待我的回饋，我應該鼓勵夥伴在與客戶持續互動的同時，平行地向我徵詢意見。

解法三：授權團隊夥伴多加運用同儕審查

我在討論文件審閱時提過同儕審查，但我應該在各種工作中尋找更多運用同儕審查的機會。這能讓大家與夥伴一起提升技能，也能減少卡在我身上的工作。

業餘專案

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

自從打造了我的第一台 homelab(居家實驗室)伺服器以來，我的辦公室就累積了越來越多的伺服器與網路設備。

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

我想到，打造一座伺服器機櫃或許能讓我們兩人都開心。我能享受一個有趣的 homelab 專案，而她也能欣賞所有線材收納在同一個機櫃中的整潔感。

於是，我打造了第一座伺服器機櫃。組裝過程很有趣，也確實讓一切變得整潔許多。所有設備垂直堆疊後，地板上的線材變少了，整座機櫃還裝有輪子，方便移動清潔。

我第一次使用managed switch(管理型交換器)與 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 了解得越多，就越覺得它不符合我的需求。它似乎期望整合者不僅用 authboss 處理驗證，還要用它來處理頁面渲染與 URL 路徑路由，這超出了我對驗證函式庫的期待。

現在，我正嘗試打造自己的可重複使用驗證函式庫。我並非想讓它成為熱門的開放原始碼套件，只是希望能省去在各個業餘專案間複製貼上一堆驗證程式碼的麻煩。

目前它唯一能做的就是檢查使用者的密碼是否正確。它還稱不上可重複使用，因為客戶端仍必須自行產生密碼雜湊——而我希望這項工作能由驗證函式庫來負責。

開發一個可重複使用的驗證函式庫是個有趣的挑戰，因為它迫使我使用平常不太會用到的 Go 特性。這也考驗了我的架構能力，因為我必須在函式庫的簡化程度與對不同驗證形式的彈性之間權衡取捨。

總結

完成了什麼？

• 與委外製造商合作，展開 TinyPilot Voyager 2a 裝置的第一批量產。
• 打造了第一座家用伺服器機櫃。
• 學會了 Nix 與 NixOS 的基礎。

經驗與收穫

• 身為創辦人，我有幾個能更有效運用時間的機會：
  • 尋找更多委派任務的機會，並將大型任務拆解以便委派。
  • 對於承接的開發任務要更保守。
  • 更有計畫地安排花在電子郵件上的時間。
  • 鼓勵團隊夥伴多加運用同儕審查。
• 伺服器機櫃對於 homelab 愛好者及其另一半來說都很有趣。

下個月的目標

• 達成 9.8 萬美元的銷售營收。
• 讓 TinyPilot 轉向委外製造商的進度保持在正軌上。
• 花在電子郵件上的時間占比控制在 40% 以下。