幾個月前，我想到一個絕妙的網站點子。接著，我又想到一個更「絕妙」的點子：把網站做出來，但全部外包給別人做。

每個偉大的網站都是從 MVP 開始的：也就是最小可行產品（minimum viable product）。它用最簡單的形式呈現你的點子，來測試到底有沒有人感興趣。Twitter 推出 MVP 時，你只能發褐皮馬鈴薯的照片。Slack 當年上線時，更是赫赫有名地只支援豬拉丁文。Netflix 如今已經跟隨選串流劃上等號，你可能都忘了它的第一個版本是怎麼運作的：你得先選一部電影，然後等上好幾天，直到 Reed Hastings 親自到你家把劇情演給你看。

我有個打造 MVP 的簡單計畫：

1. 快速寫一份設計規格文件。
2. 找一位搖滾明星級的接案工程師，精通當下最潮、最前沿的網頁框架，而且要有十年經驗。
3. 用每小時 4 美元的價碼聘請這位工程師，這樣才能讓網站的利潤最大化。
4. 坐等 MVP 開花結果，變成擁有數百萬熱情用戶、搶著要把錢塞給我的熱門網站。

你可能會很驚訝，這個計畫沒有成功。我不是在矽谷那間價值兩億美元的豪華兩房公寓裡寫這篇文章，也沒有因為被 Facebook 天價收購而登上新聞頭條。相反地，我是在自己那間普通的一房公寓裡寫下這些，在收到一個半成品之後，還莫名其妙地變成了我那位接案者的接案者。

點子

我平時採行生酮飲食，也喜歡嘗試各種新食譜。網路上其實有不少很棒的食譜，但都分散在數十個部落格裡，每個部落格的版面結構都不一樣。而且這些部落格通常跑得很慢、很難瀏覽，因為寫生酮食譜的部落客很少有網頁開發的經驗。

我的點子是 KetoHub，一個生酮食譜的索引目錄。它會把分散在網路各處的食譜彙整到同一個好用、易於瀏覽的網站上。

尋找接案者

KetoHub 最吃重的工作是網頁爬蟲——去爬遍各個食譜部落格，把相關資料抓下來。這在 Upwork 或 Fiverr 這類接案平台上是很常見的案子。我大概可以用很低的價格找到人，但如果之後想在 MVP 之後繼續迭代，程式碼很可能會一碰就碎。

等等！這不就是最適合我朋友 Ferngully 的工作嗎（她答應讓我寫她的故事，條件是要給她取個搞笑的化名）？她最近剛辭職去旅行，再過幾天就要回來找正職工作，中間這段空檔應該有時間接案。我們以前合作過，我知道她是個很可靠的工程師，而且我們配合起來很順。

我聯絡了她，她馬上就答應了。從過去的合作經驗，她知道我的程式碼審查是吹毛求疵又愛抱怨嚴謹。她說她很期待挑戰我那些嚴格的標準。

我寫了一份設計文件，大致說明了網站的各個元件。Ferngully 會負責後端的爬蟲工作，而我則會打造一個簡單的網頁前端來呈現食譜。

為什麼還沒上線？

一開始跟 Ferngully 討論這個專案時，她問我有沒有期限。「沒有期限，專心把程式寫好就好。」

這也是我跟任何跟我一起做 side project 的工程師都會說的話。我寧願星期四收到高品質的程式碼，也不想在星期一拿到趕工拼湊出來的東西。我估計 Ferngully 負責的部分大概需要 30 到 50 個小時來實作。我們大概一週就能完成，就算我估得不準，或是她每週工時不到 40 小時，最多也就兩、三週吧。

那段時間，我的正職工作正處於忙碌期。可能要過好幾個月才有時間做前端。很顯然，我才是瓶頸所在。

寫完設計文件後，我想到如果 Ferngully 交出爬蟲程式碼，結果卻要在抽屜裡躺好幾個月，那也太虎頭蛇尾了。於是我花了幾個晚上拼湊出一個基本的前端，放上一些我手動抓下來的範例食譜。這樣只要 Ferngully 完成她的工作，我們就能馬上把完整的食譜資料放上去、正式上線。

就在那時，我開始焦慮起來。

我花了一週把網站的部分完成，卻還沒看到 Ferngully 的任何程式碼。她到底在忙什麼？

在我打造前端之前，這個專案一點壓力也沒有。現在有了這個塞滿假資料、隨時可上線的網站，感覺就像我們把一個活生生的東西關在籠子裡。隨著日子一天天過去，我的程式碼正逐漸枯萎、過時。我只想趕快把 KetoHub 推向全世界，好快轉到流程的下一個階段——Mark Zuckerberg 在他那艘專門蒐集個資的超級遊艇上請我喝香檳。

在低工時的限制下工作

Ferngully 在第二週結束時寄給我第一次的程式碼審查，那是第一個後端元件的部分實作。她平均每週做了 15 個小時，但下週一就要開始正職工作了，工時肯定會再往下掉。

