一句話總結

該繼續擴張，還是把現有的東西做到更好？

亮點

• TinyPilot 創下有史以來最高的單月銷售額，總營收達 69,000 美元。
• 網站改版已超出預算五個月、超支 32,000 美元。
• 我推出了 PicoShare，這是我迄今為止成長最快的專案。

目標成績單

每個月月初，我都會設定當月想完成的目標。以下是本月的達成狀況：

發布 TinyPilot Pro 2.4.0

• 結果：如期發布 TinyPilot 2.4.0
• 評分：A

最新版本新增了多使用者支援，這是客戶期待已久的功能。我們也修復了一個惱人的錯誤，該錯誤過去經常引發客服請求。

完成 TinyPilot 網站的設計改版

• 結果：設計已完成，但尚未上線
• 評分：C

這個專案花的時間比我預期的還要久。設計本身已經完成，但設計公司目前還沒有人力在 TinyPilot 網站上實作程式碼的變更。

完成 TinyPilot 新任支援工程師的入職訓練

• 結果：Diego（迪亞哥）已上手，能獨立處理大多數的支援請求
• 評分：A

找到合適的工程師花了很長的時間，但我很高興現在步入正軌。這已經為我省下了不少時間。

TinyPilot 數據統計

3 月是 TinyPilot 有史以來銷售額與總營收最高的月份。我們比 2 月只多賣了 14% 的裝置，但其中一半是新款 Voyager 2 PoE。這款新機型比標準版貴 60 美元，帶來了 33% 的營收成長。

我的利潤呈現負值，但這比較是支出認列時點的影響。2022 年第一季的利潤為 健康的 16,000 美元，平均每月 5,300 美元（編輯（2022-04-29）：我之前數字算錯了——2022 年第一季實際上虧損了 10,000 美元）。

每位不重複訪客的營收達到 10.49 美元，創下歷史新高。作為對照，去年同期的平均每訪客營收約為 4 美元。這是個好消息，因為我原本的計畫就是先專注於提升網站的轉換率（「bottom of funnel(漏斗底部)」），再來投入行銷。這個指標的成長顯示計畫正在奏效。我認為產品、定價與網站的改進，讓訪客更願意購買。

我又有空閒時間了！

2 月時，我曾思考如何每週只花 20 小時來經營 TinyPilot。我還沒完全做到，但已經有所進展。

佔用我最多時間的工作之一是技術支援，每週要花 8 小時。這也是最難委派的職責，因為招募過程就花了數百小時。即使找到了合適的工程師，培訓也很耗時，因為我腦中累積了兩年的內部知識。

很高興向大家報告，我們已經度過了最艱難的階段。迪亞哥，也就是 TinyPilot 的第一位支援工程師，現在已經在我們的支援論壇上回覆所有問題，所以我平均每週花在支援上的時間已不到 8 小時。他也發表了第一篇教學：在 TinyPilot 上設定 Tailscale 的指南。

我也一直努力讓 TinyPilot 的在地團隊承擔更多責任。例如，本週我們發現，用來組裝 Voyager 2 的那款螺絲現在已經全面缺貨。

正常情況下，我會與我們的機殼設計師合作尋找替代品，並嘗試用新螺絲組裝，但我在寄出郵件前及時打住了。這是讓 TinyPilot 在地團隊承擔更多責任的好機會，所以我請他們主導處理。

我發現自己在 3 月的時間管理上有明顯的不同。過去六個月，我大多數日子結束時都覺得事情沒做完，不得不把重要但不緊急的任務往後延。在 3 月，我經常在下午中段就完成了緊急任務，並有空閒時間投入行銷、自動化與工作委派。

我正在克制自己，不把這些新多出來的時間拿去增加新事務，例如再聘一個人或為 TinyPilot 尋找新功能。我得提醒自己，這些事情永遠比乍看之下還要複雜。

2021 年我忙著應付太多成長型專案，現在是時候把現有的部分最佳化：

