第 2 章 价值就是那些我们想要的东西

第 2 章 价值就是那些我们想要的东西

软件的价值是什么?

我们都想要价值。所谓价值,就是那些我们想要的东西。是的,价值就是那些我们想要的东西。在软件开发领域,通常我们通过交付功能来获得价值。当然,这些功能都是有价值的功能,也是我们想要的功能。

通常,软件的价值都与金钱有关,因为软件能够帮助人们节省时间或金钱。软件也能够帮助我们赚钱。当然,也有其他类型的价值,比如说软件能够使人们的生活更加便利。有时,软件甚至能够挽救人的生命。

总之,我认为价值就是那些我们想要的东西。或许我们很喜欢用数字来表示价值,然而并非必须这样做。当构建软件时,我们将做出很多选择,每一种选择都会带来一些我们认为有价值的东西。我们可能会选择信息、用户的快乐或者是挽救人的生命。我们会选择任何有意义的事,选择那些我们想要的东西

随着这一工作的完成,我们会继续选择下一件想要的东西。我们会让研发团队以他们最快的速度、用最可靠的方式,将所选择的价值融入到软件中。当他们构建好软件之后,我们要确保得到了想要的东西,也就是说我们会检验软件的价值。

为了检验价值,我们会说:“请演示一下软件。”

那么,你的项目会为用户提供什么样的价值呢?它又会为你的公司带来什么样的价值呢?此外,它还能够为你所在的团队(当然也包括你)带来什么样的价值呢?

{%}

当软件发布时,它的价值才能够体现。

只有当软件发布并被实际使用时,项目才实现了价值的交付。如果要一直等到所有的工作完成,那么通常要过很长一段时间才能够获得价值。因此,我们需要找到一种方法尽早地交付价值。

假设我们想现在就拥有如图所示的小马,而不是以后,但现实是我们并不能够马上就创造出所有的一切。我们心中有许多想要实现的功能特性,但实现这些功能特性需要花费一定的时间。想要的功能特性越多,需要花费的时间就越长。

那么,尽早交付会有什么好处呢?公司又会如何受益呢?团队以及你我个人又会如何呢?

{%}

如果软件的某个有价值的部分能够比其他部分更早交付,会是什么情况?

每个产品都由很多部分组成。我们将这些组成部分称作功能特性(feature),或者最小可市场化功能特性(minimum marketable feature, MMF);也可以称它们为方面(aspect)、功能(function)或者能力(capability)。每一个大的功能特性又都由更小的部分组成,这些满是细节的组成部分使整个大的功能特性更完整、更有用,或者说更完善。

需要记住的是,大部分用户并不会使用产品的每一个功能特性,这里会有一种人们通常所说的 80/20 法则存在。每个人想要的功能特性可能都不同,但是没有人想要所有的功能特性。即使是那些你最熟悉、用得最多的产品,你也很有可能只是使用了其中一部分的功能特性。

{%}

推出更小的产品有意义吗?

既然大部分用户并不会使用所有的功能特性,那么更小的功能特性集合就能够提供真正的价值,而且推出这样的产品也会更快。有时,我们会认为必须实现所有的功能特性。面对现实吧:如果你曾经经历过很多软件项目,很可能会知道,在计划的时间里是不可能得到所有想要的功能特性的。我们从来都没有做到过。

我们可以捶胸顿足,要求立刻有一匹小马,或者也可以表现得更像管理者,引导软件项目获得最好的结果。很有可能会发生下面这种情况:软件的一部分功能特性能够更早地服务于用户并产生价值。因此,我们需要找出并首先推出这些功能特性。这样就会获得成功。

在第一次发布后,需要继续跟进产品的其他功能特性,否则最终的产品在整个生命期内的价值就会缩水。因此,通常我们都会有多次发布版本的计划。

但是,也有可能只发布了第一版,然后就停止了。那么,在什么情况下这是最好的做法呢?你能够想出多少种理由呢?

{%}