我重新檢視了設計文件，看看能不能刪掉一些東西。原本的設計要求後端要以程式化的方式把食譜資料上傳到網站的資料庫。如果改成讓她只把資料寫到本機的檔案系統就好，就能減輕她的工作量，之後我再用現有的命令列工具把資料上傳到網站。

好吧，也許時間有限反而是件好事。如果我能刪掉一些元素還能達到同樣的效果，那就代表它本來就還不夠精簡，還不是真正最精簡的樣貌。

我很樂觀地覺得，我們再過幾週就能收尾了。

變成接案者的接案者

不幸的是，正職工作讓 Ferngully 能投入的時間比我預期的還要少。在接下來的一個月裡，她平均每週在 KetoHub 上花的時間不到五小時。照這個速度，我們得花上好幾個月才做得完。

如果換作是其他接案者，我大概就會謝謝對方的付出，然後另請高明。但 Ferngully 不只是我的朋友，還是個正為新工作焦頭爛額的朋友。我不想逼她投入更多時間，或是大動作修改專案計畫來增加她的負擔。儘管如此，我還是懊悔不已，怪自己當初她問期限時怎麼會那麼寬鬆。

也許我可以把她的一些工作轉回自己身上？不行，如果有人請我做事，結果又自己跳下來做，我也會很不爽。我又回去看了一次設計文件，想看看還能不能再簡化，但已經找不到可以刪的東西了。接著，我開始思考能不能調整開發流程，把一些時間成本從她身上轉移到我身上。

等等，這到底是怎麼回事？我把 KetoHub 外包明明是為了省自己的時間，現在卻在為了節省 Ferngully 的時間而重整整個專案。我怎麼會變成我接案者的接案者？

簡化程式碼審查

不管到底是誰在幫誰接案，我都希望我們能盡快把專案完成。而我能省下最多時間的地方，就是我那出了名挑剔的程式碼審查。

審查對我們兩個人來說都很花時間。我在程式碼審查上投注了很多心力，而 Ferngully 實作我的建議也需要時間。加上每一輪審查之間往往隔了好幾天甚至好幾週，光是回想審查到哪、前後脈絡是什麼，就已經耗掉不少心力。

為了省時間，我決定不再給 Ferngully 審查意見。當她寄來下一份待審的 changelist 時，我就直接合併進來，自己稍微調整到符合我的標準，碰——我們就有了第一個完整的後端元件。只剩下兩個了！

這樣下去沒道理

Ferngully 對我這個聰明的省時新招可沒那麼興奮。嚴格的審查能讓她在技術上成長。沒有了那些，KetoHub 對她而言就只是工作而已，而她在正職工作上已經有夠多工作了。

我掙扎著要不要繼續寫審查意見。就算我跳過不寫，我也不確定找接案者到底有沒有真的幫我省到時間。如果恢復審查，我在時間上肯定是倒賠的。我付給接案者的時薪並不低，結果花的時間反而比我自己寫程式還要多。

我們好好談過之後，決定讓 Ferngully 不再繼續做 KetoHub。第一個元件已經完成，正好是個讓她退出的好時機。

自己動手實作

在跟 Ferngully 結束合作後的那個星期六晚上，我接著她停下的地方繼續做，並下定決心要一路做到 MVP 上線為止。到了凌晨兩點，第一個版本完成了。雖然外觀陽春到讓我有點不好意思，但總算是做完了。

我很快就意識到，這個專案從一開始就該由我一個人來做。

原型需要做大量關於取捨的細微決策。要不要多花一小時去修一個只影響 10% 食譜的 bug？哪些模組該寫自動化測試？這些問題根本不可能事先一一交代給接案者。自己一個人做，我只要跟著直覺走就行了。

自己動手做，也讓我更容易修正設計上的弱點。就算只有兩個人的團隊，設計缺陷也會帶來很高的摩擦成本。當 Ferngully 發現問題時，她得先跟我確認，我再去更新設計文件，她讀完後得丟掉一些已完成的工作，最後再依新設計重新實作。自己一個人做時，整個過程幾乎是瞬間就能完成。

最後，把後端外包出去，其實是讓我自己看不清事業的核心部分。當我親手下去做網頁爬蟲時，反而激發出許多關於未來 KetoHub 可以怎麼運用食譜資料的點子，也讓我更了解網站在設計上的限制。

心得與收穫

儘管過程中有這些問題，這段經驗還是讓我學到關於打造新網站、以及與接案者合作的重要課題。最大的心得就是：如果你是工程師，請自己打造你的 MVP。

如果你還是決定要與接案者合作：

• 討論預計的完成時間。
  • 不一定要訂下死板的期限，但要在一開始就確認彼此對時程的想像是否在同一個範圍內。
• 約定每週可投入的工時。
  • 你的接案者可能還有其他客戶或要事，事先了解他每週能為你的專案投入多少時間。

本文由 Samantha Mason 編輯。

如果你是想發掘新食譜的生酮飲食者，歡迎看看 KetoHub，也就是我在整篇文章中談到的那個網站。