一句话总结

我的时间都去哪儿了？（2023 版）

亮点

• 我在梳理自己在 TinyPilot 上把时间浪费在了哪些地方。
• 我意识到自己又一次对邮件上瘾了。
• 我搭建了自己的第一个服务器机柜。

目标完成情况

每个月初，我都会定下当月想完成的目标。以下是本月的完成情况：

与新的代工厂启动一批生产

• 结果：第一批生产已经启动。
• 评分：A

我已经和代工厂签署了采购订单，第一批生产正式启动。这将是公司迄今为止最大的一次变革，让人有些忐忑。做成了，皆大欢喜；搞砸了，就是灾难。我当然希望是前者。

发布 TinyPilot Pro 2.6.0

• 结果：已按计划发布 TinyPilot Pro 2.6.0。
• 评分：A

六月的版本发布很顺利，但感觉有点平淡。过去两个版本的研发重心都是让更新更简单、更不容易出错。这些改动大幅提升了软件的可维护性，可写进版本公告里却显得不够亮眼。

实现 9.5 万美元营收

• 结果：实现 9.3 万美元营收。
• 评分：C

TinyPilot 本月营收基本持平。有一篇新的评测上线了，但反响平平，所以销量低于预期。

TinyPilot 数据一览

本月几乎所有指标都变化不大。有一次营销推广效果不佳，但我对正在筹备的其他几个推广仍持乐观态度。

TinyPilot 的广告投放效果明显下滑。5 月份，每投入 1 美元广告费能带来 3.64 美元营收；到了 6 月，每 1 美元广告费只能带来 2.62 美元营收。考虑到每 2.62 美元营收中约有 0.90 美元是物料成本，广告目前仍然盈利，只是利润变薄了。

我打算再观察一个月广告效果。如果表现仍无起色，就约 TinyPilot 的营销顾问聊聊，看看能怎么改进。

我的时间都花在哪儿了？

在最近一次独立创始人聚会上，我提到自己最大的挑战是抽不出时间去做重要但不紧急的事。

其他参会者对此感到意外。为什么不能把一切都自动化或外包出去呢？到底有哪些事非得我亲自处理？

去年我复盘过自己的时间分配，觉得很有帮助，所以今年打算再做一次。

以下就是作为 TinyPilot 创始人，占据我最多时间的几类工作。

任务一：协调各项变动

当 TinyPilot 团队人数超过两人后，我意识到自己的主要职责之一就是协调各种变动。

TinyPilot 在多个维度上并行发展：我们要改进软件、优化硬件、接入新供应商、扩充团队等等。

对业务某一环节的改动，往往会产生连锁反应，影响到其他部分。随着团队规模和业务复杂度的提升，这种连锁反应也越来越频繁、越来越显著。

怎样才能在这上面少花时间？

聚会上有人建议我直接招个经理。这事说起来容易做起来难。

TinyPilot 目前有三个团队，每个团队两到三人：软件开发、支持工程以及客服／本地运营。三个团队的职责基本互不重叠。

如果只招人来管其中一个团队，省不了多少时间；如果要管全部三个团队，就必须有管理软件团队的经验，年薪至少得 12.5 万美元以上。算上其他成本，雇这样一个人一年至少要花 20 万美元，会把 TinyPilot 目前的所有利润都吃掉。

我能想到的最好办法和去年一样：少同时推进几个项目，多寻找可以授权出去的机会。

有些任务我会直接揽下来，是因为注意到其中有无法授权的部分。比如，一项任务包含 A、B、C 三个子任务，其中 B 需要我代表 TinyPilot 签署合同，我就会想：“哦，这只能我来。”可实际上，很多时候 A 和 C 完全可以交给别人，只是我忘了考虑这种可能。

另一个办法是把更多工作外包给供应商，减少需要内部完成的事情。今年，我们不再自行发货，而是把履约工作交给了第三方物流（3PL）服务商。虽然这让一些特殊情况更难处理，但也彻底省掉了以往需要管理的整类工作。

任务二：维护与 3PL 合作方的关系

我原本以为切换到 3PL 服务商的工作主要集中在前期。我知道挑选供应商、完成切换会很费劲，但以为之后就能一帆风顺了。

结果发现，和 3PL 合作还有一长串琐碎的流程需要慢慢理顺：

• 库存从我们办公室运往 3PL 仓库途中，如何追踪？
• 如何核实 3PL 没有在仓库中遗失库存？
• 当 3PL 发错货时，如何解决？
• 如何满足要求当日发货的客户？

这些问题都能解决，但新问题层出不穷，所以我花了很多时间在 3PL 上。

怎样才能在这上面少花时间？