只交付一部分功能特性就不再发布?

如果只发布一次的话,我们将会更早获得回报。但是,与发布完整的产品相比,这样做所获得的回报可能会少得多,即使发布完整的产品在时间上要迟很多。真的如此吗?

信息同样也有价值。有时,我们能得到的最重要的信息就是,自己正在做一件错误的事情。要想知道方向是否正确,一个好的方法就是尽早发布产品的小版本。这样如果失败了,就能够以较小的代价转变方向。

更常见的情况是,我们的想法的确很不错。有了不错的想法,应该从哪些功能特性入手呢?产品应该怎样一次只发布一部分功能特性呢?划分出的功能特性又是什么样的呢?

{%}

我们必须看到并且理解产品的各个部分。

研发团队整天从事着那些只对他们有意义、神秘的技术工作,这样做是不够的。

我们需要引导团队构建不仅对我们有意义,同时对用户也有意义的功能特性。这样的功能特性通常被称为最小可市场化功能特性。事实上,与通常的最小可市场化功能特性相比,在更细的粒度上提供商业方向更能使我们受益。

我们称这些部分为功能特性。当说“请演示一下软件”时,我们想要看见的是那些我们想要并且理解的功能特性。

回顾以前的项目,那些你希望能够更早发布的功能特性是什么?你为什么希望这些功能特性能够更早发布?又有哪些功能特性应该是不同的呢?是否还有一些功能特性根本就不应该实现?

{%}

根据功能特性划分价值。

可能实现的每一个功能特性都会为整个产品增加一些价值;同时,实现每一个功能特性都需要花费一定的时间。虽然并不能够确切地知道每个功能特性有多大的价值或者需要花费多少时间,但是我们仍然可以很好地感知应该做些什么。

假设每个功能特性的高度代表它的价值,而宽度代表它的成本。那么,哪些功能特性是我们应该首先实现的?哪些又是可以推迟到以后去实现的?这样,我们可以一目了然,不是吗?

{%}

价值的增长取决于我们选择做什么。

如上图所示,如果我们选择首先完成高价值、低成本的功能特性,并将低价值、高成本的功能特性推迟到以后去完成,就能够看出价值增长的巨大差异。注意,图中所示价值差异的比值最大也只是 3∶1。然而,在大多数产品中,最好的想法要比最坏的想法好几十倍,甚至更多。如果是这种情况的话,则结果很难在这一页上显示。

一些被推迟实现的功能特性看起来相当无趣。如果我们去实现一些不同的、更有价值的功能特性,甚至是在另外的产品上这样做,又会有什么情况发生呢?

{%}

我们甚至可以将投资转移到新的产品上!

当我们频繁地优先发布价值最高的功能特性时,很快就会发生下面这种情况:下一个要发布的功能特性并不值得我们花费这么多时间与金钱去实现。发生这种情况,是一件好事。通过投资新产品,通常我们都能做得更好。

那么,我们想要做什么样的新产品呢?又会有谁因为产品变更而受到负面的影响呢?怎样才能使产品变更对所有人来说都是好事呢?我们是否能够专注于系列产品,而不是回报率一直在降低的不同产品?我们能够提供更多软件并且同时提供更多价值吗?

{%}

价值的最大化在于频繁交付小的、以价值为中心的功能特性。

好了,我们看到,如果能够这样做的话,小的功能特性可以更早地实现价值的交付。下面,我们来考虑项目的管理问题。更小且可见的结果是否有助于项目管理?它们又是否会有碍于管理?

我们的团队又是怎样的呢?他们是按这种工作方式组织起来的吗?团队拥有所需要的人员、所需要的技能,以及所需要的帮助吗?请继续阅读本书后面的内容,我们会逐一讨论所有这些问题。

需要记住的是,以逐个实现功能特性的方式发布软件,能够获得最好的结果。

进阶阅读:

  • 第 10 章 价值是什么

  • 第 11 章 如何衡量价值

目录