以用户为中心的软件开发

问题

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

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

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

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

方法核心

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

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

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

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

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

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

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

---

文/ThoughtWorks仝键
更多精彩洞见，请关注微信公众号：思特沃克

来源：Thoughtworks思特沃克中国