需求分析：将用户实例化抽象化虚拟化

我之前接触的大多数公司做需求分析经常是这样一种文档：系统应该支持什么什么、系统应该做到什么什么……通常都是这么一种描述。开发人员如果对这个领域有点熟悉，可能还会建议说能干什么不能干什么。如果是初来乍到的，看了以后，可能惟一能记住的是系统应该做什么。但实际上，说不出一二三。

在敏捷里面，这样做事的方式是要变化一下。比如我们会分析几种典型的用户：

第一个类叫委托人，是所谓真正掏钱买软件的人，买软件和用软件是两类人，采购拍板的是老板，他的需求是一种需求，我们通常叫委托人。

第二类叫终端用户，是实际上经常用你的软件和产品的人。

第三类叫合作方。如果说你做传统ERP软件，不可能一个人做，有服务器，有合作方，合作方又是另外一类。

还有一类是内部客户，我们提供客户的管理员，还有写文档的人。

我们从这四个角度去划分用户，然后再针对每种用户进行实例化。比如做招聘相关产品的，抽象出一个招聘主管，叫杜拉拉。我们会定义它的用户属性，它到底怎么做。这主要的是帮助大家建立起真实的虚拟用户的情形，帮我们去理解他这种用户会在什么情况下怎么使用你的系统。

刚才讲我们传统的需求是系统应该做什么，在这里面我们在描述需求的时候不是这样描述的，我们经常说，对于杜拉拉她想要做什么事情，达到什么目的，首先定位角色，他属于哪类用户，然后他要做什么事，做这个事的终结果是什么，这个结果代表了什么，是价值。是说我们做这个产品功能有没有价值，在敏捷里面我们讲是价值驱动，真正对客户有用的东西我们才去做，没用的东西我们不做。所以我们会讲价值大化。

从上下文的描述，能够帮助大家快速的去理解一个软件，一个系统到底该做什么，应该做什么，更好的去把握需求。我们再把所有的需求做细分之后，我们把重要的20%找出来然后开始做。

利用MVP理论找出重要的20%需求

按照上面的思路，创业团队已经能够较好的完成第一步的工作，可以把产品做出来、推向市场并接受客户的买单。但也还是会遇到一些问题，比如在敏捷开发中通常会提倡客户沟通，但当客户多了的时候，会发现需求也越来越多，有时候团队会被客户趋势，做的东西也越来越多。后，东西多了，用户也有提升，但是转化率反而会下降。这是因为客户的需求其实一直保持在20%，但后来客户发现新增的许多东西并不是他所需要的，会不想掏钱。

这是因为我们在做这些事的时候，走了一个偏方，离我们初的目标越来越远，不是我们真正想要做的事情。所以，我们要清楚：要做做重要的20%！

那这如何找出重要的20%需求呢？或者说我认为20%是重要的，我怎么去验证它？这里需要用到MVP理论了。MVP，讲的是小可行产品。如图所示，有两个圈，一边表示小的产品，一边讲可行的产品。

对于创业公司、小团队，应该做MVP。再次一定要把小产品区分出来，小产品它不代表是可行的，什么是可行的，是你这个东西是对客户有价值的，真的能够卖给客户的。我们这里面讲MVP，小可行的真正卖给客户，客户愿意买单的这么一个产品。