敏捷創業：怎樣發現使用者的「要求」？

仲介交易 HTTP://www.aliyun.com/zixun/aggregation/6858.html">SEO診斷 淘寶客 雲主機 技術大廳

前幾天在《最好的產品滿足的不是需求，而是「要求」》中，我們提到「想盡辦法地滿足使用者的要求，讓他們無可救藥地愛上你的產品。 」文章中對使用者的「要求」與「需求」做了區分，很多朋友回復消息說蠻有啟發，但我也注意到一些創業者仍有疑問：既然我要想盡辦法地滿足使用者的要求，但是使用者的要求無止境，而且差異性也較大，那我怎麼辦?

我絕不能冒充專家，我只是說說我的看法。

從事軟體發展的朋友們可能都知道，軟體發展比較普遍的有兩種模型，一是瀑布模型，一是敏捷模型。 事實上這兩種模型背後所呈現的思維邏輯，也是創業過程中所常見的。

瀑布模型把軟體發展分成各個階段，需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等，每個階段都嚴格定義了輸入和輸出，如果達不到輸出的要求，則下一個階段就不展開。 系統測試完成後，軟體交付給使用者，於是整個過程就完成了。

瀑布模型的思維模式是很容易被人接受的模式，感覺理所當然，先瞭解使用者要什麼，然後一步一步直到交付為止。 這種模式曾經被廣泛採用。 然而它有它的缺點，最大的問題在於無法及時應變。 一個專案短則幾個月，長則一兩年，使用者的要求在這期間很可能發生變化。 就像使用者要定做一件合體的衣服，你給他量了尺寸，然後悶聲不響地做了幾個月，結果發現幾個月後，使用者長胖了，這個時候返工的成本就太大了。

後來就有了敏捷模型。 敏捷模型的核心是反覆運算，最終目標是讓客戶滿意，所以能夠主動接受需求變更。 它的宣言我比較認同：個體和交互勝過過程和工具，可以工作的軟體勝過面面俱到的文檔，客戶合作勝過合同談判，回應變化勝過遵循計畫。 尤其是最後一句的」回應變化「，也是我們精益創業的本質。

在敏捷開發過程中，一般兩個星期就會出一個版本，每一個版本與上一個版本相比，會增加幾個特性，使用者的要求如果有變更，可以在最近的一個版本中及時應對。 在這種方式下，使用者不需要等待幾個月後直接看到最終版本，而是可以在過程中不斷地參與進來，這對產品滿足使用者的要求是非常重要的。

還是拿剛才定做衣服做例子，在敏捷開發的思維下，裁縫可能先做一件樣衣，布料可能很粗糙，甚至上面劃滿了標記，然後讓你試一試大小，是否合身;過幾天後，再讓你試一試，這時已經用上了正式的面料，你可能覺得衣領的樣式不合適; 再過幾天後，你又試了一次，這樣交互下去，直到你心滿意足地拿到了你喜歡的衣服為止。

微信的開發是敏捷模型很好的代表，我們每升級一次版本，就會發現微信的功能有一些變化，語音對講是在2.0版本中出來的，「搖一搖」功能是在3.0版本出來的，到了5.0版本，又對訂閱號做了折疊處理。 這種反覆開發的方式，使得它能夠及時把握市場的回饋從而做出應對。

使用者的要求無止境，所以我們需要借鑒敏捷模型，不斷地調整產品，創業的整個生命週期，就是在不斷地接受回饋，不斷地滿足使用者的要求。

所以不要去擔心使用者要求得太多，你要做的，就是一點一點地做起。

我們經常接觸到一些創業專案，創業者很容易進入一個誤區。 他們在一開始就過分完整地規劃了產品的所有細節，然後付出了很多的時間和精力把這些細節實現。 錢燒了很多，市場的時機也耽誤了，結果產品一上市，反應很一般。 這就是瀑布型的思維模式，試圖完美，想一次性滿足使用者的所有要求，結果發現現實並不完美的時候，改變已經來不及了。

別妄想一次性滿足使用者的所有要求，因為即使是使用者自己，也不一定知道他的所有要求是什麼，更別說使用者的要求會隨著時間的推移而發生變化。

好吧，很多人可能會問：「那我從哪裡開始?」

我的建議是從最為基礎的「可用」開始，微信1.0時，也僅有即時通訊、分享照片和更換頭像等簡單功能。 裁縫給客人定做衣服，第一步要保證他們能穿得進去，然後再考慮穿得是否舒服、外觀是否漂亮的問題。

說得通俗一些，使用者對產品的要求就像人類活著的要求一樣。 人活著要吃飯，要穿衣，要車子，要房子，要配偶，要看電影，要聽音樂，甚至要登陸月球，這麼多要求，怎麼辦?很簡單，從解決溫飽開始。

在解決「可用」的問題之後，那些讓使用者「好用」的東西該怎麼加上去?我認為這應該去問使用者，而不是在辦公室裡折磨自己。 產品和軟體一樣，也是反覆運算著向前進步的，上一個版本推放市場後，聽一聽使用者說什麼，尤其是說得最多的是什麼，然後，你也許就知道你該怎麼做了。