• 自動化我們的發布流程
• 自動化我們的 end-to-end testing(端對端測試)
• 更主動地與客戶交流，而不是等到他們聯繫客服才互動
• 在 TinyPilot 客服人員與支援工程師之間建立 escalation paths(升級處理流程)
• 改善與製造商之間的作業流程

該繼續再投資，還是開始獲利了？

在 TinyPilot 成立以來的整段時間，我都忽略短期利潤，專注於長期成長。我避免讓公司陷入虧損，但很樂意維持接近損益兩平的狀態，把所有營收再投入到產品改進上。

我把再投資視為累積動能。假設我的銷售額是每月 3,000 美元，我花 5,000 美元改進產品，讓銷售額提升到每月 4,000 美元，那麼這 5,000 美元是一次性成本，但 TinyPilot 的銷售動能卻永久提升了。

但我不是一家有創投支持的新創公司。我的目標不是無限成長、靠 IPO 致富。在某個時間點，我必須停止把所有資源都投入成長，開始獲取收入。現在就是那個時候嗎？

我目前主要的短期支出是為了可製造性而最佳化 Voyager 2 的電路設計（每月 10,000 至 20,000 美元），以及重新設計銷售網站（每月 5,000 至 6,000 美元）。再過幾個月，我們就會定版 Voyager 2 的電路板，我也不會再一直調整網站，到時成本就會大幅下降。如果我能維持目前的銷售額，只要不再啟動新專案，每月就能賺進 20,000 美元。

我原本的計畫是一旦 Voyager 2 的生產穩定下來，就立刻與我的電機工程合作夥伴著手開發 Voyager 3。開發 Voyager 3 在接下來的六個月中每月約需花費 15,000 至 25,000 美元，將會吃掉我今年剩餘的所有利潤。不僅如此，它還會佔用我大量的時間，因為發布新產品會改變 TinyPilot 內部許多作業流程。

到了這個階段，我認為是時候開始獲取收入了。今年稍晚我仍可啟動新專案，但首先，我希望將銷售額提升到 70,000 至 90,000 美元的區間，這樣我才能在不耗盡所有利潤的情況下投資產品改進。

那些我希望早點知道、關於與設計公司合作的事

早在 9 月，我就聘請了一家設計公司來改善 TinyPilot 的網站。當時我以為這個專案只要六週、花費 7,000 美元。六個月後，我已經花了 39,577 美元，專案卻還沒完成。

我們怎麼會走到這一步？我可以指出設計公司那邊的失誤，但核心問題是我不知道如何有效地與設計公司合作。我過去只聘請過自由接案者，沒意識到與設計公司合作會帶來多大的互動模式改變。

我把這些希望當初就知道的事情記錄下來，既是給自己的提醒，也希望能幫助那些還沒開始與設計公司合作的人。

設計公司需要更多的管理，而不是更少

我聘請這家設計公司時犯下的根本錯誤，就是低估了管理他們所需的時間。

這家設計公司每月為我工作 40 到 60 小時。這跟 TinyPilot 其他每位自由接案者的工時差不多，所以我以為管理設計公司所需的監督程度會跟管理一位自由接案者差不多。我應該要為管理他們預留多得多的時間才對。

與設計公司合作時，你會同時與多位各自負責不同子專案的人互動。人越多，自然就需要越多的管理時間。

舉例來說，假設一名每週工作 40 小時的員工需要每週 6 到 8 小時的管理時間。如果你把這個職位拆成兩個人、每人各做 20 小時，你的管理時間可能會膨脹到每週 10 到 12 小時。員工的總工時相同，但與兩個人溝通反而會造成效率損失。

同樣的邏輯也適用於設計公司。即使你每月獲得 40 小時的工作量，客戶管理設計公司的六名成員，所費的力氣也比管理做同樣工作的單一自由接案者要多得多。

嚴格守住專案範疇

這個專案最大的問題出在範疇界定上。鑑於我把一個六週的專案做成了六個月，你大概也猜到了。

