人人都在说这些术语，仿佛他们真的就懂怎么做软件了。起码，觉得自己真的懂怎么创新了。然而经不起细聊，一旦深入下去聊一个mvp，聊聊他的迭代计划。就会发现露馅了张嘴闭嘴，谈的都是功能。这个迭代要交付几个功能，这个mvp多了什么功能？他的竞争对手都有哪些功能？却很少听到用户人人都在喊，以用户为中心。口号喊得震天响，但你看他们的行为模式，他们的语言，并没有用户的身影。
我时常觉得这个事情不太对劲。但是也没有想到更好的方法。敏捷中使用的故事卡比功能的视角要好一点。因为在故事卡里，你要写下用户的价值。但是，我一直也不知道这个价值是从哪儿来的。是先开枪后画靶子我们想做某个功能了，所以硬按一些价值的。还是真的存在的，价值的单位应该是什么呢？没有单位的东西就无法管理。无法管理，也就无法优化。我们交付的价值是越来越多吗？还是交付的不如以前了？用什么来判断？
回答不了这些问题，不管输赢都是有点不明不白的。这些问题的核心问题就是价值的单位应该是什么？怎么算一个价值？直到我看了，我们公司设计团队的一个框架MERLIN。又在《创新的窘境》，作者的新书《与运气竞争》里，看到了理论依据。这个问题在我这里才算是告一段落。我明白了，以用户为中心的软件开发大概应该怎么做。
如果我们想以用户为中心进行软件开发，那么知行要合一，我们的分析方法应该是围绕着用户展开的。
这个方向倒是不新鲜，我们在inception的时候做用需求分析时我们的方法就是围绕着用户展开的。一个典型的分析过程，如下图所示：
我们会在上面画一条轴，标示出用户旅途。这是用户在使用软件的时候的，他的一个全过程。然后在对应的时间点上，标记出，我们的功能。这样我们的功能就不是平白出来的。每一个都联系了用户价值。在ThoughtWorks，我们可能标记的是用户故事，相对于功能，用户故事，首先就是要写出价值。
但是这个图还是不够给力。首先，从用户旅途上的点，到功能的映射简直是个magic move。并不能很好的传递为什么是这样的一个功能，而不是别的功能？毕竟实现一个用户的价值方法有很多。后续在执行的过程当中，难免会僵化行事。 其次，上面的旅途，还可以再抽象和封装。简言之，旅途本身也应该是有抽象层次的。一个旅途上的一个点，可能也是一段新的旅途。
一个更系统的做法是这样的，首先做服务设计：
系统化的分析用户的行为，过程中与企业有哪些触点，在这些触点上用户“雇佣”企业的产品到底是来做什么的，也就是动机。
然后将这些点再进一步细化，采用故事的模式：
图上的一行会讲一个故事，就像电影分镜或者漫画一样，来表达用户使用的故事，真正的故事，而不是用户故事那种东西，我们叫这个东西故事板。 在故事板上，我们描绘了一个故事，这个故事里，用户获得了一种体验。一个故事对应一个体验。在基本需求都已经得到满足的今天，体验是新的最有价值的事情，以体验为中心才是以用户为中心。故事板恰好给了我们一个非常符合人类认知习惯的方式来描述什么是一个体验。也就回答了开头的问题，什么是价值的单位。
当我们定义出了价值的单位，就可以从这一单位的价值里面映射出故事卡，来进行开发过程的管理。
这里就是我们的重点，我们将来交付的软件、交付的服务、我们交付的一个MVP本质上是交付给了用户一组体验。MVP的迭代则应该是更多的体验或某些旧体验的升级（也就是同一个动机，换了一个故事来满足）。
这就是以用户为中心的软件开发的核心。最终我们把用户的价值很好的表达了出来，并且找到了用户体验的基本单位——故事板，由于故事板也可以转化为用户故事，结合早已经存在的敏捷开发方法，也就可以对体验的交付进行度量和管理。达到真正的以用户为中心进行软件开发。
文/ThoughtWorks仝键
原文：https://insights.thoughtworks.cn/user-centered-software-development/
