一句話總結

燒錄 microSD 出乎意料的困難

本月亮點

• TinyPilot 創下有史以來營收第二高的月份。
• TinyPilot 將生產轉移給第三方廠商的作業已接近完成。
• 我可能已經踏入機械鍵盤的「黑暗面」。

目標成績單

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

盡快將生產轉移至委外製造商

• 結果：首批產品有個小問題，但轉移應該很快就能完成。
• 評分：B

我們已收到委外製造商生產的首批量產裝置，預計在 11 月出貨給客戶。

我原本希望這批產品能完美無缺，讓我們可以宣告轉移完成。可惜組裝過程中出現了一個小錯誤，必須在我們辦公室修正，所以還沒辦法做到從製造商到倉庫再到客戶的順暢流程。

減少 TinyPilot 軟體發布流程中的手動作業

• 結果：我們消除了一項原本綁在我身上的手動發布工作。
• 評分：A

我一直在尋找自動化、簡化 TinyPilot 軟體發布流程的方法。我特別想讓自己從 TinyPilot 日常工作流程的關鍵路徑中退出。10 月，我們在這兩方面都有進展，自動化了 TinyPilot Pro 新版本推出時更新 TinyPilot 網站的方式。

以前是我發布新版本後，再手動更新網站、指向新的下載連結。現在網站會與我們的更新服務同步，能自動偵測到新版本。

制定更有效執行 TinyPilot Pro 授權的計畫

• 結果：尚未在計畫上有任何進展。
• 評分：F

開發團隊在 10 月的可用時間比我預期的少，所以最終沒能為授權控管擬定計畫。

TinyPilot 數據一覽

這是 TinyPilot 史上營收第二高的月份，但我完全不知道原因。數據分析上看不出特別之處，我也沒注意到有新的評測或報導。我們在2022 年 10 月也有強勁的銷售表現，所以可能只是季節性因素。

我原本預期數字會稍微下滑，因為我把重心都放在生產轉移上，沒什麼投入行銷。很高興看到我們還能靠著動能維持下去，不過在 2023 年最後幾個月，我也開始要增加對成長的投資。

與新製造商把 microSD 弄對的奮鬥

消失的記憶卡

TinyPilot 裝置的資料是儲存在一種叫做 microSD 的小小記憶卡上。在製造商預定寄出首批 TinyPilot 樣品的前幾天，他們注意到我寄給他們的參考機裡有 microSD，便問我是不是需要 microSD？

結果發現，製造商在物料清單（BOM）裡完全沒有列入 microSD。我自己也一直沒發現少了這項。

幸好，採購並燒錄 microSD 是個快速又單純的流程。我們原本就有一家會印上 TinyPilot 標誌的 microSD 供應商。我們讓製造商與該供應商直接聯繫，並向製造商說明如何將 TinyPilot 的軟體燒錄到 microSD 上。

我和製造商都認為不值得為了 microSD 而延後首批樣品。我們決定讓他們先出貨不含 microSD 的裝置，過一兩週再補寄記憶卡。

結果首批樣品出現了一大堆問題，讓我完全忘了 microSD 這回事，而製造商也真的就沒寄來。

檢查 microSD 是否正確燒錄

到了 10 月中，製造商說他們已經修正了我針對首批樣品提出的所有問題。他們準備寄來一批小量的量產批次，應該是完整無缺、可以直接出貨給客戶的狀態。

我們仍打算對首批產品進行額外的品質檢驗，確保符合我們內部的標準。其中一項驗證就是檢查製造商是否正確燒錄了 microSD。

直到這批貨預定抵達的兩天前，我才想到——我到底要怎麼檢查製造商有沒有把 microSD 燒錄正確？我想確保記憶卡上的每一個位元組都正確無誤。

驗證 microSD 並不是件簡單的事，所以我請 TinyPilot 的支援工程團隊寫一個快速的 shell 腳本，把製造商的 microSD 與我們的「黃金」映像檔逐一比對並回報差異。他們及時在測試前把腳本完成了。

首批產品抵達後，我插入一片 microSD，執行我們的完整性檢查腳本，結果顯示完全吻合。太好了！

我們接著做了功能測試，一切都正常運作。我非常開心。這代表製造商這批做得完全正確，我們可以宣告轉移到第三方製造商的任務大功告成了。

就在我準備關掉最後一台測試中的 TinyPilot 時，我發現有點不對勁。影像設定並不是 TinyPilot 出廠的預設值，看起來像是有人在我之前用過這台裝置。

我關掉正在測試的裝置，重新執行 microSD 檢查腳本。這次應該一定會回報有變更，因為我在測試過程中改了很多設定。沒想到，腳本卻回報我的 microSD 與黃金映像檔完美一致。

大事不妙。

雖然這個腳本在支援工程師的電腦上運作正常，但在我的測試環境中卻總是回報假的相符結果（false positive）。

