一句話總結

當長期任務停擺時，就該擔心了。

重點回顧

• TinyPilot 單月營收達 11.2 萬美元，史上首次突破六位數大關。
• 我嚴重高估了 TinyPilot 出貨團隊還有多少餘裕。
• 長期任務就像金絲雀，能預警資源即將耗盡。

目標達成度

每個月月初，我都會宣告想完成的事。以下是本月的達成狀況：

準備將 TinyPilot 的出貨作業轉移給第三方物流（3PL）廠商

• 結果：已針對單一低銷量的產品啟動導入流程
• 評分：B

我低估了在地團隊能投入這件事的餘裕。加上銷售額意外暴增，我們沒能把內部出貨流程調整成適合 3PL 廠商的模式。不過，即使流程還不完美也能先往前推進，等 3PL 廠商幫我們騰出時間後再慢慢改善。

持續培訓新的支援工程師

• 結果：兩位支援工程師已能獨立處理約 80% 的支援工單。
• 評分：A

支援工程團隊的表現比我預期更出色。除了處理進階的支援需求，他們還會深入追查問題根源，從源頭減少錯誤發生，並改善 TinyPilot 的診斷日誌。

減少我在關鍵路徑上的專案

• 結果：我克制住想發起任何新專案的衝動。
• 評分：B

推出新的 TinyPilot 機型一向需要花我大量時間。我已經歷過夠多次，足以預期大部分的工作，但我也知道不管事前規劃多周全，總還是有意料之外的工作。即使有些日子感覺自己還有餘力，我還是盡量讓自己的時間保持彈性。

TinyPilot 數據一覽

TinyPilot 的銷售再創歷史新高，總營收達到 11.2 萬美元。這是 TinyPilot 有史以來第一次單月營收突破六位數。

這次大幅成長主要歸功於 TinyPilot 在 Linus Tech Tips 上獲得正面提及，這是自架實驗室（homelab）愛好者圈中最受歡迎的 YouTube 頻道之一。雖然那支影片主要是在評測競爭對手的產品，但該頻道訂閱數眾多，讓 TinyPilot 在接下來兩週內訂單大幅湧入。

很高興看到即使在成本異常偏高的情況下，三個月滾動獲利仍穩健維持正數。TinyPilot 目前正花較高成本以 3D 列印方式生產超出原有產能的外殼，但等到一月改用金屬外殼後，成本應該會大幅下降。

我們連幫自己省時間的時間都沒有

11 月的目標之一是開始將出貨作業轉移給第三方物流（3PL）廠商。我請出貨團隊的一位成員檢視現有工作流程，並準備移交給 3PL 廠商。

下一週，我們因為 Linus Tech Tips 影片帶來訂單暴增，因此完全沒空研究轉移到 3PL 的事。又過了兩週，我們仍在消化暴增的訂單，同樣沒有任何進展。

下一次我與出貨團隊成員開會時，我問他平常處理這類非例行任務還剩下多少餘裕，結果得知答案大概是零。出貨團隊光是組裝裝置、出貨以及回覆支援請求這些短期任務，就已經佔滿了一週的所有工時。

這種情況我並不陌生，只不過以往沒有短期餘裕的人通常是我。

對於任何工作流程，通常都有顯而易見的省時方法。可能是自動化、增聘人手、改用代管服務等等。問題在於，改變工作流程本身就有摩擦成本。

過去幾個月，我一直在畫漂亮的 圖表來說明外包與委派所需的時間投入。秉持這個精神，以下是我在把某項任務交給別人前後所花費的時間：

一開始，這項任務很耗時，因為所有工作都得由我自己來做。當我聘請他人時，我的工作量反而更大，因為除了原本的任務，我還得加上招募與培訓新人的工作。直到新人完全上手後，我才能真正省下時間，但這可能需要數週甚至數月，取決於任務的複雜度。

實務上，一天只有這麼多小時。如果把工作時數的上限也考慮進去，會發生什麼事？

糟了，現在我根本無法達到聘用後省時的狀態，因為短期內已經沒有餘裕去招募和培訓新人。我連幫自己省時間的時間都沒有。

用長期任務作為耗竭的早期警訊

轉移至 3PL 廠商的延宕，讓我意識到自己需要一套更好的早期預警機制，來察覺餘裕即將耗盡的狀況。

我目前想到最好的做法，是更謹慎地平衡每個人的短期與長期任務。舉例來說，支援工程師的緊急職責是在 TinyPilot 客服論壇和 CRM 平台上回覆客戶的支援請求。支援量時高時低，因此當支援工程師有空檔時，他們會去尋找支援請求中的重複模式，並發布說明文章或深入調查更根本的錯誤修正。

TinyPilot 的每個人都有短期與長期任務的組合：

長期任務可以扮演礦坑裡金絲雀的角色。當一個團隊在長期任務上的進展持續放緩，就代表他們可能已接近負荷上限。這時，我就該想辦法減輕負擔，可能是減少職責或增加人力。

用長期任務作為警訊有兩個挑戰。第一個是，最常忽略長期任務的團隊就是創辦人團隊，也就是我。當我負荷過重時，我不會注意到其他團隊在長期任務上的放緩。就算注意到了，我也沒有時間處理。我想解方是對自己接手的專案數量更警覺一些，保留餘裕來應付轉換流程的成本。

另一個問題是，出貨團隊的長期任務最不明顯。我們的製造與出貨流程並不是那種每週都能持續改善的工作。但隨著我們將出貨與製造轉移給第三方廠商，出貨團隊的職責將轉向客戶支援。客戶支援在短期工作（回覆支援請求）與長期工作（完善內部標準流程）之間，有著更自然的平衡。

