一句话总结

是该继续扩张，还是先把现有的做好？

亮点

• TinyPilot 迎来了史上销售最好的一月，总营收达 6.9 万美元。
• 网站改版项目已延期五个月，超支 3.2 万美元。
• 我发布了 PicoShare，这是我迄今为止增长最快的项目。

目标完成度

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

发布 TinyPilot Pro 2.4.0

• 结果：按时发布了 TinyPilot 2.4.0
• 评分：A

新版本增加了多用户支持，这是客户期待已久的功能。我们还修复了一个频繁引发用户求助的恼人 bug。

完成 TinyPilot 官网的设计改版

• 结果：设计已完成，但尚未上线
• 评分：C

这个项目的耗时仍超出预期。设计稿本身已经完成，但设计公司一直抽不出人力来在 TinyPilot 官网上落实代码改动。

完成新任技术支持工程师的入职培训

• 结果：Diego 已上手，能够独立处理大部分技术支持请求
• 评分：A

找到合适的人选花了很长时间，但现在看来效果很好，已经为我节省了大量时间。

TinyPilot 数据一览

3 月是 TinyPilot 迄今在销售和总营收上表现最好的一个月。销量相比 2 月仅增长了 14%，但其中一半是新款 Voyager 2 PoE。该型号比标准版贵 60 美元，这带来了 33% 的营收增长。

本月利润为负，但这更多是费用入账时间的问题。2022 年第一季度的利润为健康的 1.6 万美元，月均 5300 美元（2022-04-29 更正：数据有误——2022 年第一季度实际亏损了 1 万美元）。

每独立访客营收达到 10.49 美元，创下历史新高。作为对比，去年同期该数值约为 4 美元。这是个好消息，因为我原本的计划就是先提升网站的转化率（“漏斗底部”），再去做推广。该指标的增长表明计划正在奏效。我认为产品、定价和网站的改进让用户更愿意下单。

我又有空闲时间了！

2 月时，我曾思考如何用每周 20 小时来运营 TinyPilot。虽然还没完全实现，但已经取得了进展。

占用我时间最多的就是技术支持，每周要花 8 小时。这也是最难交出去的工作，因为招聘过程就花了上百小时。即便找到了合适的人，培训也非常耗时——两年的经验和隐性知识全在我一个人的脑子里。

好消息是，我们已经渡过了最艰难的阶段。TinyPilot 的首位技术支持工程师 Diego 现在已经在支持论坛上回答所有问题，因此我每周花在支持上的时间已降至 8 小时以下。他还发布了自己的第一篇教程：一份在 TinyPilot 上配置 Tailscale 的指南。

我也在有意让 TinyPilot 本地的团队承担更多责任。例如，本周我们发现用于组装 Voyager 2 的那款螺丝在全网都已断货。

换作以往，我会直接联系外壳设计师寻找替代品，并尝试用新螺丝进行组装。但这次我在发邮件前停了下来——这正是让本地团队挑大梁的好机会，于是我让他们来主导这件事。

整个 3 月，我在时间管理上感受到了明显变化。过去半年里，我几乎每天结束时都觉得还有事没做完，不得不把重要但不紧急的任务往后推。而在 3 月，我常常到下午中段就完成了紧急工作，有了空余时间去投入到推广、自动化和任务分派上。

我也在克制自己，不把这些新腾出来的时间立刻花在做加法上，比如再招一个人或为 TinyPilot 增加新功能。我得不断提醒自己，这些事总是比一开始看起来要复杂得多。

2021 年我一直在手忙脚乱地应付过多的增长型项目，现在是时候把已有的东西优化好了：

• 自动化发布流程
• 自动化端到端测试
• 更主动地与客户沟通，而不是等他们来找客服才交流
• 在客服团队与技术支持工程师之间建立问题升级路径
• 优化与代工厂的协作流程

继续再投入，还是开始变现？

自 TinyPilot 成立以来，我一直不太在意短期利润，而是专注于长期增长。我会避免亏损，但也很乐意以接近盈亏平衡的状态运营，把所有营收都再投入到产品改进中。

