几个月前，我冒出一个绝妙的网站点子。接着，我又想到了一个更绝妙的主意：把网站做出来，但所有活都外包出去。

每个伟大的网站都是从 MVP——最小可行产品——开始的。它用最简单的形态来验证想法是否有人感兴趣。Twitter 推出 MVP 时，你只能发褐皮土豆的照片。Slack 刚上线时据说只支持猪拉丁语。而 Netflix 如今已是在线流媒体的代名词，你可能都忘了它的第一个版本：你先选一部电影，然后等上好几天，直到里德·黑斯廷斯亲自上门给你把剧情演一遍。

我有一个简单的 MVP 搭建计划：

1. 快速写一份设计说明。
2. 找一位顶尖的自由职业开发者，要求在当下最时髦、最前沿的网页框架上有 10 年经验。
3. 给这位开发者开价每小时 4 美元，以最大化网站利润。
4. 坐等 MVP 茁壮成长，变成一个拥有数百万热情用户的热门网站，大家抢着要给我送钱。

你可能会惊讶地发现，这个计划并没有成功。此刻我并不是在硅谷那套价值 2 亿美元的两居室豪宅里写这篇文章，也没有被 Facebook 天价收购而登上头条。相反，我是在自己普通的一居室里敲下这些文字，手里只有个半成品，还莫名其妙地成了自己外包人员的外包。

想法

我坚持生酮饮食，喜欢尝试各种新菜谱。网上有不少好菜谱，但分散在几十个博客里，每个博客的结构都不一样。而且这些博客往往又慢又难用，因为生酮博主们很少懂网页开发。

我的想法是做一个叫 KetoHub 的生酮菜谱目录，把全网的菜谱聚合到一个简单易用的网站里。

寻找自由职业者

KetoHub 最核心的工作是网页抓取——爬取菜谱博客并提取相关数据。这在 Upwork 或 Fiverr 这类自由职业平台上是很常见的任务。我大概能以很低的价格找到人，但如果想在 MVP 之后继续迭代，拿到的代码可能会一碰就散。

等等！这活儿正好适合我的朋友 Ferngully（她同意我写她，但条件是给她起个搞笑的化名）。她刚辞职去旅行，不过几天后就要回来找全职工作，中间这段时间正好可以接点自由职业。我们以前合作过，我知道她是个靠谱的开发者，而且我们配合得很默契。

我联系了她，她立刻就答应了。她了解我过去做代码审查的风格——吹毛求疵、絮絮叨叨严谨细致。她说很期待挑战一下我这苛刻的标准。

我写了一份设计文档，从宏观层面阐述了网站的各个组件。Ferngully 负责后端的抓取任务，而我来搭建一个简单的前端来展示菜谱。

为什么还没上线？

一开始和 Ferngully 聊这个项目时，她问我有没有截止时间。“没有截止时间，只管把代码写好。”

这也是我跟任何和我一起做业余项目的开发者都会说的话。我宁愿周四拿到高质量的代码，也不想要周一赶工拼凑出来的东西。我估计 Ferngully 的那部分需要 30 到 50 小时来实现。大概一周就能做完，就算我的估算不准，或者她每周工作不到 40 小时，两三周也该够了。

那段时间我的本职工作正忙，可能要过好几个月才有时间做前端。毫无疑问，瓶颈肯定在我。

写完设计文档后，我想到一个挺扫兴的场景：如果 Ferngully 把抓取代码交付了，却要在抽屉里躺上好几个月，那多没劲。于是我花了几个晚上搭了一个基础前端，展示了一些我手工抓取的示例菜谱。这样只要 Ferngully 完成她的工作，我们就能马上接入完整的菜谱数据并上线。

就在那时，我开始焦虑了。

我用一周时间完成了网站部分，却还没见到 Ferngully 的任何代码。她在忙什么呢？

在我搭建前端之前，整个项目毫无压力。现在网站已经有了雏形，只是填着假数据，感觉就像养了个活物却把它关在笼子里。每过一天，我的代码都在慢慢过时。我只想赶紧把 KetoHub 推向世界，好进入下一个环节——马克·扎克伯格邀请我登上他那艘收集个人信息的超级游艇，共饮香槟。

低带宽协作

Ferngully 在第二周结束时发来了第一次代码审查。这只是第一个后端组件的部分实现。她平均每周投入了 15 小时，但下周一就要开始全职工作了，投入时间肯定会进一步减少。

