【深圳软件开发】以用户为中心的软件开发有什么优势?
作者:admin
阅读量:146
2021-05-24 15:45:43

在当今时代,迭代开发已经成为常识,甚至在政治上也是正确的。任何人都可以告诉你一些关于MVP的事情。敏捷也从开发术语转变为管理术语,迭代、测试和反馈等术语遍布全球。

每个人都在谈论这些术语,好像他们真的知道如何制作软件。至少,我想我真的知道如何创新。不过,我们不能细谈。一旦我们深入研究,我们就可以讨论MVP和他的迭代计划。你会发现这一切都与功能有关。这个迭代需要交付多少个函数?这个MVP有什么功能?他的竞争对手的职能是什么?但很少有用户听到。每个人都在喊,以用户为中心。口号是响亮的,但你可以看到他们的行为模式。他们的语言中没有用户。这更像是当他们拒绝别人,坚持自己的观点时,以此为借口。

我经常觉得这样不对。但我没有想到更好的办法。敏捷中使用的故事卡比功能性的观点要好一点。因为在故事卡片上,你必须写下用户的价值。然而,我从不知道这个值来自哪里。我们要先射击,然后再画靶子吗?我们想做某种功能,那么我们真的有硬安全的价值吗?什么是价值单位?没有单位的东西是无法管理的。如果它不能被管理,它就不能被优化。我们是否提供了越来越多的价值?还是交货不如以前?如何判断?

如果你不能回答这些问题,你输赢就有点不清楚了。这些问题的核心是什么应该是价值单位?如何计算一个值?直到读了我们公司设计团队的一个框架Merlin,看到了《创新的困境》一书作者的新书《与幸运的竞争》中的理论基础,我才把这些问题想清楚。这个问题到此为止。我已经了解了以用户为中心的软件开发应该做什么。

如果我们想在软件开发中以用户为中心。所以我们的分析方法应该围绕用户。

这个方向并不新鲜。一直以来,当我们在初始阶段进行需求分析时,我们的方法关注的是用户。典型的分析过程如下图所示。

我们将在上面画一个轴来标记用户的旅程。这是用户使用软件的整个过程。然后,在相应的时间点,标记我们的函数。这样,我们的功能就不简单了。每一个都与用户值相关联。在ThoughtWorks中,我们比普通人更关注用户故事。与函数相比,用户故事增加了关于价值的线索,因为用户故事的一件事就是写价值。

我一直觉得这张照片够棒的。首先,从用户旅程的角度到功能的映射,这是一个神奇的举动。对于未来的读者来说,这不是一个好的方式来表达为什么这样一个功能,而不是其他功能?毕竟,实现用户价值的方法有很多种。因此,在执行过程中,必然会采取僵化的行动。

第二,上述旅程可以抽象和概括。简而言之,旅程本身应该是抽象的。旅程中的一个点也可能是一个新的旅程。

所以现在我觉得一个比较系统的方法应该是:服务设计

系统地分析了用户的行为以及在此过程中与企业的联系。在这些联系上,运用“拼运气”的思维框架,用户“雇佣”企业产品的动机是什么。

然后,对这些要点进行进一步细化,采用故事模式

图片中的一条线会讲述一个故事,就像电影或卡通一样,表达用户的故事,真实的故事,而不是用户的故事。我们称之为故事板。在故事板上,我们描述了一个用户体验的故事。一个故事对应一次经历。在满足基本需求的今天,体验是新的、最有价值的东西,以体验为中心就是以用户为中心。故事板只是给了我们一种方式来描述什么是符合人类认知习惯的体验。也就是说,什么是价值单位。

当我们定义值单元时,我们可以从这个单元的值映射故事卡来管理开发过程

这是我们的重点。我们在未来提供的软件、服务和MVP本质上是提供给一组用户体验的。MVP的迭代应该是更多的经验或者一些旧经验的升级(也就是说,相同的动机被不同的故事所满足)。

最后,我们很好的表达了用户的价值,找到了用户体验故事板的基本单元。因为故事板也可以转化为用户故事,结合现有的各种敏捷开发方法,我们可以度量和管理交付的体验,实现以用户为中心的软件开发。

很久以前,我认为MVP是TDD在产品策略上的延伸。TDD最重要的价值之一是避免自我满足和消除浪费。程序员有时会写很多函数和设计,因为自我完善而无法使用,这是一种浪费。但是程序员能减少的浪费是非常有限的,最终还是从需求的源头——用户层面减少浪费才能真正做好。在软件开发中,所谓客户就是上帝,用户就是上帝。这句话并不意味着你可以做任何用户说,但你只能从上帝那里得到灵感,如果你接近用户。这是事实。

有了MVP,就像用测试驱动程序开发一样。我们可以避免很多过度设计。然而,作为一种测试,MVP过于精细,无法分析、编写断言和获得良好的反馈。在这里我们把它分解到故事板级别,我们可以得到准确的测试目标,我们也可以做真正的精细测试,真正做到以用户为中心。