我把再投入看作是在积累势能。假如月销售额是 3000 美元，我花 5000 美元改进产品后达到 4000 美元/月，那 5000 美元是一次性成本，而 TinyPilot 的销售增速却会永久性地提升。

但我并不是一家有风投支持的创业公司。我的目标不是无限增长、靠 IPO 暴富。总有一天，我得停止把所有钱都投入增长，开始真正获得收入。现在就是那个时候吗？

我目前主要的短期开支是为提升可制造性而优化 Voyager 2 的电路设计（每月 1-2 万美元），以及销售网站的改版（每月 5000-6000 美元）。再过几个月，Voyager 2 的电路板就会定版，网站也不会再反复折腾，成本会大幅下降。只要销量保持稳定，光是不再开新项目，我每月就能赚 2 万美元。

我最初的计划是一旦 Voyager 2 的生产稳定下来，就立刻与电气工程合作伙伴着手开发 Voyager 3。开发 Voyager 3 在未来六个月里每月大约要花 1.5-2.5 万美元，会吞掉我今年剩余的所有利润。不仅如此，它还会占据我大量时间，因为发布一款新产品会改变 TinyPilot 内部的许多工作流程。

眼下，我觉得是时候开始获取收益了。新项目可以等到今年晚些时候再启动，在此之前，我想先把销售额做到 7-9 万美元的区间，这样我就能在不耗尽利润的前提下继续投入产品改进。

关于与设计公司合作，我希望当初就知道的事

早在 9 月，我就聘请了一家设计公司来改进 TinyPilot 的官网。当时我以为这个项目六周、花费 7000 美元就能完成。六个月过去了，我已经花了 39577 美元，项目却还没结束。

怎么会变成这样？我可以指出设计公司那边的问题，但核心原因是我根本不知道如何与设计公司有效合作。我以前只请过自由职业者，没意识到与公司合作会带来如此大的变化。

我把这些希望当初就知道的事记录下来，既是给自己的提醒，也希望能帮到还没开始与设计公司合作的人。

与设计公司合作，需要更多管理，而不是更少

我在聘请这家公司时犯的根本性错误，是低估了管理他们所需的时间。

这家公司每月为我工作 40-60 小时，这和 TinyPilot 其他自由职业者的工作时长差不多，所以我以为管理一家公司和管一个自由职业者差不多。事实上，我本该为此预留多得多的管理时间。

与设计公司合作时，你需要对接多个人，每个人都在负责各自的子项目。人越多，所需的管理时间就必然越多。

举个例子，假设管理一个每周工作 40 小时的员工需要每周 6-8 小时的管理时间。如果你把这个岗位拆成两个人，每人每周 20 小时，你的管理时间可能会膨胀到每周 10-12 小时。员工的总工时没变，但与两个人沟通会带来效率损耗。

同样的逻辑也适用于设计公司。即使你每月只购买 40 小时的工作量，作为客户，管理公司里的六个人也比管理一个做同样工作的自由职业者要费劲得多。

严格控制项目范围

这个项目最大的问题出在范围界定上。考虑到一个六周的项目我做了六个月，你大概也能猜到。

起初，我和设计公司约定这只是一个品牌重塑项目——为网站设计新的 logo、配色和字体，然后再评估下一步。但随后就出现了范围蔓延。设计师们不断不动声色地扩大范围，等我反应过来时，已经在对网站进行全面改版了。

我总觉得再让他们做一阵子，这个月就能收尾，结果却一拖再拖。回头看，我本该及时止损，把项目范围缩回到最初约定的品牌重塑上。但当时我正忙于 Voyager 2 的发布，让设计公司继续做下去似乎是最省事的选择。

即便自以为吸取了教训，这个月范围蔓延的问题还是再次找上了我。我按优先级列出了改版待办任务的看板，预定了 60 小时的 3 月工时，但不确定设计任务能否用满这些时间，于是又在清单末尾加了一些低优先级的 bug，以防工时有剩余。

