一句話總結

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

亮點

• TinyPilot 創下有史以來銷售表現最好的月份，總營收達 6.9 萬美元。
• 網站改版專案已超支 3.2 萬美元、進度延宕五個月。
• 我推出了 PicoShare，這是我至今發表過成長最快的專案。

目標達成度

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

發布 TinyPilot Pro 2.4.0

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

這次更新新增了多使用者支援，這是客戶期待已久的功能。我們也修掉了一個一直帶來大量客服請求的惱人錯誤。

完成 TinyPilot 網站的設計大改版

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

這個專案花的時間還是一直超出我的預期。設計本身已經完成了，但設計公司目前還沒有餘力在 TinyPilot 的網站上實作程式碼變更。

完成 TinyPilot 新任支援工程師的 onboarding

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

花了很久才找到合適的工程師，很高興現在運作得很順利。這已經幫我省下了大量時間。

TinyPilot 數據

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

這個月呈現虧損，但更多是費用認列時點的關係。2022 年第一季的獲利為 穩健的 1.6 萬美元，平均每月 5,300 美元（編按（2022-04-29）：數字算錯了——2022 年第一季我實際上虧損了 1 萬美元）。

每位不重複訪客帶來的營收達到 10.49 美元，創下新高。作為對照，去年同期的平均訪客營收大約是 4 美元。這是個好消息，因為我原本的計畫就是先專注提升網站的轉換率（也就是所謂的「漏斗底部」），之後再來做行銷。這個指標的成長顯示計畫正奏效。我認為產品、定價和網站的改進，讓訪客更願意下單了。

我又有空閒時間了！

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

過去最佔用我時間的是技術支援，每週要花 8 小時。這也是最難交出去的工作，因為光是招募就花了上百小時。就算找到合適的工程師，培訓也很耗時，因為我腦中累積了兩年的內部知識。

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

我也一直在努力讓 TinyPilot 的在地團隊承擔更多責任。舉例來說，這週我們發現用來組裝 Voyager 2 的那款螺絲現在到處都缺貨了。

照以往，我會和機殼設計師合作找替代品，並試著用新螺絲組裝，但在寄信前我及時煞住了。這是讓 TinyPilot 在地團隊承擔更多責任的好機會，所以我請他們主導處理。

我發現 3 月在時間管理上有明顯的不同。過去六個月，我大多數日子結束時都覺得事情沒做完，不得不把重要但不緊急的事往後延。但在 3 月，我常常在下午中段就把緊急的事做完，還有空閒時間可以投入在行銷、自動化和授權分工上。

我正在克制自己，不要把這些新多出來的時間拿去增加新東西，像是再請一個人或為 TinyPilot 開發新功能。我得提醒自己，這些事總是比一開始看起來複雜得多。

2021 年我為了應付太多成長型專案而疲於奔命，現在是時候好好優化現有的一切了：

• 自動化我們的發布流程
• 自動化我們的端對端測試
• 更主動地與客戶交流，而不是等他們來找客服
• 建立 TinyPilot 客服人員與支援工程師之間的升級處理流程
• 改善與製造商的協作流程

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

自 TinyPilot 成立以來，我一直忽略短期獲利，而是專注於長期成長。我避免讓公司虧損，但很樂意在接近損益兩平的狀態下，把所有營收再投入去改善產品。

我把再投資視為在累積動能。如果我的月銷售額是 3,000 美元，而我花 5,000 美元去改善產品，讓月銷售額提升到 4,000 美元，那 5,000 美元是一次性成本，但 TinyPilot 的銷售動能就會永久提升。

但我不是靠創投支撐的新創。我的目標不是永遠成長、靠 IPO 致富。在某個時間點，我必須停止把一切都投入成長，開始獲利。現在就是那個時候嗎？

我目前主要的短期支出是為了讓 Voyager 2 的電路設計更適合量產（每月 1 至 2 萬美元），以及銷售網站的改版（每月 5,000 至 6,000 美元）。再過幾個月，我們就會定版 Voyager 2 的電路板，我也不會再一直去改網站，到時成本就會大幅下降。如果能維持目前的銷售額，光是不再啟動新專案，我每個月就能賺進 2 萬美元。

我原本的計畫是一旦 Voyager 2 的生產穩定下來，就立刻和電機工程夥伴合作開發 Voyager 3。開發 Voyager 3 在接下來六個月每月要花約 1.5 至 2.5 萬美元，會吃掉我今年剩下的所有獲利。不僅如此，它還會佔用我大量時間，因為推出新產品會改變 TinyPilot 內部許多工作流程。

在這個時間點，我認為該開始獲利了。我今年稍晚還是可以啟動新專案，但首先我想把銷售額提升到 7 至 9 萬美元的區間，這樣我才能在不耗盡獲利的情況下投資產品改進。

早知道就好了：與設計公司合作的心得

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