進一步檢查 microSD 後，很明顯製造商誤解了我們的指示。我們希望他們用一片測試用的 microSD 進行品管，完成後再換上一片全新燒錄好的卡才包裝出貨給客戶。但製造商並沒有做這個更換的動作，所以出貨給客戶的其實是已經用過的 microSD。

幸好，這個錯誤在我們辦公室相對容易修正。本地團隊把每一盒都打開，將 microSD 重新燒錄回乾淨的狀態，再重新包裝並送往倉庫。

長期來看，我們當然不想在辦公室重燒每一片 microSD。向製造商回報這個問題後，他們表示確實誤解了指示，並已修正流程，確保每一片送到客戶手上的 microSD 都是全新燒錄的映像檔。我們會再驗證下一批貨，但我有信心這個問題快要結束了。

我本來可以如何避免 microSD 的問題？

microSD 的問題是一連串早期錯誤累積而成的：

• 我沒注意到製造商的物料清單中少了 microSD。
• 製造商從未寄來 microSD 樣品，而我也忘了追蹤。
• 直到流程後期才想到要如何驗證 microSD。
• 我低估了 microSD 檢查腳本應該具備的嚴謹程度。

當初審核 BOM 時，我只是憑記憶覺得東西都齊了。其實我應該更嚴謹地把現有產品拆解、逐一盤點，再確認與製造商的 BOM 是否一對一相符。

這已經是第二次遇到製造商承諾跳票的問題了，而我還是沒找到很好的解法。整體來說，他們多數任務都能掌握，但如果我不去追蹤，大約有 10% 的工作會被遺忘。我通常只在等某個東西時才會提出，但這樣就很容易讓 microSD 或說明書這類看似不重要的零件被忽略——直到它們卡住出貨才發現重要性。

我對 microSD 檢查腳本的投入也不夠。當時覺得這只是一次性的腳本，不需要像對待面向客戶的程式碼那樣花時間與心力。但遇到假相符的狀況後，我才意識到這個腳本在品質檢驗過程中必須正確運作有多重要，否則錯誤的代價會很高。因此，我們正按照建立正式產品程式碼的標準流程，重新撰寫這個腳本。

我還不確定該如何端到端地驗證製造商的流程。當我們還在內部生產時，我們有一套放在 Notion 上的操作指示，全團隊照著做就好。我們沒辦法與製造商共用 Notion 工作區，因為他們的作業員並非都能讀懂英文。所以我們給他們英文版的操作指示，再由製造商翻譯成越南文，讓作業員閱讀越南文版本。我無法驗證越南文的流程是否與英文版一致。

要求提供品管流程的影片還算有幫助。影片能以不受語言限制的方式呈現製造商如何執行品管。但要拍到整個流程從頭到尾的影片很困難。品管流程的影片並沒有清楚顯示他們用來測試的 microSD 最後竟然留在了最終產品中，我也不確定該怎麼防止這種情況。

製造商其實有邀請我去越南參觀工廠。我以今年已經出差太多為由婉拒了，但回頭看，或許那趟拜訪就能避免一些昂貴的錯誤。我當時也可以考慮讓本地團隊的成員代為前往。

建立客戶成功流程

年初時，TinyPilot 本地團隊的工作大約是 20% 客服、80% 組裝與出貨。隨著我們今年將生產與出貨外包，這個比例已經大幅改變。到了 2024 年初，組裝與出貨應該會降到本地團隊工作量的 0%。

問題是，客服目前仍佔不到本地團隊每週工時的一半，那麼多出來的時間要怎麼運用？

團隊從年初就一直在討論這個問題。最自然的轉變，似乎是從被動回應支援請求，轉為主動聯繫既有客戶。有些公司把這個職能稱為「客戶成功」（customer success）。

說來有點難為情，我很少主動聯繫客戶。這是那種重要但不緊急的事，總是被我忽略。但如果我能教會本地團隊來做，就不會再受限於我個人的時間與精力。

我們正在試行一套新的客戶成功流程，步驟如下：

1. 客服團隊研究在 TinyPilot 上花費較多的客戶（特別是回購客戶）。
2. 客服團隊寄出人工撰寫的電子郵件，提及客戶公司與訂單的具體細節（避免看起來像自動發送），並邀請對方通話，討論功能需求或痛點。
3. 與客戶會談，了解他們如何使用 TinyPilot。
4. 將客戶的回饋整合到我們的產品路線圖中。

當我以客戶身分收到其他企業的主動聯繫時，通常都明顯是出於自利。他們會說像是「我們想幫您更了解我們的產品」這類話，但其實只是想讓我多買一點。

我希望 TinyPilot 的客戶聯繫是合作導向，而不是寄生或貪婪的感覺。我認為這能幫助我們將路線圖調整為客戶真正想要的功能，也能讓我們發現原本不會察覺的 TinyPilot 新機會。

業餘小專案

再見 Ansible，你好 Nix

過去幾年，我一直用 Ansible 來管理開發環境，但它的許多痛點讓我越來越受不了。過去幾個月來，我一直在嘗試用 Nix 取代 Ansible試了幾個月，現在總算大功告成了。

