问题
今天这个时代迭代开发已经成为常识，甚至政治正确，随便谁就能给你扯两句mvp。敏捷也从一个开发的名词变成了管理名词，迭代、测试、反馈这类名词满天飞。
人人都在说这些术语，仿佛他们真的就懂怎么做软件了。起码，觉得自己真的懂怎么创新了。然而经不起细聊，一旦深入下去聊一个mvp，聊聊他的迭代计划。就会发现露馅了，张嘴闭嘴谈的都是功能。这个迭代要交付几个功能，这个mvp多了什么功能？他的竞争对手都有哪些功能？却很少听到用户。人人都在喊，以用户为中心。口号喊得震天响，但你看他们的行为模式，他们的语言中，并没有用户的身影，更像只是在否定别人、固执己见的时候拿这个来当借口。
我时常觉得这个事情不太对劲。但是也没有想到更好的方法。敏捷中使用的故事卡比功能的视角要好一点。因为在故事卡里，你要写下用户的价值。但是，我一直也不知道这个价值是从哪儿来的。是先开枪后画靶子我们想做某个功能了，所以硬安的一些价值，还是真的存在的？价值的单位应该是什么呢？没有单位的东西就无法管理。无法管理，也就无法优化。我们交付的价值是越来越多吗？还是交付的不如以前了？用什么来判断？
回答不了这些问题，不管输赢都是有点不明不白的。这些问题的核心问题就是价值的单位应该是什么？怎么算一个价值？一直没想清楚这些问题，直到我看了我们公司设计团队的一个框架MERLIN，又在《创新的窘境》作者的新书《与运气竞争》里看到了理论依据，这个问题在我这里才算是告一段落。我明白了，以用户为中心的软件开发大概应该怎么做。
方法核心
如果我们想以用户为中心进行软件开发。那么我们的分析方法应该是围绕着用户展开的。
这个方向倒是不新鲜，一直以来我们在inception的时候做用需求分析时我们的方法就是围绕着用户展开的，一个典型的分析过程，如下图所示。
我们会在上面画一条轴，标示出用户旅途。这是用户在使用软件的时候的，他的一个全过程。然后在对应的时间点上，标记出我们的功能。这样我们的功能就不是平白出来的。每一个都联系了用户价值。相对于一般人会更容易理解功能，在ThoughtWorks，我们更多标记的是用户故事。比起功能，用户故事增加了有关价值的线索，因为用户故事首先就是要写出价值。
一直以来我觉得这个图还是不够给力。首先，从用户旅途上的点，到功能的映射这一步，简直是个magic move。对未来的读者来说，并不能很好的传递为什么是这样的一个功能，而不是别的功能？毕竟实现一个用户的价值方法有很多。于是后续在执行的过程当中，难免会僵化行事。
其次，上面的旅途，还可以再抽象和封装。简言之，旅途本身也应该是有抽象层次的。一个旅途上的一个点，可能也是一段新的旅途。
所以现在我觉得，一个更系统的做法应该是这样的，首先做服务设计：
系统化的分析用户的行为，过程中与企业有哪些触点，在这些触点上，借用《与运气竞争》里的思维框架来讲，用户“雇佣”企业的产品到底是来做什么的，也就是动机有哪些。
然后将这些点再进一步细化，采用故事的模式：
图上的一行会讲一个故事，就像电影分镜或者漫画一样，来表达用户使用的故事，真正的故事，而不是用户故事那种东西，我们叫这个东西故事板。
在故事板上，我们描绘了一个故事，这个故事里，用户获得了一种体验。一个故事对应一个体验。在基本需求都已经得到满足的今天，体验是新的最有价值的事情，以体验为中心才是以用户为中心。故事板恰好给了我们一个非常符合人类认知习惯的方式来描述什么是一个体验。也就回答了开头的问题，什么是价值的单位。
当我们定义出了价值的单位，就可以从这一单位的价值里面映射出故事卡，来进行开发过程的管理：
这里就是我们的重点，我们将来交付的软件、交付的服务、我们交付的一个MVP本质上是交付给了用户一组体验。MVP的迭代则应该是更多的体验或某些旧体验的升级（也就是同一个动机，换了一个不同的故事来满足）。
最终我们把用户的价值很好的表达了出来，并且找到了用户体验的基本单位——故事板，由于故事板也可以转化为用户故事，结合早已经存在的各种敏捷开发方法，也就可以对体验的交付进行度量和管理，达到以用户为中心进行软件开发。
尾声
很早之前我就觉得MVP是TDD思想在产品策略上的延伸，TDD一个很重要的价值就是避免自嗨从而消除浪费。程序员有时候会因为自嗨写出来好多用不到的功能和设计，这些都是浪费。但是程序员能减少的浪费很有限，最终的最终还是要从需求的源头——用户层面来减少浪费才能真的做好。所谓顾客就是上帝，软件开发中用户就是上帝，这句话的意思不是说用户说什么你就做什么，而是说你只有贴近用户，才能得到上帝的启示，现场有神明，就是这么个道理。
有了MVP之后，就像开发有了测试驱动。我们就可以避免很多过度设计。但是MVP作为测试，粒度太大了，不好分析，不好写断言，不能得到精细的反馈。这里我们把它分解到故事板层面，就可以得到精确的测试目标，也就可以做真正精细的测试，真正做到以用户为中心。