怎麼會變成這樣？我可以指出設計公司那邊的失誤，但核心問題是我不知道該如何有效地與設計公司合作。我以前只聘過自由接案者，沒意識到與公司合作會讓互動模式完全不同。

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

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

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

這家公司每月為我工作 40 至 60 小時。這跟 TinyPilot 其他每位自由接案者的工時差不多，所以我以為管理這家公司的心力跟管理一位接案者差不多。我應該要預留更多時間來管理他們才對。

當你和一家公司合作時，你其實是在和多位各自負責不同子專案的人互動。人越多，自然就需要更多管理時間。

舉例來說，假設一名每週工作 40 小時的員工需要每週 6 至 8 小時的管理時間。如果你把這個職位拆成兩個人、每人每週工作 20 小時，你的管理時間可能會暴增到每週 10 至 12 小時。員工的總工時相同，但因為你要和兩個人溝通，效率就產生了耗損。

同樣的邏輯也適用於設計公司。即使你每月只得到 40 小時的產出，客戶要花在管理一家有六名成員的公司上的心力，還是會比管理一位做同樣工作量的自由接案者來得多。

嚴格守住專案範疇

這個專案最大的問題在於範疇控管。你可能已經猜到了，畢竟一個六週的專案做了六個月。

一開始，我和設計公司約定這個專案只是做品牌重塑。我們會為網站打造新的標誌、配色和字型，然後再評估下一步。但接著範疇就開始蔓延了。設計師們不斷默默地擴大範圍，直到我發現自己已經做到整個網站全面改版的一半。

我一直覺得如果再讓他們做一下下，他們這個月就會收尾，但事情卻一直拖下去。回過頭看，我應該要直接認賠、把專案範疇縮回原本約定的品牌重塑。但當時我正忙於 Voyager 2 的發布，所以對我來說最省事的做法就是讓設計公司繼續做下去。

即使我以為自己已經學到教訓，範疇蔓延這個月還是又咬了我一口。我做了一個專案看板，把改版待辦事項依優先順序排列。我為 3 月預定了 60 小時的公司工時，但不確定設計工作是否會用完整個時數。我在清單最後加了一些低優先順序的錯誤，心想如果公司還有剩餘時間就可以處理。

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

設計公司把所有設計工作都留在半完成的狀態，卻把我這個月四分之一的時數拿去修完了所有低優先順序的錯誤。

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

小心未完成的開放迴圈

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

但和設計公司合作時，很容易就會陷入好幾個任務都只完成 80% 的局面。也許公司裡的 Alice 這個月只有 10 小時的空檔，所以她把任務 A 做到 80%。接著換 Bob 接手，但他不想半路接手 Alice 的專案，所以他轉去做任務 B，做到 30% 就停了。還沒回過神，你就已經花了 39,577 美元，卻什麼成果都無法使用，因為所有工作都只完成了 80% 至 90%。

在《搞定》（Getting Things Done）一書中，David Allen 把未完成的任務稱為「開放迴圈」。開放迴圈越多，你的專注力就越差，因為每一個都會佔據你腦中一點空間。一位自由接案者通常一次只會和你有幾個開放迴圈，而一家設計公司可能會有 5 到 10 倍之多，而且拖得更久。

開放迴圈對你的錢來說也是更差的投資。假設你需要在六個月內完成六項任務。如果你聘請個人，他每個月大約會交付一項任務。如果你每月底付款，你差不多是在付款的同時就享受到成果。但如果是設計公司，他們可能會把這六項任務分給六個人，每人只花六分之一的時間在你的專案上。到了第五個月，公司已經拿走了 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,800 顆星，LogPaste 則花了一年才有 201 顆星。

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

• @viktorpenelski 新增了永久保留分享檔案的選項。
• @dertuerke 新增了檔案大小的人類可讀格式（例如顯示「1.53 MB」而非「1530000 bytes」）。
• @dertuerke 新增了「複製到剪貼簿」按鈕。

我也加入了對多架構 Docker 映像檔的支援，所以現在你可以在 Raspberry Pi 這類 ARM 架構的系統上執行 PicoShare 的 Docker 映像檔。建立多架構建置的過程出乎意料地簡單，但卻很難找到說明文件，因為流程一直在變。

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

總結

完成了什麼？

• 發布了 TinyPilot Pro 2.4.0
• 發布了 PicoShare 1.0.0
• 完成了 TinyPilot 首位支援工程師的培訓

學到的教訓

• 與設計公司合作和管理自由接案者的方式不同。
• 為自架工具提供 Docker 映像檔會讓它更具吸引力。
  • 我猜 PicoShare 之所以能這麼快吸引到使用者，就是因為只要用一行 Docker 指令就能跑起來。

下個月的目標

• 發表一篇關於用 TinyPilot 打造家用實驗室 NAS 伺服器的部落格文章和影片。
• 完成 TinyPilot 網站的改版。
• 發布一個支援透過 WebRTC 以 H264 進行視訊串流（可選擇加入的實驗性功能）的 TinyPilot Pro 版本。