我以前就看過Nix Home Manager，但一直不懂它的用意。它是管理我家目錄下的檔案？NixOS 不是已經管理了整個系統嗎？

我當時沒搞懂的關鍵是：

• Home Manager 可在任何 Linux 或 Mac 系統上運作，不限於 NixOS。
• 因為 Home Manager 專為文字檔最佳化，它在管理文字檔的介面上比 NixOS 更好用。

現在，我不再用 Ansible 管理開發系統，而是改用 Home Manager 加上針對專案的 Nix flakes 來管理一切。我已經超過一個月沒跑過 Ansible playbook 了。

一個明顯的改變是，我更常為常用指令設定與使用 bash 別名。以前要新增 bash 別名，得先加到 Ansible playbook，再到每台想套用的系統上重新執行 playbook。但在我的系統上跑 Ansible playbook 又慢又容易失敗，結果常常一半系統有這個別名、一半沒有。摩擦力太大，讓我很少有動力去新增別名、並把它融入日常習慣。

改用 Nix 後，Home Manager 現在統一管理我所有的 bash 別名。如果想新增一個 shell alias，我只要編輯 ~/.config/home-manager/home.nix，然後執行 home-manger switch 來套用變更（其實我把它縮短成一個 bash alias：hs）。整個過程不到一分鐘，而且不像 Ansible 那樣會因為外部因素而失敗。

我本來想全面轉換到 NixOS，但因為我平時使用的 Debian 開發環境與 NixOS 差異太大，一直遇到困難。使用 Home Manager 則是在全面投入 Nix 與保留熟悉的 Debian 工作流程之間，取得一個很好的平衡。

我現在成了奇怪的機械鍵盤人

在 Lex Fridman 訪談 Python 創始人 Guido von Rossum 的節目中，Lex 花了好一段時間岔題，大談他有多愛他的 Kinesis Advantage 2 鍵盤。

Kinesis 是機械鍵盤的知名廠商。他們的鍵盤很特別，按鍵位於凹陷的鍵井中，而且鍵盤的左右兩半相隔數英吋。

Lex 對他的 Kinesis 鍵盤愛到甚至搭飛機都要帶著，寧願扛著一塊巨大的鍵盤，也不願用筆電內建的鍵盤。

我從 14 歲起就一直使用某個版本的 Microsoft 人體工學鍵盤。我喜歡它，但不像 Lex 談起 Kinesis 那樣著迷，所以這幾個月我也對機械鍵盤產生了好奇。

我只認識幾個用機械鍵盤的人，一直不太懂它的魅力在哪。他們想沉迷於某種嗜好也無妨，但我總覺得一把鍵盤能帶來的最大樂趣也就那樣，何必費事？

後來，我好奇起來，開始深入研究高階鍵盤。我清醒的大部分時間都在鍵盤前，或許我真的應該投資來優化這個體驗。

看了 Kinesis、Ergodox 和 ZSA 等幾個選項後，我最後選擇了Kinesis Advantage 360。

用這把鍵盤的第一天真的很煎熬，打字速度大概只剩平時的 5%。那天有很多文書要處理，所以隔天早上我先把它收了起來。

第二天好一些，但還是很吃力。我堅持下去，現在打英文文章時在這把鍵盤上反而更快，但寫程式時就變慢了。像 [、{ 和 = 這類符號，我在這把鍵盤上還沒習慣。即使已經重新映射過按鍵讓它們更好按，我仍在努力建立肌肉記憶。

我看過其他人的心得，說習慣 Kinesis 後再切回一般鍵盤也沒問題，但我的經驗並非如此。當我切回 Surface Pro 6 上那個擁擠的筆電鍵盤時，會打出成堆的錯字。也許最終我還是能兩邊都用得自在。

雖然有 60 天的退貨期，但到這個階段，我很確定會繼續用 Kinesis。

總結

完成了什麼？

• 我們出貨了由委外製造商生產的首批 TinyPilot Voyager 2a 裝置。
• 消除了 TinyPilot 發布流程中的手動作業。
• 我換成了機械鍵盤。

學到的教訓

• 更主動地追蹤製造商的承諾。
  • 這是我以前就犯過的錯，卻沒有好好處理。
  • microSD 事件重演了同樣的模式：製造商承諾要做某件事，我以為他們會處理，結果雙方都忘了，後續就出了問題。
  • 我需要開始記錄他們的承諾，並每週檢視進度，以防他們遺忘。
• 逐項核對 BOM。
  • 幾個月前製造商寄來物料清單時，我只是心裡大概對一下預期的項目，結果沒發現少了 microSD。
  • 未來再走 BOM 確認流程時，我會把現有產品拆開、清點所有零件，再核對是否與製造商的 BOM 一致。

下個月目標

• 盡快將生產轉移至委外製造商。
• 進行五次客戶訪談通話。
• 清空 TinyPilot 辦公室中的所有舊庫存與備用零件。