速度比完美更重要：創業教我的事，後來都變成我帶團隊的原則

本篇是「不是那 1%：CityTasker 創業反思」系列的第 3 / 5 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

想到一個功能，當晚就上線

2012 到 2014 年，我和朋友做了一個叫 CityTasker 的東西——一個任務媒合平台，slogan 是「整個城市都有我的好幫手」。你有件懶得做的事，丟上來，附近有空的人接走。

那時候我是 Co-founder 兼全端工程師，前端、後端、雙平台 App，一個人扛。團隊小到不行，所以我們沒有什麼「規格先評審、設計先過稿」的流程。一個功能想到了，覺得使用者可能會要，當晚就刻，刻完隔天就丟上線，然後盯著後台看有沒有人用。

沒人用，就拿掉。有人用，就接著改。

現在回頭看，那根本不是什麼方法論，那是窮人的本能。

我得老實說：當年選擇「先上線再說」，不是因為我們讀過什麼敏捷開發的書，而是因為我們別無選擇。

帳戶裡的錢每天都在變少。你沒有三個月去把一個功能磨到完美，因為三個月後公司可能就不在了。完美是一種需要時間和金錢餵養的東西，而那兩樣我們都沒有。我們唯一有的，是「先讓它活著、再看市場給不給臉」的急迫感。

所以我們學會了一件事：**先把不完美的東西丟出去，讓真實的使用者告訴你哪裡錯，遠比關起門來自己猜要快得多。**一個你覺得很完美、但沒人要的功能，跟一個醜陋、卻有人天天用的功能比起來，後者的價值高出太多。

那時候我以為這只是創業的求生技巧。我沒想到，它後來會變成我帶團隊的底層信念。

CityTasker 燒完錢收攤後，我回去上班，接著一路在軟體開發、技術管理、DevOps、雲端架構裡打滾，從 17 Media 的 Principal Engineer、Snapask 的後端技術總監，做到現在 QT Medical 的 VP Engineering。

帶的人愈來愈多，我發現一件有趣的事：當年那個被現實逼出來的「速度比完美重要」，現在變成了我刻意選擇的管理原則。差別在於——以前是因為沒得選，現在是因為我知道它真的有用。

具體來說，它長成幾個樣子：

**敏捷，但不是因為時髦。**小步快跑、快速迭代，是因為我親身體會過「猜錯方向但跑得快」可以及時掉頭，「猜對方向卻跑得慢」反而被市場拋下。
**公開透明的溝通。**創業時資訊就在我們幾個人腦袋裡，藏不住也不必藏。帶團隊後我刻意維持這件事：不藏決策的理由、不藏壞消息。資訊一旦變成少數人的特權，速度第一個死。
**鼓勵主動承擔、勇於實驗。**我希望團隊裡的人敢自己做決定、敢試錯，而不是每件事都等我點頭。能自己接住任務、自己往前推的人，才跑得起來。
**把失敗當養分，而不是拿來究責。**這大概是 CityTasker 給我最深的一課。一個沒成功的創業教會我，面對失敗可以更坦然，把它當成長的養分，而非絕對的挫敗。所以團隊裡有人實驗失敗了，我第一個問的不是「誰的錯」，而是「我們從中學到什麼」。

不過十年下來，我也學到這句話不能無限上綱。

「先上線再說」的另一面，是技術債、是品質的妥協、是你某天得回頭還的帳。創業時我可以說「反正公司能不能活到下個月都不知道，債以後再說」——但帶一個要長期經營的產品和團隊時，這句話會害死你。

所以現在的我，拿捏的方式變了。我會問：這次的不完美，是「可以之後再補」的那種，還是「補不回來」的那種？使用者體驗的小瑕疵、之後可以重構的程式碼，先上；但牽涉到資料安全、病人安全、信任這種補不回來的東西，我寧可慢。

速度依然重要，但成熟一點的版本是：**該快的地方快到底，該慢的地方有膽量慢下來。**而分辨這兩者，正是十年來我一直在練的功課。

那場創業沒有成功。錢燒完了，口袋見底，我們先回去上班，隊友轉去了旅遊產業。從世俗的標準看，它是個失敗的故事。

但「速度比完美更重要」這句話，跟著我走了十年，從一個窮學生的求生本能，長成一個技術主管的管理哲學。它幫我帶過好幾個團隊、撐過好幾個產品。

如果有人問我 CityTasker 留下了什麼——不是那些註冊數字，也不是 AppWorks 的光環。是這套被現實狠狠教過、之後我又選擇相信一輩子的做事方式。

這大概就是一場沒成功的創業，最值錢的遺產。