这一块我应该更多地授权给团队其他成员。

我已经开始让 TinyPilot 的本地员工更主动地去对接 3PL，目前效果不错。

以前遇到比如防止 3PL 遗失库存这类问题，我会自己去制定一套核对他们库存报告的流程。现在，我不再事事亲力亲为，而是让本地团队的一位同事来负责。

任务三：参与软件开发

我在 TinyPilot 的软件开发上花了很多时间，因为这是我最享受的部分。尽管现在写代码的时间不多，但骨子里我依然是个开发者。

有了几小时空闲，我常常会去修个小 bug 或整理一下代码。但有时看似很小的改动也会膨胀成好几天的工作量。

怎样才能在这上面少花时间？

这个问题很难，因为最显而易见的答案就是：“Michael 别再写代码了。”

可我就是喜欢写代码……

更现实的做法是，我在接任务时应该更克制，只做以下几类开发工作：

• 改善开发者体验的工作，比如完善文档、改进测试或编写新的便捷脚本
• 那些因为我掌握历史背景和公司内部信息，自己做比给别人布置任务更省事的改动
• 尝试性的改动，成功了就有收益，失败了也可以直接丢弃

任务四：审阅文档

支持工程团队除了日常客服，还负责编写文档和教程。我对面向公众的文档要求比较苛刻，所以会花很多时间审阅团队的文稿，就风格、清晰度和技术表述给出反馈。

审文档花不了太多实际时间，却极耗专注力。我自己写东西要做到表达清晰就已经很费神，更别说去读别人的稿子，还要准确指出哪里缺失或含糊了。

我常常成了文档工作的瓶颈——即便有空出一小时来审一篇新教程，也常常没有足够的精力给出有价值的反馈。

怎样才能在这上面少花时间？

最容易的改进是更多地依靠同事互审。在开发团队，软件工程师们 90% 的代码都是互相 review，不需要我参与。英文写作要保持风格统一比代码更难，但我觉得文档编辑中有 80% 的工作可以通过互审完成。

另一个需要改变的是在安排文档任务时考虑我自己的精力。以前我会一口气给支持工程团队排上三篇教程，结果自己根本没能力一下子全部审完。以后应该把文档任务错开，给自己留出审阅的时间。

摆脱邮件成瘾

过去几年里，我在“和邮件保持健康关系”和“对邮件上瘾、效率低下”之间反复摇摆。

我的好习惯是怎么丢掉的？

一旦养成了健康的邮件习惯，通常很容易保持下去。真正让我破功的，往往是某个事件给了我一个不得不紧盯邮箱的正当理由。

最近，为 TinyPilot 生产金属外壳的供应商延期交货，导致我们外壳断供。缺外壳非常麻烦，意味着无法组装新设备。于是我得手忙脚乱地给本地团队重新安排任务，而且这些新任务还得是那种过几天外壳一到（希望如此）就能立刻放下、回去继续组装的活儿。

在外壳短缺这种情况下，确实有必要频繁查看邮件。如果中国供应商在周五晚上给我发了邮件，而我等到周一早上才回，他们要到周二早上才能看到。这就耽误了三天，意味着本地团队又要多三天无法组装新设备。

问题在于，紧急情况结束后，我还是保留了频繁查邮件的习惯。即便查完发现没有急件，我仍渴望那种多巴胺刺激，于是转去刷社交媒体。这从来都不是高效的表现——本来只想花 30 秒看个邮件，结果变成了 10 到 30 分钟的无意义刷屏。

解法一：只在规定的时间查邮件

以往摆脱不良邮件习惯的办法，就是把一天的安排明确地规划出来。

每天早上，我会把工作日切成 30 分钟一块，安排好每一块时间怎么用。为了避免不由自主地去查邮件，我会专门安排处理邮件的时间，而不是让邮件成为一整天的背景噪音。

我得逼自己重新养成这个习惯。一旦进入节奏，保持下去很容易，难的是重新开始。过去的经验是，熬过头几天，之后就会变得轻松，甚至很有成就感，不再需要靠意志力硬撑。

解法二：鼓励事后反馈

写下这段话时是早上 10 点，到目前为止我都忍住了没查邮件。但我有一种强烈的感觉，觉得自己在耽误大家的工作。

会有这种感觉，是因为同事们经常会就客服工单来征求我的意见——而这正是我一直鼓励的做法。

我逐渐意识到，同事把工单升级给我，会让我的收件箱变得更具时效压力。工单原本只需要等两位支持工程师中任意一人有空，现在却卡在我和那位发起升级的工程师身上。于是我总觉得必须尽快回复，不然就会让客户等上好几天。