跳出 Ansible 坑

Ansible 是一套用來自動化設定伺服器的工具。我已經用了七年，所有自家實驗室裡的虛擬機器都是用它來管理的。

早在 2020 年開始開發 TinyPilot 時，我需要一種方式把程式部署到 Raspberry Pi 上，並設定 TinyPilot 所需的作業系統功能。Ansible 擅長遠端系統設定，因此非常適合。

當我發布 TinyPilot 時，對我而言最簡單的安裝方式，就是複製我在開發時使用的工作流程。我寫了一個簡單的安裝腳本來初始化 Ansible 環境，然後透過 Ansible 安裝 TinyPilot。

當時我就知道，比較正規的安裝方式應該是用 Debian 套件。問題是我完全不懂怎麼製作 Debian 套件，而且感覺很麻煩。我是不是得自己架一個 apt 軟體庫？要不要管理金鑰？TinyPilot 依賴 nginx，那我該怎麼從自己的套件去設定 nginx？

兩年半後，開發團隊正在為我當初選擇 Ansible 付出代價。隨著 TinyPilot 功能越來越多，我們的 Ansible 設定變得極其複雜。如果安裝程式是單純的 shell 腳本或 Debian 套件，安裝大概只要 10 到 20 秒。但 Ansible 帶來的額外開銷，卻讓安裝與更新時間拉長到六分鐘以上。

除了對終端使用者的影響，Ansible 還傾向於吞噬開發資源。Ansible 的程式碼除錯又慢又繁瑣，尤其是在處理持續整合環境中沒有的作業系統與架構時。小小的更動常常會膨脹成一週的開發時間。

過去幾個月，開發團隊一直在探索如何將 Ansible 程式碼移植成 TinyPilot 的 Debian 套件。很高興地說，我們已經有了立足點。我們建立了一個混合式解法，讓 TinyPilot 的 Ansible 角色去安裝最新版的 TinyPilot Debian 套件。這讓我們能逐步將 Ansible 程式碼搬移到 Debian 套件中。

以下是我希望當初開始開發 TinyPilot 時就知道的 Debian 相關知識：

• 你可以建立並發佈獨立的 Debian 套件，而不需要自行架設 apt 軟體庫。
• 如果照著對的教學做，建立一個簡單的 Debian 套件只要 15 分鐘，教學可參考這篇。
• 你可以用 Docker QEMU 在 x64 系統上建置 ARM 架構的 Debian 套件。
• 如果你的程式是用 Python 這類可攜式語言寫的，你可以跳過 QEMU，直接建置與架構無關的 Debian 套件。
• 如果你的套件需要設定另一個套件，典型的做法是在設定目錄中新增一個檔案，而不是去動到對方套件擁有的檔案。
  • 例如，TinyPilot 的 Debian 套件可以透過在 /etc/nginx/sites-enabled/ 目錄中新增一個檔案來設定 nginx。

學習 Debian 最困難的部分，是在眾多雜訊中找到有用的資訊。很多資源基本上就是叫你「去讀那本 9,000 頁的 Debian 維護者指南，但過時的部分就自己忽略」。

我覺得最有幫助的指南是：

• 「Creating and hosting your own deb packages and apt repo」，作者 Alex Couture-Beil
• 「Pragmatic Debian packaging」，作者 Vincent Bernat

Vincent 甚至還熱心地跟我進行視訊通話，解答我對 Debian 套件剩下的疑問。

業餘專案

ScreenJournal

我看了很多電視影集和電影，也很喜歡向朋友推薦，但我常常忘記自己想推薦哪一部。

我找過不少像 Goodreads 那樣可以追蹤閱讀紀錄、但用來追蹤電影和電視的 App，卻沒有一個符合我的想像。我覺得朋友們已經對預設公開的社群 App 感到疲乏，所以我想要一個能讓一小群朋友分享推薦的小社群。比較像 Discord，而不是 Twitter。

我開始開發一個與朋友分享影評的 App，叫做 ScreenJournal：

它還沒完全到能上線的程度，因為目前的評論是私密的，而且只支援單一使用者。現在它比較像是一個人的私人電影日記，但我清單上的下一個功能就是支援多使用者。

使用者管理是出了名的難做對，所以我一向避免自己實作。過去幾年，我都是用朋友 David Toth 的 UserKit 服務來管理使用者。UserKit 很棒，但它尚未對外開放，所以想在自己伺服器上運行 ScreenJournal 的其他開發者就很不方便。

我找過 Go 的開源使用者管理框架，但大多數都依賴外部服務的 OAuth，這不是我想要的。剩下的則又笨重又複雜，讓我提不起勁去用。

所以，我正冒險自己實作使用者管理。工作階段管理我打算用 jeff，驗證則會用 bcrypt，然後聽天由命。

總結

完成了什麼？

• 已與 3PL 廠商啟動導入流程。
• 在幾個重要面向改進了 TinyPilot 的 Debian 套件。
• 為國際外包人員找到了更好的付款平台。
  • Deel 的體驗很差，我對 Remote.com 也不太滿意，所以我們決定改用 Pilot。

經驗教訓

• 長期任務是資源耗竭很好的領先指標。
  • 如果一個團隊在長期任務上的進展持續放緩，就必須在還有餘裕切換流程之前及早處理。
  • 對創辦人而言，特別重要的是要為長期任務保留時間，否則就無法有效回應其他團隊的資源耗竭。
• Debian 打包並沒有一開始想的那麼可怕。

下個月的目標

• 完成來自 3PL 廠商的第一筆出貨。
• 完成下一個 TinyPilot Pro 版本的程式碼。
• 為一月發表 TinyPilot Voyager 2a 做準備。