你大概已经猜到接下来发生了什么……

设计公司把所有设计任务都晾在半成品状态，却用掉了我当月四分之一的工时去修那些低优先级的 bug。

往后我需要把要求说得更清楚，让他们明白在所有关键任务完成之前，不要去碰非关键任务。

警惕未闭环

如果你给一个自由职业者布置了任务 A、B、C，他在任务 A 完成 80% 时突然停下来转去做任务 B，会让人觉得奇怪。如果他在任务 B 做到一半时又去做任务 C，那就更离谱了。

而与设计公司合作，很容易陷入多个任务都只完成 80% 的境地。也许公司里的 Alice 这个月只有 10 小时空档，所以她把任务 A 做到了 80%；接着 Bob 接手，但他不想中途接手 Alice 的项目，于是另起炉灶做任务 B，只完成了 30%。等你回过神来，已经花了 39577 美元，却没有任何一项成果能真正用上，因为所有任务都只完成了 80-90%。

在《搞定》（Getting Things Done）一书中，David Allen 把未完成的任务称为“未闭环”。未闭环越多，你的注意力就越分散，因为每一个都会在你的脑海中占据一块空间。自由职业者通常一次只会和你有几个未闭环，而设计公司可能会有 5 到 10 倍之多，而且持续时间更长。

未闭环对你的投入产出比也很不划算。假设你需要在六个月内完成六项任务，如果请的是个人，他大概每月交付一项。你在月底付款时，几乎能同步享受到工作成果。而如果是设计公司，他们可能会把六项任务分给六个人，每个人只用六分之一的时间做你的项目。到了第五个月，你已经付了 80% 的钱，却得不到任何实际收益，因为没有一项任务是真正完成的。

先按小时付费，再转为包月

我合作的这家公司提供按小时计费和包月两种模式。按小时计费是预先购买 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 又做了一期。一位专注于自托管的博主还写了一篇在群晖 NAS 上安装 PicoShare 的教程（这对我来说很有趣，因为我的第一篇博客就是关于在群晖 NAS 上通过 Docker 部署的）。

PicoShare 现在是我创建过的增长最快的项目。首次提交是在 2 月 13 日，目前在 GitHub 上已有 664 个 star。作为对比，TinyPilot 经过近两年才获得 1.8k 个 star，LogPaste 则在一年后获得了 201 个 star。

开源开发者们也贡献了很棒的代码：

• @viktorpenelski 添加了永久保留分享文件的选项。
• @dertuerke 为文件大小添加了人类可读的格式（例如用“1.53 MB”代替“1530000 bytes”）。
• @dertuerke 添加了“复制到剪贴板”按钮。

我还为其添加了多架构 Docker 镜像支持，现在你可以在树莓派这类基于 ARM 的系统上运行 PicoShare 的 Docker 镜像了。创建多架构构建的过程出乎意料地简单，只是由于流程不断变化，很难找到相关说明。

我还搭建了一个在线演示服务器。起初我对此有所顾虑，不想处理他人上传非法内容或耗尽带宽的问题。后来我想到可以给演示服务器加一个限制：用户只能访问从自己 IP 上传的文件。这样既能让大家体验服务，又能限制被滥用的程度。

总结

完成了什么？

• 发布了 TinyPilot Pro 2.4.0
• 发布了 PicoShare 1.0.0
• 完成了 TinyPilot 首位技术支持工程师的培训

经验教训

• 与设计公司合作和与自由职业者合作，需要不同的管理方式。
• 为自托管工具提供 Docker 镜像会让它更具吸引力。
  • 我猜 PicoShare 能如此迅速吸引用户，就是因为只需一条 Docker 命令就能跑起来。

下月目标

• 发布一篇关于使用 TinyPilot 搭建家庭实验室 NAS 服务器的博客文章和视频。
• 完成 TinyPilot 官网的改版。
• 发布一个支持通过 WebRTC 传输 H264 视频（可选的实验性功能）的 TinyPilot Pro 版本。