有一个我们从未尝试过的方法是“并行升级”。与其让工单停下来等我的反馈，不如鼓励同事在向我征求意见的同时，继续和客户沟通。

解法三：让同事更多地开展同行评审

在讨论文档审阅时我提到了同行评审，其实我应该在各类工作中都寻找更多互审的机会。这样既能让大家在协作中提升技能，也能减少卡在我这里的任务。

业余项目

搭建我的第一个家用服务器机柜

自从搭建了我的第一台 homelab 服务器之后，我的办公室里就堆起了越来越多服务器和网络设备。

未婚妻指出，我的办公室之所以显脏，是因为到处都是线，弄得都没法好好吸尘。我当时还想：“什么？这线也不算多啊，很正常吧。”但仔细一看，好像确实有点多了……

我突然想到，搭个服务器机柜就能两全其美：我能玩个有趣的 homelab 项目，她也能享受线缆收纳整齐的清爽。

于是，我搭起了自己的第一个服务器机柜。过程很有趣，效果也确实整洁了不少。所有设备垂直堆叠，地板上的线少了，整个机柜还带轮子，方便推开打扫。

这是我第一次使用可网管交换机和 VLAN。起初我觉得 VLAN 太繁琐、难以调试，现在掌握了基础之后，反而乐在其中，恨不得什么都用 VLAN 来划分。

我正在写一篇更长的文章，详细介绍我是如何挑选各个组件以及踩了哪些坑，敬请期待。

学习 Nix

过去一年里，Nix 一直在我最想了解的技术清单顶部，所以最近我花了些时间深入学习了一下。

我把初次使用 Nix 的笔记整理了出来，没想到在 Hacker News 和 Twitter 上获得了不少关注。Nix 社区的不少人还主动联系我，愿意帮我解决遇到的问题。

这件事鼓励我以后在尝试不熟悉的技术时，多记录一些笔记。

用 Go 自制认证库

2018 年刚开始做 Web 应用时，我不想自己实现认证，所以一直使用第三方服务。

第三方认证服务用起来还行，但却限制了我的开源项目的推广。其他开发者只有使用和我相同的认证服务，才能部署我的应用。

另一个问题是，第三方认证会让端到端测试变得更慢、更不可靠、也更复杂。

在最近的项目 ScreenJournal 中，我想摆脱对第三方认证服务的依赖，于是调研了现有的认证库。我的需求是：

1. 必须是开源的。
2. 必须使用 Go，这是我目前做 Web 应用的首选语言。
3. 必须是一个可以集成到应用中的库，而不是需要单独部署的服务。
4. 必须支持以 SQLite 作为数据存储。

goth（原名 gomniauth）似乎是最受欢迎的认证库，但它不符合第（3）条要求，因为它依赖外部第三方服务。

另一个流行的 Go 认证方案是 authboss。它满足我的所有要求，但文档相当简略。后来我发现这是作者有意为之，目的是减少支持请求的负担。

我花了一下午尝试用 authboss 实现一个简单的 Web 应用，却连最基本的功能都没跑通。越是了解 authboss，就越觉得它不符合我的预期。它似乎要求接入者不仅用它来做认证，还要用它来处理页面渲染和 URL 路由，这已经超出了我对认证库的期望。

现在，我正尝试自己做一个可复用的认证库。目标不是把它打造成热门的开源项目，只是想避免在各个业余项目之间来回复制粘贴一堆认证代码。

目前，它只能校验用户的密码是否正确。还算不上可复用，因为调用方仍然需要自行生成密码哈希——而我希望这部分工作也由认证库来完成。

开发一个可复用的认证库是个有趣的挑战，它迫使我去使用一些平时很少用到的 Go 特性，也锻炼了我的架构能力，因为我需要在“让库更简单易用”和“对不同认证方式保持更强的灵活性”之间权衡取舍。

收尾

完成了什么？

• 与代工厂合作，启动了首批 TinyPilot Voyager 2a 设备的生产。
• 搭建了第一个家用服务器机柜。
• 学习了 Nix 和 NixOS 的基础知识。

经验教训

• 作为创始人，我在更高效地利用时间方面还有几个机会：
  • 多寻找授权的机会，并把大任务拆小以便于授权。
  • 在承接开发任务时更克制。
  • 更有计划地安排处理邮件的时间。
  • 鼓励团队成员更多地进行同行评审。
• 服务器机柜对 homelab 爱好者及其伴侣来说都很有趣。

下月目标

• 实现 9.8 万美元销售收入。
• 确保 TinyPilot 向代工厂转移的进度按计划推进。
• 花在邮件上的时间控制在 40% 以内。