「敏捷」創業 B座12樓
http://xueqiu.com/3495536609/24933688
前幾天在《讓用戶愛上你的產品》(回覆「m」見歷史文章)中，我們提到「想盡辦法地滿足用戶的要求，讓他們無可救藥地愛上你的產品。」文章中對用戶的」要求」與「需求」做了區分，很多朋友回覆消息說蠻有啟發，不少的網站也在轉載，當然我也注意到一些創業者仍有疑問：既然我要想盡辦法地滿足用戶的要求，但是用戶的要求無止境，而且差異性也較大，那我怎麼辦?
我絕不能冒充專家，我只是說說我的看法。
從事軟件開發的朋友們可能都知道，軟件開發比較普遍的有兩種模型，一是瀑布模型，一是敏捷模型。事實上這兩種模型背後所呈現的思維邏輯，也是創業過程中所常見的。
瀑布模型把軟件開發分成各個階段，需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等，每個階段都嚴格定義了輸入和輸出，如果達不到輸出的要求，則下一個階段就不展開。系統測試完成後，軟件交付給用戶，於是整個過程就完成了。
瀑布模型的思維模式是很容易被人接受的模式，感覺理所當然，先瞭解用戶要什麼，然後一步一步直到交付為止。這種模式曾經被廣泛採用。然而它有它的缺點，最大的問題在於無法及時應變。一個項目短則幾個月，長則一兩年，用戶的要求在這期間很可能發生變化。就像用戶要定做一件合體的衣服，你給他量了尺寸，然後悶聲不響地做了幾個月，結果發現幾個月後，用戶長胖了，這個時候返工的成本就太大了。
後來就有了敏捷模型。敏捷模型的核心是迭代，最終目標是讓客戶滿意，所以能夠主動接受需求變更。它的宣言我比較認同：個體和交互勝過過程和工具，可以工作的軟件勝過面面俱到的文檔，客戶合作勝過合同談判，響應變化勝過遵循計劃。尤其是最後一句的」響應變化「，也是我們精益創業的本質。
在敏捷開發過程中，一般兩個星期就會出一個版本，每一個版本與上一個版本相比，會增加幾個特性，用戶的要求如果有變更，可以在最近的一個版本中及時應對。在這種方式下，用戶不需要等待幾個月後直接看到最終版本，而是可以在過程中不斷地參與進來，這對產品滿足用戶的要求是非常重要的。
還是拿剛才定做衣服做例子，在敏捷開發的思維下，裁縫可能先做一件樣衣，布料可能很粗糙，甚至上面劃滿了標記，然後讓你試一試大小，是否合身;過幾天後，再讓你試一試，這時已經用上了正式的面料，你可能覺得衣領的樣式不合適;再過幾天後，你又試了一次，這樣交互下去，直到你心滿意足地拿到了你喜歡的衣服為止。
微信的開發是敏捷模型很好的代表，我們每升級一次版本，就會發現微信的功能有一些變化，語音對講是在2.0版本中出來的，「搖一搖」功能是在3.0版本出來的，到了5.0版本，又對訂閱號做了摺疊處理。這種迭代開發的方式，使得它能夠及時把握市場的反饋從而做出應對。
用戶的要求無止境，所以我們需要借鑑敏捷模型，不斷地調整產品，創業的整個生命週期，就是在不斷地接受反饋，不斷地滿足用戶的要求。
所以不要去擔心用戶要求得太多，你要做的，就是一點一點地做起。
我們經常接觸到一些創業項目，創業者很容易進入一個誤區。他們在一開始就過分完整地規劃了產品的所有細節，然後付出了很多的時間和精力把這些細節實現。錢燒了很多，市場的時機也耽誤了，結果產品一上市，反應很一般。這就是瀑布型的思維模式，試圖完美，想一次性滿足用戶的所有要求，結果發現現實並不完美的時候，改變已經來不及了。
別妄想一次性滿足用戶的所有要求，因為即使是用戶自己，也不一定知道他的所有要求是什麼，更別說用戶的要求會隨著時間的推移而發生變化。
好吧，很多人可能會問：「那我從哪裡開始?」
我的建議是從最為基礎的「可用」開始，微信1.0時，也僅有即時通訊、分享照片和更換頭像等簡單功能。裁縫給客人定做衣服，第一步要保證他們能穿得進去，然後再考慮穿得是否舒服、外觀是否漂亮的問題。
說得通俗一些，用戶對產品的要求就像人類活著的要求一樣。人活著要吃飯，要穿衣，要車子，要房子，要配偶，要看電影，要聽音樂，甚至要登陸月球，這麼多要求，怎麼辦?很簡單，從解決溫飽開始。
在解決「可用」的問題之後，那些讓用戶「好用」的東西該怎麼加上去?我認為這應該去問用戶，而不是在辦公室裡折磨自己。產品和軟件一樣，也是迭代著向前進步的，上一個版本推放市場後，聽一聽用戶說什麼，尤其是說得最多的是什麼，然後，你也許就知道你該怎麼做了。