需求分析：將用戶實例化抽象化虛擬化
我之前接觸的大多數公司做需求分析經常是這樣一種文檔：系統應該支持什么什么、系統應該做到什么什么……通常都是這么一種描述。開發人員如果對這個領域有點熟悉，可能還會建議說能干什么不能干什么。如果是初來乍到的，看了以后，可能惟一能記住的是系統應該做什么。但實際上，說不出一二三。
在敏捷里面，這樣做事的方式是要變化一下。比如我們會分析幾種典型的用戶：
第一個類叫委托人，是所謂真正掏錢買軟件的人，買軟件和用軟件是兩類人，采購拍板的是老板，他的需求是一種需求，我們通常叫委托人。
第二類叫終端用戶，是實際上經常用你的軟件和產品的人。
第三類叫合作方。如果說你做傳統ERP軟件，不可能一個人做，有服務器，有合作方，合作方又是另外一類。
還有一類是內部客戶，我們提供客戶的管理員，還有寫文檔的人。
我們從這四個角度去劃分用戶，然后再針對每種用戶進行實例化。比如做招聘相關產品的，抽象出一個招聘主管，叫杜拉拉。我們會定義它的用戶屬性，它到底怎么做。這主要的是幫助大家建立起真實的虛擬用戶的情形，幫我們去理解他這種用戶會在什么情況下怎么使用你的系統。
剛才講我們傳統的需求是系統應該做什么，在這里面我們在描述需求的時候不是這樣描述的，我們經常說，對于杜拉拉她想要做什么事情，達到什么目的，首先定位角色，他屬于哪類用戶，然后他要做什么事，做這個事的終結果是什么，這個結果代表了什么，是價值。是說我們做這個產品功能有沒有價值，在敏捷里面我們講是價值驅動，真正對客戶有用的東西我們才去做，沒用的東西我們不做。所以我們會講價值大化。
從上下文的描述，能夠幫助大家快速的去理解一個軟件，一個系統到底該做什么，應該做什么，更好的去把握需求。我們再把所有的需求做細分之后，我們把重要的20%找出來然后開始做。
利用MVP理論找出重要的20%需求
按照上面的思路，創業團隊已經能夠較好的完成第一步的工作，可以把產品做出來、推向市場并接受客戶的買單。但也還是會遇到一些問題，比如在敏捷開發中通常會提倡客戶溝通，但當客戶多了的時候，會發現需求也越來越多，有時候團隊會被客戶趨勢，做的東西也越來越多。后，東西多了，用戶也有提升，但是轉化率反而會下降。這是因為客戶的需求其實一直保持在20%，但后來客戶發現新增的許多東西并不是他所需要的，會不想掏錢。
這是因為我們在做這些事的時候，走了一個偏方，離我們初的目標越來越遠，不是我們真正想要做的事情。所以，我們要清楚：要做做重要的20%！
那這如何找出重要的20%需求呢？或者說我認為20%是重要的，我怎么去驗證它？這里需要用到MVP理論了。MVP，講的是小可行產品。如圖所示，有兩個圈，一邊表示小的產品，一邊講可行的產品。
對于創業公司、小團隊，應該做MVP。再次一定要把小產品區分出來，小產品它不代表是可行的，什么是可行的，是你這個東西是對客戶有價值的，真的能夠賣給客戶的。我們這里面講MVP，小可行的真正賣給客戶，客戶愿意買單的這么一個產品。
