2016-08-08 分类: 软件开发
今天这个时代迭代开发已经成为常识,甚至政治正确。随便谁就能给你扯两句mvp。敏捷也从一个开发的,名词变成了管理名词。迭代,测试,反馈,名词满天飞。
人人都在说这些术语,仿佛他们真的就懂怎么做软件了。起码,觉得自己真的懂怎么创新了。然而经不起细聊,一旦深入下去聊一个mvp,聊聊他的迭代计划。就会发现露馅了张嘴闭嘴,谈的都是功能。这个迭代要交付几个功能,这个mvp多了什么功能?他的竞争对手都有哪些功能?却很少听到用户人人都在喊,以用户为中心。口号喊得震天响,但你看他们的行为模式,他们的语言,并没有用户的身影。
我时常觉得这个事情不太对劲。但是也没有想到更好的方法。敏捷中使用的故事卡比功能的视角要好一点。因为在故事卡里,你要写下用户的价值。但是,我一直也不知道这个价值是从哪儿来的。是先开枪后画靶子我们想做某个功能了,所以硬按一些价值的。还是真的存在的,价值的单位应该是什么呢?没有单位的东西就无法管理。无法管理,也就无法优化。我们交付的价值是越来越多吗?还是交付的不如以前了?用什么来判断?
回答不了这些问题,不管输赢都是有点不明不白的。这些问题的核心问题就是价值的单位应该是什么?怎么算一个价值?直到我看了,我们公司设计团队的一个框架MERLIN。又在《创新的窘境》,作者的新书《与运气竞争》里,看到了理论依据。这个问题在我这里才算是告一段落。我明白了,以用户为中心的软件开发大概应该怎么做。
如果我们想以用户为中心进行软件开发,那么知行要合一,我们的分析方法应该是围绕着用户展开的。
这个方向倒是不新鲜,我们在inception的时候做用需求分析时我们的方法就是围绕着用户展开的。一个典型的分析过程,如下图所示:
我们会在上面画一条轴,标示出用户旅途。这是用户在使用软件的时候的,他的一个全过程。然后在对应的时间点上,标记出,我们的功能。这样我们的功能就不是平白出来的。每一个都联系了用户价值。在ThoughtWorks,我们可能标记的是用户故事,相对于功能,用户故事,首先就是要写出价值。
但是这个图还是不够给力。首先,从用户旅途上的点,到功能的映射简直是个magic move。并不能很好的传递为什么是这样的一个功能,而不是别的功能?毕竟实现一个用户的价值方法有很多。后续在执行的过程当中,难免会僵化行事。 其次,上面的旅途,还可以再抽象和封装。简言之,旅途本身也应该是有抽象层次的。一个旅途上的一个点,可能也是一段新的旅途。
一个更系统的做法是这样的,首先做服务设计:
系统化的分析用户的行为,过程中与企业有哪些触点,在这些触点上用户“雇佣”企业的产品到底是来做什么的,也就是动机。
然后将这些点再进一步细化,采用故事的模式:
当我们定义出了价值的单位,就可以从这一单位的价值里面映射出故事卡,来进行开发过程的管理。
这里就是我们的重点,我们将来交付的软件、交付的服务、我们交付的一个MVP本质上是交付给了用户一组体验。MVP的迭代则应该是更多的体验或某些旧体验的升级(也就是同一个动机,换了一个故事来满足)。
这就是以用户为中心的软件开发的核心。最终我们把用户的价值很好的表达了出来,并且找到了用户体验的基本单位——故事板,由于故事板也可以转化为用户故事,结合早已经存在的敏捷开发方法,也就可以对体验的交付进行度量和管理。达到真正的以用户为中心进行软件开发。
文章题目:以用户为中心的软件开发
分享地址:https://www.cdcxhl.com/news23/45473.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有网站维护、软件开发等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联
猜你还喜欢下面的内容