一開始，我與設計公司約定專案只是重新打造品牌。我們會為網站建立新的標誌、配色與字體，然後再評估下一步。但接著就出現了 scope creep(範疇潛變)。設計師們不斷默默地擴大範疇，直到我發現自己已經做到網站的全面改版的一半。

我一直覺得如果再讓他們做久一點，他們就能在當月收尾，但事情卻一直拖延。回頭看，我當時應該要果斷停損，把專案範疇縮回原本計畫的品牌重塑就好。但那時我正忙於 Voyager 2 的發布，所以對我來說最輕鬆的做法就是讓設計公司繼續做下去。

即使我以為自己已經學到教訓，scope creep 這個月又咬了我一口。我為改版建立了一個專案看板，把待辦任務依優先順序排列。我為 3 月預訂了 60 小時的設計公司工時，但不確定設計任務會不會把時數全部用完。於是我在清單最後加了一些低優先順序的錯誤，以備設計公司還有剩餘時間時處理。

你知道接下來會發生什麼……

設計公司把所有設計任務都留在一半完成的狀態，卻用掉了我當月四分之一的時數去修那些低優先順序的錯誤。

往後，我需要設定更明確的期望，讓他們知道在所有關鍵任務完成之前，不要去處理非關鍵的任務。

小心 open loops(未完成迴圈)

如果你把任務 A、B、C 指派給一位自由接案者，他在任務 A 完成 80% 時突然停下來轉去做任務 B，會讓人覺得很奇怪。如果他在任務 B 做到一半時又停下來去做任務 C，那就更奇怪了。

與設計公司合作時，卻很容易陷入好幾個任務都只完成 80% 的局面。也許設計公司的 Alice（艾莉絲）這個月只有 10 小時的空檔，所以她把任務 A 做到 80%。接著換 Bob（鮑伯）上場，但他不想半途接手艾莉絲的專案，所以他開始做任務 B，只做了 30%。不知不覺間，你已經花了 39,577 美元，卻無法使用任何成果，因為全部都只完成了 80% 到 90%。

在 David Allen（大衛·艾倫）所著的 Getting Things Done（《搞定》）一書中，他將未完成的任務描述為「open loops」。你手上的 open loops 越多，專注力就越差，因為每一項都會在你的腦中占據一些空間。自由接案者一次通常只會與你有幾條 open loops，而設計公司可能會同時有 5 到 10 倍之多，而且拖得更久。

Open loops 對你的投資報酬率來說也更不划算。假設你需要在六個月內完成六項任務。如果你聘請個人，他大約每月會交付一項任務。如果你每月月底付款，你幾乎是在付款的同時就享受到工作的成果。與設計公司合作時，他們可能會把這六項任務分給六個人，每個人只花六分之一的時間在你的專案上。到了第五個月，設計公司已經拿走了 80% 的費用，但你卻得到 0% 的效益，因為沒有任何一項任務完成了。

先以時數計費，再轉為包月制

我合作的這家設計公司同時提供時數計費與包月制方案。時數計費是預先購買 30 小時的時數包，然後設計公司會與我合作直到這些時數用完。包月制則是承諾每月固定時數，最低為每月 40 小時。包月制的費率比時數計費便宜 20%，但未使用的時數不能累積到下個月，而且若要取消，必須提前 28 天通知。

我沒意識到的是，時數計費的客戶可能會好幾個月都得不到資源。我從 10 月開始與這家設計公司合作，前兩個月表現很好，但到了 12 月卻大幅下滑。

當時我以為只是假期的淡季影響，但當狀況延續到 1 月，我便向負責人提出了這個問題。他坦承設計公司流失了人力，又接了新的包月客戶，因此很難為 TinyPilot 分配人力，因為我是他們唯一的時數計費客戶。他建議我改簽包月合約以確保優先順序。

