在介紹工具進行高速迭代之前，這一章我要先談談，如何在時限之內，準時上線項目的技巧。
一個項目高達 600 個細節，其實也不是一件輕鬆的事情上。我們不僅準時完成，細節還經過打磨。其實背後是有祕訣的。
我們內部做項目，其實也有一套與一般團隊不同方式的開發順序。這套方法，我們稱之爲「逆向法」。
2012 年，我曾經與朋友雙人組隊，在 Facebook 舉辦的 Hackathon 獲勝拿下大獎。
大概在六年前，我還沒開始創業前，當時我個人搭建項目的速度已經很牛逼。
其實連這次參賽，也是有備而來，只是我沒想過會拿第一名而已。
很多人以爲 Hackathon 獲勝需要完全憑藉運氣與技術功底，但是，其實 Hackathon 其實也是可以「準備的」。
我當時參賽的作品是一個書籤收集服務（其實挺無趣的）。當初打算解決的痛點是：
- 當時每個人在 Facebook 每天都會 Like 很多頁面
- 但是一 Like 過，隔幾天就不知道去哪裏了。
- 無法儲存收藏覺得有價值的連結
我想開發一個網站，讓一般使用者透過這個服務，可以自動收集整理自己曾經在 Facebook Like 過的書籤，並且搜索整理。
聽起來真的挺沒勁的。這個功能 Facebook 怎麼可能沒有。但是在 2012 我參加這個比賽的時候，Facebook 還真的沒有這個功能。
這個功能，Facebook 一直到 2014 年才上線。
當時朋友也覺得我這個點子，當時聽起來就是去送死。做這個產品有意義嗎？
但是，挑選這個點子，作爲參賽項目，真的是有目的性的。
在比賽前，我總結以前打過幾場 Hackathon 的經驗，檢討出前幾次我之所以落敗的幾個主要原因：
- 太貪心 - 想在比賽裏面做盡可能多的 Feature，結果作不完
- 沒有人懂價值 - 功能作不完，簡報沒時間做，上臺亂講導致上臺時沒有人懂這個產品的價值
- 不能用 - 寫不完結果沒有時間測試，裁判一按下去，產品就是爛的不能用
- 自HIGH - 自己做了一個覺得很炫，工藝很高的產品，但是完全不合主辦單位舉辦這個比賽的期望
以前在我單純的想法裏面，我認爲打 Hackathon 要贏：只需要代碼牛逼，IDEA 牛逼，這樣就能確保最後勝利。
但是往往事與願違。
一般來說，在黑客鬆結束過後，大家批評得最兇的往往是「贏下大獎的怎麼都是那些 "PPT 組"」。
從這件事，我卻發現了一個隱藏的真理。雖然很不公平，但是在實際狀況中，一般評審根本沒空可以查覈代碼質量，評審只關心最終成品解決了什麼問題，試用的時候是否真如同參賽者宣稱的一致而已。至於作弊與否，那都是賽後的事了。
所以這就是爲什麼 PPT 組容易贏的原因。評審多半隻評審最後結果。沒有興趣去評覈後面的工藝。
但是即便我知道這個「密技」，身爲有一個有自尊的程序員，在 Hackathon 中「作弊」 -- 改用 PPT 去競技，是絕對不可能的念頭。
無論如何，我覺得過去的打法，的確是有不少改進空間。我歸納出了幾條很簡單的戰略：
- 功能要單純，最好只有一個主要功能，這樣才做得完。
- 要做對主辦單位有意義的項目
- 扣除開發時間外，要留足夠多的時間寫投影片與 DEBUG
下次這麼做也許有可能贏。所以才挑了這麼樣的題目 --- 無聊但對主辦方有價值的題目。卻沒想到一舉贏下了最大獎項。
我認爲打 Hackathon 其實跟創業這件事其實是非常相似的。
- 需要牛逼幻燈片
- 正確的產品，適合主辦方開新聞發佈會
- 在最短時間，開發最小可行性產品
- 需要牛逼幻燈片
- 被市場認可並獲利
- 在正確的時間點啓動上線
所以。其實我們可以把打贏一場 Hackathon，比喻爲挑戰在 10 小時之內創業。
當時我們是怎麼贏得 Hackathon 大獎的呢？
主要有幾點關鍵因素：
- 我們上臺的時候，做了很牛逼的投影片。甚至在上臺之前，我在臺下演練了很多遍。
- 最後做出了一個對主辦單位很有意義的項目
- 比賽時間只有 9 小時，我們在時限之內做出了一個完整的產品
在這當中，我們用了以下這樣的策略：
當時比賽是是早上9點開始的，下午6點必須上臺 pitch。所以總長總共有九個小時。
因爲時間只有這麼短，但卻要有完美的效果。
我計算出來，我必須至少留兩個小時寫投影片並且彩排。
所以開發時間剩下：九個小時扣掉兩個小時就是七個小時。那七個小時裏面又扣掉吃飯的時間，還有上廁所的時間，大概一個半小時到兩個小時。所以留給真正開發的時間只有五個小時。
那麼五個小時之內，可以開發多少功能呢？
給大家五秒鐘的時間想看看，五個小時我能寫多少功能？1、2、3、4、5，答案是一個功能。
爲什麼到最後決定只寫一個功能？
各位應該有這樣的經驗，每當你時間不夠的時候，還特別容易出錯。平常比如說開發一個功能，估計實際測試時，可能會出現五個Bug。所以時間要留開發一個功能與 de 5 個 bug 的時間。
但是時間特別緊急的時候，可能就不是這樣了，甚至很可能會發現一口氣出現了 15 個 bug。修了這個還出現別的沒想到的 bug。
特別緊張的時刻特別容易出現。
爲了怕莫非定律干擾。我算了一下，如果開發時間只有五個小時，原本依照我的功力應該可以寫五個功能。
但是因爲一定會出現莫非定律，所以最保險的策略應該是隻做一個主要的功能。
所以這是我們第一個策略。我們作品的核心功能非常簡單，就是一個網站收藏工具，去抓取並分析Facebook上面的動態，儲存回數據庫，讓使用者之後可以查找。也沒有什麼特別高大上的功能。
早上9點一到會場，我就只花了簡短的時間跟我的隊友進行簡短的溝通關於早上的戰略。
雖然他覺得這點子好像太單薄了。但是因爲他比較資淺，所以還是以我的意見爲主。
我在以前打 Hackathon 學到的另一個寶貴經驗：在比賽時千萬不要找太多隊友，隊友太多意見也會太多。最後光討論與辯論，時間就用光了。
我記得之前有一次打比賽時，遇到有一個大神組。別人一組頂多 3-4 個人。那組有 11 個。隊友每一個都是各領域裏面赫赫有名的資深開發者或大神。但是他們那一組，到最後都花在吵架，產品最後真的不怎麼樣。。。。。
所以這次打比賽，我決定只找一個隊友。
因爲組成簡單，我們只花了很簡短的時間，就決定主要進攻方向是什麼。
先花了半小時，決定要做哪一些工作。再花一個小時，把雛形框架部署到機器上。
部署網站到機器上。通常是產品做好之後的最後一步。但是，我以前的經驗是等到把作品做好之後，放到這個遠端的機器裏面時。因爲本地的環境跟遠端的環境還是很不一樣。所以得要花很多時間調試，而且在最後面時，時間肯定也不夠。
那時候一定會出非常的多的包，會導致投影片也沒辦法寫完。
所以我們先解決這當中可能預見的最大風險。
接下來我們的第二步，再花了一個小時，把主要功能趕快做好，做了一個能夠動的第一版 app。
9 點比賽開始，在中午12點左右，我們就有一個可以動可以展示的第一版了。主幹功能全部做完。
在12點前開發完第一版有一個很大的戰略意義。
很多人不明白爲什麼要在12點之前要做完？明明下午6點纔是截止時間。
在中午12點做完有個好處，就是當中午吃飯時間，其他人還在討論項目細節的時候。我就在拿着我的筆電炫耀我已經做完的進度。雖然只是第一版App，但是其他人不知道中間其實省略很多細節。只會覺得「我操，Xdite實在太牛逼了。我們可能已經贏不了。」
我要的就是這種效果。所以才拼死在 12點的時候把主要的功能趕快寫完 XD。
我第三階段開始做的是把主幹功能上面可以微調的小部分的功能，慢慢的補完。接着拿這個作品到Facebook上面請我朋友真實測試網站上面有沒有什麼使用上的問題。
爲什麼要做這件事情？
之前我在參加其他 Hackathon 比賽的時候，最大的扼碗是，根本沒有時間好好測試，就是自己覺得簡單 debug 完就覺得 ok 了。結果評審一測的時候就爛掉了。
這件事情實在是太囧了，絕對不能再發生。
所以這次比賽的策略是一做完就丟給外面的真實的用戶去測，儘可能的在上線前，把有可能出包的問題先都找出來修復。
果然這些測試用戶，馬上就幫測到很多我不可能發現的小細節。
當時印象中，他們測到有一個非常有用的體驗細節：
因爲這個項目是分析每個人在Facebook上面的動態，找過自己 like 過的網站。所以需要一定的匯入時間與分析時間。在三個人同時在線的時候，這個網站的匯入速度還是正常的。但是在丟給50個人去測試時，機器就沒辦法消化這麼大的量了。
就一個使用的體驗來說：按下匯入按鈕，但是卻沒有馬上看到結果或者是進度。正常人會以爲是功能爛了。
我才發現，我的排程演算法規劃錯誤了。實際上是有匯入的，只是他們可能沒辦法馬上看到。我設計的過場等待畫面，也沒辦法有效的拖住使用者。
發現這件事情後，我立刻進行細節修正。要是沒有做這輪測試的話，估計上線評審一按，馬上就會「爛掉」。
所以我真的很慶幸，當時做了一輪完整的使用者測試。大概是在下午三四點的時候，我就把所有的bug全部都修掉了。
在測試這些網站功能的時候，突然間有一個朋友就問： xdite 你們這個產品到底是在做什麼的？
我說這產品不是很明顯嗎？當你每次在網路上贊過很多Facebook連接，過幾天要回去找時，就忘了在哪裏。FB 沒有整理收藏功能，所以我們就做一個外部收藏整理服務。我們是做這個題目，你看不出來嗎？
他說鬼才有辦法一眼就看出來。你們的首頁呢？
他說一般的產品首頁都會明自己提供什麼服務，建議我們得做一個。
所以我就趕緊做了一個 Landing Page（當時我都還不知道這叫 Landing Page），只知道必須做一個一眼就能說明自己用途的首頁。
到了這個階段，最後還剩下一些時間。我邊寫投影片邊調整。在寫投影片的過程中，需要調整一些截圖與過場，我就順便同時調整了網站上一些細節。
在上臺之前，我已經臺下排練了至少五遍以上PPT。
正常來說，程序員在上臺 Pitch 自己作品前，都會相當緊張，一緊張就結結巴巴講不好，更何況還要Demo，Demo錯了之後就更加完蛋。
因爲反覆排練了很多遍，在五六點上臺Demo時，我的表現簡直就是完美（當時是自我感覺）。
所以最後結果是這樣的：
- 我們的投影片非常牛逼
- 我本人demo的時候非常的牛逼
- 我們做了一個有意義的產品。要知道這個黑客鬆是Facebook辦的，我們做了其實Facebook想要做的一個功能，但又不知道要不要花RD資源去做做，也不知道有沒有市場，所以我們第三個做了一個有意義的產品
- 我們的產品是沒有bug的，在 demo 前給很多人測過了，所以沒有bug
- 100%production ready，也就是說明天上線，要跟用戶收錢或是直接使用，是完全沒有什麼問題的，完成度極高。
所以這就是爲什麼我們當場贏得臺北站。後續也拿到世界第一名（Facebook 分 3 大洲 23 個城市比賽）。因爲我們的產品完整度與意義實在是太高了。
這裏我要跟各位分享其他人是如何搞砸他們的黑客鬆。
不能說是搞砸，沒有人願意搞砸自己的項目。
但是一般人去打黑客鬆的時候，會是怎麼樣的策略？
首先一般團隊會這樣做：
到會場第一個先找小夥伴，看會場有哪些牛逼的小夥伴，然後就詢問你要不來我們這一組？
即使他們組成了一個非常牛逼的團隊，下一步要做一個牛逼的產品。假設這組有五個人，每個人提了5個feature，光功能討論會議，就可以花老長時間。可能最後得花了一個多小時，才能決定最後要做的十個功能。
但是十個功能，可能真是做不完的，所以最後砍到 6 個功能。所以他們就分頭去做六個功能。接下來 5 個小時，他們埋頭的開始瘋狂地做實做這些功能。
但是快到截止時間要上臺發表了。才驚覺 Fuck，怎麼做不完。就只好草草砍到兩個確定完整的功能，急急忙忙的收尾。
然後趕快指定一個其中比較閒的人做投影片，另外一個人彩排練習。
但是因爲真的沒時間測試產品，所以這一隊就上去第一個就先道歉：「抱歉我們這個產品沒有做完，請大家不要見怪。」
另外一件比較常出現的狀況，是demo之後，然後評審以及其他隊伍聽的這項目覺得可能有點意思，想去試用。結果一開，爛掉了。它自然就被打零分或者是很低分。
幾乎99%以上的人打黑客鬆都是這樣輸掉，包括我以前也是一樣這樣輸掉的。
這當中我這次的表現跟他們的差別在哪裏？
一開場我就已經定調節奏，堅持在中午12點前把一切的東西都做完，並且預留一段完整的時間專注彩排。
我的策略是先保留兩個小時彩排時間，兩個小時的時間修bug時間。而且在實做做功能上也極度節制。
但是其他人的策略是「沒有計畫」，直接埋頭苦幹去做。
所以縱然大家都有 9 個小時時間，但是最後的結果有極大的差異：
- 我把功能完整的上線
- 其他隊伍只做出了一個什麼都不是的東西
其實，打 Hackathon 這樣的策略，不是那一次纔想到。早在參加 Hackathon 前，我平常做項目也是類似的結構安排。反而是在打 Hackathon 時，因爲沒有計畫，老是莫名其妙輸掉（其實也不冤）。
所以最後我痛下決心，檢討 Hackathon 戰略。把平時我在做大型項目的戰略技巧搬過來，才大獲勝利的。
這樣的技巧，可以用在大的中的小的項目。
假設今天我們要做的這個項目，工期時間有三個月。
那麼要如何管理這個項目的時間？
我的作法是，不管這個項目是要開發什麼軟件。一定會先保留最後一個月的時間，最後一個月的時間不能被動。
也就是說老闆給我三個月時間做這個項目，我會告訴自己，只有兩個月時間能做開發。
最後一段空白，誰都不能動，這段時間是保留給測試的。
接下來我會把剩下來那兩個月的時間，再切成把它切三段。
基本上是一些地面作業：
- 項目部署
- 前面章節講過的「重構法」裏面的主幹路線
讓所有人可以一開始很快的出發，不置於在中間或最後被絆倒。
第二第三階段實做主幹打磨細節：
把整個項目的 must have 主幹拉出來。先把整個架構打起來。再利用「重構法」補充細節。這樣做的好處是在第二階段，很快就能知道哪些路是「跑不通的」「沒有時間作的」「太過複雜」的。這些主幹就可以先「被消失」。
而因爲主幹功能都已經出來。每個功能的精緻程度取決於「重構次數」。所以無論哪個版本。都可以被稱之爲完整版。
到了最後一個階段。因爲有「足夠充裕」的時間。就可以有時間測試，打磨細節。
我在 Hackathon 裏面也是這樣子做的。先是把下午兩個小時的時間完整的保留起來，以中午12點爲中間界限。集中火力在早上把大的功能跟最危險的部署部分完工。下午專注在補足功能細節以及修正用戶測試後的反饋。
接著很順利的完成demo pitch，完成上線。
很多人在參與大工程時，很容易一下子就失去了方向準則，以爲只要猛力做，最後就會達到所謂的成功。
但是我做項目的做事方法並不是這樣子的。
我在啓動任何項目前，我都先找出「成功的定義是什麼」？
比如說創業第一個「成功」目標是什麼？
答案，可能是「順利完成第一版，成交第一筆訂單，收到第一筆入帳」，叫做所謂的成功。如果花了時間，做了一個產品卻沒有收到錢，這件事情叫做失敗。
那麼打 Hackathon 中，成功的定義是什麼？
我發現的「成功」的定義並不是代碼寫的多牛逼，而是得讓評審認知到這個產品的價值，也就是唯有準備好的投影片，跟好的pitch，吸引評審的目光，你的產品的代碼價值纔有機會被看見。
所以我反其道而行，「奢侈」的我花了兩個小時準備投影片與 Demo。
明明我在寫代碼上造詣非常牛逼，卻選擇把最重要的精力放在這裏。這是因爲在這個場景中，專注準備投影片才能達到「成功」
先找出「成功」的定義，再依據這個準則，去安排當中的進度。
- 什麼是主線？
- 什麼是副線？
- 什麼是風險？
在這個過程中就可以把細節一一梳理出來。
我的作法是：一開始就把風險的活都先抓出來。先建立主幹，然後慢慢修整副幹。如此一來就會有充裕的時間，知道當中什麼事必須做，什麼事不需要做。
我在這裏，想要再次強調一個概念「項目不是死的，是活的」。
很多人對於項目開發最大的誤解，就是認爲項目是死的，固定不動的。
項目的進行得按照項目經理寫完的一頁紙，或是說一大本規劃嚴格執行規劃。
但現實真不是這麼執行的。在做項目的過程當中，你會逐漸發現，很多當初的預想都跟真實的想象非常不一樣。
正常的狀況，是很難完成當初預期的一直線計畫，去完成所有的進度。只能「盡力」的「無限逼近成功」。
我在這裏，爲各位總結一下「逆向法」的步驟：
- 先定義成功
- 根據「成功」排定優先級
- 預先保留「測試時間」
- 將剩下的時間切成「三段」
- 第一段：探索、架構主線、預備資源
- 第二段：進行主線要做的事、逐步放棄不重要的事
- 第三段：做好做滿收尾主線，儘量豐滿支線，迭代「重構」功能，始終保持每個版本都是「完整版」
- 大量反覆驗收有風險，會出包的部分
我們在 OTCBTC 開發期間，也是按照這樣的節奏。
整個工期是 35 天。切 10 天爲測試期，25 天是 開發期。
10 天又分爲兩種測試：
- close alpha
- close beta
close alpha 的對象是開發組以及營運組人員。也就是與核心較爲相關的組別。此時針對的測試目標是這個項目業務上應該被「實作」的 主要故事。
在 OTCBTC 這個項目裏，主要的故事
- 使用者可以存幣，取幣
- 使用者可以發佈廣告
- 使用者可以下單
- 使用者可以透過站內系統進行交易細節溝通
- 使用者下單後可以對交易進行評價
測試時的情景，要以不同角色各自對這些故事各模擬一遍。因爲不同角色在同樣功能跑出來的故事流程，是很不一樣的。我們測試的角色有：
- 未登入會員
- 登入會員
- 客服權限
- Admin 權限
各個角色都測過一次。
之所以需要這樣測試的原因，是因爲程序員在撰寫功能時，爲了方便幾乎都是以 admin 帳號在開發。
如果不制定測試步驟和角色，很容易出現流程上的大漏洞。
此時的修復重點放在「補完流程」或「捨去流程」，確認所有「有價值的故事」是否正常運作。
但不需要理會易用度，也不能進行任何 UI 動線上的調整。
close beta 的對象是全公司所有人，公司員工的親朋好友，可以信賴的死忠會員等等...etc. 此時針對的測試目標是這個項目的使用者體驗。（我們後面會有一章 Onboarding，主要就是在講如何領先竟者，預先幾個月迭代出良好的使用者體驗）
- 測試第一次存幣提幣的用戶是否流程容易卡住
- 發佈賣幣廣告有許多細節要注意，如何降低使用者門檻，又不容易發錯廣告造成糾紛
- 流程動線是否讓買賣雙方容易覺得產生不信任
- 不知道下一步該按哪裏
- 網站新訊息的流動是否不夠快速，容易造成網站看起來一片死城
此時已經是視同準上線了（所以 Close Alpha 階段的資料會清掉），所有運營組的人必須視同營運狀態一樣運營站務。
我們還會用真錢真幣實際做交易。以免測不出真的細節。
我們印象中一個比較深刻的測試，是測雙方的下單互動。當時程序員都是「快轉」測試。也就是兩個程序員坐在一起，互相發廣告下單，跟隔壁說「我已經轉錢了，你快給我放幣」。
這樣其實是測不出來細節的。所以我下令測試的時候，兩個測試搭檔是必須要坐在相隔很遠的辦公室，甚至一個人要在家裏，不許用其他方式，不許打電話。純用網站下單溝通，這樣才能真實模擬出來我們的軟件有什麼問題。
所以後來在我們推出新功能後，都會多測一個「快轉」場景。有什麼場景是你因爲是自己開發了，已經很熟，或者是步驟很複雜，所以下意識在測試時「想快轉」。這些在 beta 測試時，都要拿出來一個一個仔細測。
甚至我在上線的頭兩個禮拜。給了各 10 萬人民幣給兩位運營組同事，請他們也真實下去撲單交易。跟一般用戶真實做交易。
一旦用真錢，測試的人，就會更小心。就會更回到用戶心態。用這個方法，我們在早期捕捉到了很多內部測試裏面，自己沒有感知到的細節。
這個階段的修復重點放在 UX 動線的調整，以及運營方針、步驟的調整，避免開站之後迭代太慢，網站變成死城。
我們把 25 天分爲三個階段。
- 部署期
- 主要功能開發期
- 細節補完期
這個項目的部屬期比較短。很大的原因是我們上一個項目是做區塊鏈投資平臺，所以已經有基本的錢包功能（存幣/取幣）了。
所以部署期比較短，主要的時間都是在上一個項目不需要的代碼。
我們在上一張提過 User Story。當中的第五版 User Story 長成這樣
- 身爲一個商家，我要能夠在後臺上架賣幣廣告，並且設定上架販賣
- 身爲一個賣家，可以在管理後臺上架廣告
- 身爲一個賣家，可以在發佈廣告時調整價格
- 身爲一個賣家，廣告錨定的應該是全球 BTC 行情均價
- 身爲一個賣家，可以在買幣者下單後，與賣家溝通進行交易
- 身爲一個賣家，可以在買幣者付完錢打款後，釋放數字貨幣給對方
- 身爲一個賣家，可以在買幣者下單後，收到通知後，立即處理訂單
- 身爲一個消費者，我要能夠在前臺看到廣告，並且下單購買
- 身爲一個消費者，可以在前臺看到下單廣告列表
- 身爲一個消費者，可以在前臺看到廣告內容詳情
- 身爲一個消費者，可以在下單後，與賣家溝通進行交易
- 身爲一個消費者，下單之後，賣家數字幣必須進行鎖定，確保交易安全
- 身爲一個使用者，必須在站上擁有數字貨幣錢包，進行充值 / 提幣
- 身爲一個使用者，可以申請一個錢包 (BTC/ETH)
- 身爲一個使用者，申請錢包後，可以拿到一個數字錢包地址
- 身爲一個使用者，可以充值到錢包地址（6個確認後到帳）
- 身爲一個使用者，可以發起提幣
- 身爲一個使用者，必須經過身份驗證功能，才能使用完整功能
- 身爲一個使用者，必須通過 email 驗證
- 身爲一個使用者，必須通過 實名 驗證（身份證）
- 身爲一個使用者，必須通過 進階 驗證（銀行卡）
- 身爲一個使用者，爲了確保資產安全，必須綁定聯繫方式
- 身爲一個使用者，必須通過 email 驗證
- 身爲一個使用者，必須綁定二步驗證
所以這階段的主要任務是在完成以下 Story 的第一版
- 身爲一個商家，我要能夠在後臺上架賣幣廣告，並且設定上架販賣
- 身爲一個消費者，我要能夠在前臺看到廣告，並且下單購買
- 身爲一個使用者，必須在站上擁有數字貨幣錢包，進行充值 / 提幣
- 身爲一個使用者，必須經過身份驗證功能，才能使用完整功能
- 身爲一個使用者，爲了確保資產安全，必須綁定聯繫方式
在這個階段，甚至我們做得很簡略。甚至是勉強完成整個動線而已。
比如說這個動線。商家發佈廣告 => 使用者看到列表 => 使用者看到廣告頁面下單 => 檢視下單細節
主程的工作就是先完成每條故事的閉環初稿。接著每兩三天，集中起來一條線一條線的「完成主幹功能」。
而細節補完期，就是完成第一版之後，重構一遍再一遍。在進行測試前，至少重構三遍。以下是我們錢包頁面的演化。
第一版甚至連錢包的地址都是假的。程序員只需要專注在頁面上的功能實現。如「顯示二維碼」「複製地址」「察看區塊鏈瀏覽器」。
而真實的地址可以交給獨立的錢包工程師去實現。這樣就可以把開發的相依性徹底分開。
而功能在第二版開始就是「完整版」了，只是「比較醜」而已。
運用這樣的開發法，理論在哪一版都是「完整版」。差別的只是體驗細節。
我們原本信心滿滿的想要在一開始就做出全功能版。
但是在主幹開發期的第三天，程序員就愁眉苦臉的來找我，說完整版實在做不出來。因爲我們根本是重新發明「幣版」的「淘寶」與「阿里旺旺」。
所以當下我的決定，就是
- 將「全功能的買賣廣告」砍到只有「賣廣告」
- 即時聊天室砍掉變成要手動刷新的留言板
- 第一版只支持 BTC
- 只支持簡體中文版
後面纔在「細節補完期」。視人力資源調配，慢慢偷偷補回來。
我在本書一直強調一個概念：「項目是活的」，所以沒有什麼是不能砍的或者是加上去的。
甚至是後期在 onboarding 期間補的細節，還會甚至遠超過大家的想像。但最重要的是，得一直以「成功的完整版」的概念去釋出。「成功的完整版」是指這個網站能夠完成「Jobs to be done」的任務。
Jobs to be done 是創新大師 Clayton Christensen 有一本書 Competing Against Luck: The Story of Innovation and Customer Choice 當中的一個概念。他認爲每一個消費者會去使用一個產品，本質上是僱用這個產品去幹一件活(Jobs to be done)。
這本書的理論是創新不必靠運氣或通靈，只要你找到這件事並正確的提供解決方案，最有效幫助顧客達成任務的業者，就能取得競爭的優勢。
我們做項目的原則與準則也是如此的。