今天这个时代迭代开发已经成为常识，甚至政治正确。随便谁就能给你扯两句mvp。敏捷也从一个开发的，名词变成了管理名词。迭代，测试，反馈，名词满天飞。

人人都在说这些术语，仿佛他们真的就懂怎么做软件了。起码，觉得自己真的懂怎么创新了。然而经不起细聊，一旦深入下去聊一个mvp，聊聊他的迭代计划。就会发现露馅了张嘴闭嘴，谈的都是功能。这个迭代要交付几个功能，这个mvp多了什么功能？他的竞争对手都有哪些功能？却很少听到用户人人都在喊，以用户为中心。口号喊得震天响，但你看他们的行为模式，他们的语言，并没有用户的身影。

我时常觉得这个事情不太对劲。但是也没有想到更好的方法。敏捷中使用的故事卡比功能的视角要好一点。因为在故事卡里，你要写下用户的价值。但是，我一直也不知道这个价值是从哪儿来的。是先开枪后画靶子我们想做某个功能了，所以硬按一些价值的。还是真的存在的，价值的单位应该是什么呢？没有单位的东西就无法管理。无法管理，也就无法优化。我们交付的价值是越来越多吗？还是交付的不如以前了？用什么来判断？

回答不了这些问题，不管输赢都是有点不明不白的。这些问题的核心问题就是价值的单位应该是什么？怎么算一个价值？直到我看了，我们公司设计团队的一个框架MERLIN。又在《创新的窘境》，作者的新书《与运气竞争》里，看到了理论依据。这个问题在我这里才算是告一段落。我明白了，以用户为中心的软件开发大概应该怎么做。

方法核心

如果我们想以用户为中心进行软件开发，那么知行要合一，我们的分析方法应该是围绕着用户展开的。

这个方向倒是不新鲜，我们在inception的时候做用需求分析时我们的方法就是围绕着用户展开的。一个典型的分析过程，如下图所示：

我们会在上面画一条轴，标示出用户旅途。这是用户在使用软件的时候的，他的一个全过程。然后在对应的时间点上，标记出，我们的功能。这样我们的功能就不是平白出来的。每一个都联系了用户价值。在ThoughtWorks，我们可能标记的是用户故事，相对于功能，用户故事，首先就是要写出价值。

但是这个图还是不够给力。首先，从用户旅途上的点，到功能的映射简直是个magic move。并不能很好的传递为什么是这样的一个功能，而不是别的功能？毕竟实现一个用户的价值方法有很多。后续在执行的过程当中，难免会僵化行事。 其次，上面的旅途，还可以再抽象和封装。简言之，旅途本身也应该是有抽象层次的。一个旅途上的一个点，可能也是一段新的旅途。

一个更系统的做法是这样的，首先做服务设计：

系统化的分析用户的行为，过程中与企业有哪些触点，在这些触点上用户“雇佣”企业的产品到底是来做什么的，也就是动机。

然后将这些点再进一步细化，采用故事的模式：

当我们定义出了价值的单位，就可以从这一单位的价值里面映射出故事卡，来进行开发过程的管理。

这里就是我们的重点，我们将来交付的软件、交付的服务、我们交付的一个MVP本质上是交付给了用户一组体验。MVP的迭代则应该是更多的体验或某些旧体验的升级（也就是同一个动机，换了一个故事来满足）。

这就是以用户为中心的软件开发的核心。最终我们把用户的价值很好的表达了出来，并且找到了用户体验的基本单位——故事板，由于故事板也可以转化为用户故事，结合早已经存在的敏捷开发方法，也就可以对体验的交付进行度量和管理。达到真正的以用户为中心进行软件开发。