減法開發哲學
我在大公司受過的完整訓練跟經驗是：大公司的那一套完整產品開發經驗跟流程不適合套用在每一個公司，特別是新創公司(startup)。
Startup 本身的資源有限、人力有限，必須要思考如何把資源投注在最重要的項目上，才不致浪費時間在開發“只有 20% 需求的功能”上 – 沒錯，要取悅所有使用者很難，因此，當資源有限時，必須取舍。
先照顧大多數人的需求，確保絕大多數使用者是被滿足的，然后行有馀力再來檢視是否必要滿足剩下的使用者需求 — 有的時候，維持使用者的“饑餓感”是必要之惡，因為，很多時候連我們自己都不確定是否是短暫的需求，抑或可能發展出長久的使用習慣 — 這個問題跟購物慾望很像，當我們很喜歡一件商品時，心里頭可能會開始囤積慾望，不斷的堆積自己必須購買的理由，說服自己“我需要”，進而促成實際的購物行動，但很可能一兩個禮拜后，這件商品就被晾在一旁了。
我認為 Startup 適用的開發方法是“減法開發”。
什么是“減法開發”呢?
1. 盡量列出需求
首先，團隊可以天馬行空發想，依照產品的主要定位構思不同的功能，并列出詳細的使用情境(use case)，假設總共列出了 100 個待開發的功能。在這個階段，我們先不去構思其可行性或是開發的時間。
2. 去蕪存菁
現在，我們提出一個實際的假設：“我們的資源有限，只能開發其中 50 個功能，哪 50 個功能是非得要優先開發的?”
留意到了嗎?第二個階段我們必須思考的問題是：當我們必須取舍時，哪些功能是真正使用者必要使用的。取決“必要”性的關鍵在于，哪些功能是可能“現在(或暫時)沒有也沒有差別”。
3. 專注在核心項目
第三個挑戰來了。“我們只有一半個月時間，依照目前的人力與資源，算一算可能只有 10 – 20 個功能可以如期被開發完成。”
我們必須在 50 個我們在第二階段覺得“一定要開發”的功能里，再篩選出“真正必要”的功能。團隊只需要專注在把第三階段列出的 10 – 20 個功能開發完成即可。
因為，新創公司往往沒有太多的資源，必須要在很快的時間內“做實驗”(interation)，知道實驗的結果，然后不斷的從實驗結果及經驗中快速修正，繼續做下一個實驗，花費太多時間在開發一個大型專案，很容易把僅有的有限資源不知不覺中就耗費掉了。
把使用者的抱怨與不滿變成助力
這是一句老話，可是我們往往(或偶爾)會忘記。千萬別一開始就把所有資源都抑注在一個超大型的專案，因為對很多 Internet 的使用者來說，早已習慣測試新的服務跟產品，并提供自己的使用經驗回饋，別放過廣大的 beta tester 群所能貢獻給你的價值。
開發一個超大型專案所冒的風險不小，因為一個新功能或新產品，往往推出后三個月內就會決定生死：這是一樁一翻兩瞪眼的生意，很快就會知道結果。
所以，如果所冒的風險是如此，我們是要選擇要花一年時間開發一個超大型、超完美的專案，還是很快地在三個月內先推出簡單的版本呢?我會選擇后者。
曾經，有一個公司耗費了很多人力、資源，花了兩年時間開發一個新的服務，結果在一年半時，市場竄出了新的同樣的服務，并且快速地在市場空窗期滿足了使用者需求，擄獲了很多使用者的心，形成一股不小的“實力”，最后只得花大錢跟其他競爭公司競標，買下這個新的服務。
“測水溫”是 Internet 軟體或服務的常態，使用者早已習以為常，對于“不完美”完全可以理解，也很樂于嘗試，因此，先推出CYE核心的功能測水溫，反應好再持續專注開發其他必要的周邊功能來使得這個新服務變得更完善，反應不好，也不必冒著抑注了所有精力，花費很多時間開發一個大專案，卻可能很快便知道不討使用者歡心的結果的風險。
一次給一點，使用者最高興
我承認這是我以前求學、工作時使用過的伎倆 – 使用者的期待是需要被管理的。
如果一次推出 100 項功能，大部分使用者不見得會覺得高興，反而因為面臨太多選擇，亦或是在使用者遭遇到程度不等的問題，在這些功能里“迷航”了，他們心里頭可能會覺得“不好用”。
其實，使用者接觸一個新的服務都需要“學習”。每個使用者的學習曲線會依照他們的專業背景、接觸網路的時間長短等而有所不同，這還不包括“適應”的問題。試想：100 項功能要花多久的時間才能上手，甚至“適應”(順手)呢?
如果只推出 5 項功能，使用者可能會感到驚訝，很快地便可以上手，甚至可能到處廣為宣傳，使用者得到的成就感與滿足感與前者有很大的不同。
你會選擇哪一種方式呢?
想認識全國各地的創業者、創業專家，快來加入“中國創業圈”
|