我重新翻开设计文档，看看能不能砍掉一些需求。文档要求后端把菜谱数据自动上传到网站的数据存储中。如果让她只把数据写到本地文件系统，然后我用现有的命令行工具上传到网站，就能减轻她的工作量。

好吧，或许时间有限反而是件好事。如果我能从 MVP 里砍掉一些功能还能达到同样的效果，那说明它之前还不够“最小”。

我乐观地认为，再过几周就能收尾了。

成了自己外包的外包

不幸的是，Ferngully 入职后，可用时间比我预想的还要少。在接下来一个月里，她平均每周在 KetoHub 上投入不到五小时。照这个速度，我们得花好几个月才能完成。

如果换成别的自由职业者，我大可感谢对方的付出，然后另请他人。但 Ferngully 不仅是我的朋友，还是一个正承受新工作压力的朋友。我不想因为催进度或大幅改计划而给她添负担。尽管如此，我还是后悔当初她问截止时间时自己表现得那么宽松。

也许我可以把她的一些工作揽过来自己做。不行，要是有人雇我干活，结果又自己动手做了，我也会不爽。我重新审视设计文档，想再简化一些，但已经找不到可删的东西了。于是我开始琢磨，能不能调整开发流程，把她身上的时间成本转移到我这里。

等一下。这是怎么回事？我外包 KetoHub 本是为了节省自己的时间，现在却在重构整个项目，好让 Ferngully 省时间、让我多花时间。我怎么成了自己外包的外包？

简化代码审查

不管谁在为谁打工，我都想尽快把项目做完。能省掉的最大时间开销，就是我那出了名的挑剔的代码审查。

审查对我们俩来说都很耗时间。我在代码审查上花了很多心思，而 Ferngully 实现我的建议也需要时间。加上每轮审查之间要隔上几天甚至几周，光是回想上下文、找回之前的进度，就要浪费不少精力。

为了省时间，我决定不再给 Ferngully 提修改意见。下一次她发来待审的变更时，我直接合并进去，自己稍微改改以符合我的标准，搞定——我们就有了第一个完整的后端组件。还剩两个！

这说不通

Ferngully 对我这个聪明的省时妙招可没那么兴奋。严格的审查能让她在技术上成长。没有这些，KetoHub 对她而言就只是工作，而她在公司里已经有足够多的工作了。

我纠结要不要继续写审查意见。即便跳过了审查，我也不确定请外包到底有没有帮我节省时间。如果重新开始写意见，那肯定是亏本的——我付给外包不低的时薪，结果花的时间比自己写代码还要多。

我们商量后决定，Ferngully 不再继续参与 KetoHub。第一个组件已经完成，正好是个交接的好时机。

自己动手实现

和 Ferngully 结束合作后的那个周六晚上，我从她停下的地方继续往下做，下定决心要一直干到 MVP 上线。到凌晨两点，第一个版本完成了。样子简陋得让我有点难为情，但总算是做完了。

我很快就意识到，一开始就该自己一个人做。

做原型需要对各种权衡做出大量细小的决策。要不要多花一小时去修一个只影响 10% 菜谱的 bug？哪些模块需要写自动化测试？这些问题不可能提前事无巨细地交代给外包。自己一个人做时，我完全可以跟着直觉走。

自己做也让修复设计缺陷变得容易得多。哪怕只有两个人的团队，设计缺陷也会带来很高的摩擦成本。当 Ferngully 发现一个问题时，她得先跟我确认，我再更新设计文档，她读完后扔掉一部分已完成的工作，最后再按新设计重做。而我一个人做时，整个过程几乎是瞬间完成的。

最后，把后端外包出去，让我对业务的核心部分变得陌生。当我亲自去做网页抓取时，反而激发了对 KetoHub 未来迭代中可用菜谱数据的各种想法，也让我对网站的设计约束有了更清晰的认识。

收获

尽管过程磕磕绊绊，这次经历还是让我学到了关于创建新网站和与自由职业者合作的重要一课。最大的收获是：如果你会写代码，就自己去搭建 MVP。

如果你决定与自由职业者合作：

• 商定目标完成时间。
  • 不必设定死板的截止日期，但要在一开始就确认大家对进度的预期是否在同一个区间。
• 约定每周投入时间。
  • 你的自由职业者可能还有其他客户或要事。弄清楚他们每周能为你的项目投入多少时间。

本文由 Samantha Mason 编辑。

如果你是正在尝试生酮饮食、想发掘新菜谱的人，不妨看看 KetoHub，也就是本文一直在说的那个网站。