我感到很惱火。他們把我的專案排到後面，卻期望我對他們做出更大的承諾？但同時，我也能理解。設計公司本身也是一家小企業，他們想優先服務長期客戶，而非一次性的案子。設計公司早在 10 月就告訴我，作為包月客戶我會獲得優先權，但我沒意識到差別會這麼大。

如果再來一次，我會先買一個 30 小時的時數包作為對設計公司的試用，然後在專案的剩餘期間改為包月合約。在設計公司的行程上擁有固定的保障時數，似乎能帶來更好的品質，因為我在他們的行程上有受保障的時間，而不是一個月裡零散的幾個小時。

業餘專案

PicoShare

PicoShare 是我在 2 月打造的一款開源、極簡的檔案分享工具。

我經常與他人分享圖片、影片和 PDF。如果是為了工作而傳送檔案，把檔案上傳到 imgur 或 mega.nz 再傳連結，總讓我覺得有點不專業。那些服務可不會讓人聯想到「專業的商務溝通」。我也不喜歡用 Google Drive 或 Dropbox，因為它們的介面很礙事，有時還會要求收件人在檢視檔案前先建立帳號。PicoShare 讓我無需依賴第三方服務，就能建立易於分享的連結。

我在 3 月 20 日透過在 /r/selfhosted 版上發布消息，正式發布了PicoShare v1.0.0。反應還算正面，但並沒有引起轟動。在接下來的幾週內，它才慢慢累積起人氣。

YouTube 創作者 David Burgess（大衛·柏吉斯）製作了一部關於 PicoShare 的影片，接著 Hal Gus（哈爾·格斯）又做了一部。一位自架服務部落客寫了一篇教學，介紹如何在 Synology NAS 上安裝 PicoShare（這對我來說別具意義，因為我的第一篇部落格文章就是關於在我的 Synology NAS 上透過 Docker 設定映像檔）。

PicoShare 現在是我創建過成長最快的專案。第一次提交是在 2 月 13 日，目前該專案在 GitHub 上已有 664 顆星。作為對照，TinyPilot 經過近兩年累積了 1.8k 顆星，而 LogPaste 在一年後有 201 顆星。

開源開發者們也做出了很棒的程式碼貢獻：

• @viktorpenelski 新增了永久保留分享的檔案的選項。
• @dertuerke 為檔案大小新增了易讀的格式（例如，顯示「1.53 MB」而非「1530000 bytes」）。
• @dertuerke 新增了「Copy to Clipboard」按鈕。

我新增了對 multiarch Docker images(多架構 Docker 映像檔)的支援，所以現在你可以在像 Raspberry Pi 這類 ARM 架構的系統上執行 PicoShare Docker 映像檔。建立 multiarch 建置的過程出乎意料地簡單，但因為流程不斷在變，要找到說明文件卻非常困難。

我也建立了一個線上展示伺服器。一開始我刻意避免這麼做，因為我不想處理有人上傳非法內容或耗盡頻寬的問題。後來，我想到可以在展示伺服器上加入一項限制，讓使用者只能存取從自己 IP 上傳的檔案。這樣既能讓大家試玩服務，又能限制被濫用的程度。

總結

完成了什麼？

• 發布了 TinyPilot Pro 2.4.0
• 發布了 PicoShare 1.0.0
• 培訓了 TinyPilot 的第一位支援工程師

學到的教訓

• 與設計公司合作所需的管理方式與自由接案者不同。
• 為自架工具建立 Docker 映像檔能大幅提升其吸引力。
  • 我懷疑 PicoShare 能如此快速吸引使用者的原因，在於只需一行 Docker 指令就能執行。

下個月的目標

• 發布一篇關於使用 TinyPilot 打造 homelab NAS(家用實驗室 NAS)伺服器的部落格文章與影片。
• 完成 TinyPilot 網站的改版。
• 發布一個 TinyPilot Pro 版本，提供可選擇加入的 H264 video over WebRTC(透過 WebRTC 傳輸 H264 視訊)實驗性支援。