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