敏捷和精益开发，玩转MVP不要错过这四个案例

几年前，我画了这张图，并开始在介绍敏捷和精益开发时使用它：

从那时起，这张图就像病毒一样传播！到处都出现了，在文章中出现，在演讲中出现，甚至在书中出现（Jeff Patton的《用户故事地图》中就出现了——顺便说一下，这是本好书）。很多人告诉我，这张图确实抓住了迭代和增量开发、精益创业以及MVP（最小可行产品）之类的本质。然而也存在一些误解——如果你抛开原始语境而只看这张图的话，自然就会出现这种情况。还有些人批评说它把事情简化过头了，这也是对的。这张图只是一个隐喻而已。它并不是在讲述一个真实的汽车开发过程，而是说明普通的产品开发过程，只是用汽车打比方而已。

不管怎样，既然有了这么多不同的声音，我想是时候对这张图背后的含义做个解释了。

第一个例子——“Not Like This”（“不要这样做”这张图）

下面这行图显示了，对迭代和增量产品开发（又称为敏捷）的一个常见误解。

许多项目失败很大程度上是因为他们做了大爆炸交付（直到100%完成了才构建产品并在项目结束时交付）。我不记得我见过多少因为这个原因而失败的项目（后面有些例子）。然而，当敏捷开发被介绍为一种替代方案时，人们有时候却难以接受半成品时就交付的理念——谁会想要半台汽车呢？设想一下这样的场景：

“先生，这是我们首次迭代的产物——一只前轮。您觉得怎么样？”

客户会像这样回答：“见鬼，我订的是整台车，而你却只给我个轮胎！这东西我能用来干嘛？”

（顺便说一声，我在这里使用“客户”这个术语，作为一个通用术语，用于代表产品经理、产品负责人以及早期用户之类的人员。）

虽然每次交付的产品越来越接近于完成，但是客户仍然非常生气，因为他得到的车并不完整，仍然不能真正使用。

最后，当产品完成时，客户会像这样说：“最后还是谢谢你！你为什么不一开始就给我这个，而不是给我那些无用的垃圾？”

在这个例子中，客户对最终产品感到满意，因为这就是他所订购的产品。而在现实中，这通常不成立。时间已经过去很久了，但却没有经过任何实际的用户体验，所以产品中很可能充斥着人们基于对用户需求的错误假设而产生的设计缺陷。 因此，右边的那张笑脸只是极其理想的情况。

不管怎样，第一行代表了“劣质的敏捷开发”。从技术上看，它可能是增量和迭代交付的，但由于没有形成真正的反馈环，使得产品开发变得极具风险——并且也绝对不是敏捷开发。

因此，给出了“Not Like This”（不要这样做）这个标题

第二个例子——“Like This”（“要这样做”这张图）

现在看第二行。

在这里，我们采用了非常不同的方法。我们都开始于同样的背景——客户订购了一台汽车。但这一次我们并非只构建一台汽车。取而代之的是，我们聚焦于客户想要满足的潜在需求。原来，客户的潜在需求是“我需要更快地从A到达B”，而汽车只是一个可能的解决方案而已。

记住，汽车只是一个隐喻，要考虑任何一种客户定制的产品开发情况。

因此，团队要提供的是他们能够想到的、能够让客户体验、并给予反馈的最小产品。有些人可能会称其为MVP（最小可行产品），不过我更喜欢称其为最早可体验的产品（这种说法更加具体）。

可以根据你自己的喜好来称呼MVP（甚至有些人会基于这个隐喻，称他们的第一个发布版本为“滑板版本”。）

客户不太可能会对这个产品感到满意。这东西好像与他订购的汽车没有半毛钱关系。但是不要紧！这就是重点——我们并不试图让客户在此时就感到满意。我们可能会让少数早期用户感到满意，但我们此时的主要目标只是学习。理论上，团队会事先向客户解释清楚，因此客户也不会太失望。

然而，相对于在第一个例子场景中团队交付的前轮，滑板是一个实际能用的东西，能够帮助客户从A到达B。虽然帮助不大，但聊胜于无。因此我们会告诉客户：“别担心，项目还没有结束，这只是第一个迭代而已。 我们仍然致力于构建一台汽车，但同时请试用并向我们提供反馈”。心思很大，但还得以小功能的可行增量来交付。

我们可能会学习到一些令人惊讶的事情。例如我们可以假象这种场景：客户说他不喜欢滑板，我们问为什么。他说：“我讨厌这个颜色。”我们这样回答：“嗯…，颜色吗？就这些？”客户说：“是的，换成蓝色！除此之外都很好！”你刚刚节省一大笔钱，因为不用再去构建一台汽车！这种可能性不太大，但谁敢肯定一定不会发生呢？

关键问题是“什么是我们能学习得最快和最便宜的方式？”。我们能否交付甚至比交付滑板还早的东西呢？公共汽车票怎么样？

这有助于解决客户的问题吗？也许能，也许不能，但通过把东西交到真实客户的手里，我们绝对能够学习到什么。精益创业提供了一个非常棒的模型。它的基础是：列出你对用户的假设，然后按部就班地将其证实或者证伪。

你不用让所有用户体验产品，甚至你也不用为了体验什么而特地构建一个产品。与什么都不做相比较，就算只找一个用户进行原型体验都能让你学到更多。

但是没关系，我们回到滑板的例子。

在办公室里玩了一圈后，客户说：“不错，有点意思，能让我更快地到达咖啡机边上。但是不太稳，我太容易掉下来了。”

因此，下一次迭代我们会试图解决这个问题，或者至少进一步研究这个问题。

现在，客户能够踩着滑板在办公室转悠，而且不会再掉下来！

客户满意了吗？未必满意，他可能还是有点想要那台车。但在这期间，他实际上正在使用产品，并给予我们反馈。他最大的痛点是难以走得更远点。因此，下次发布的产品会变成类似于自行车的东西。

现在，客户能把活动范围扩大的园区了。Yiihaaa！

在这个过程中，我们学习到一些新的东西：客户喜欢呼吸新鲜空气。客户是在一个园区，并且其交通主要是在大楼之间转悠。

结果可能自行车是比原先设想的汽车更好的产品。事实上，在体验这个产品时，我们可能会发现，对于汽车来说路太窄了。我们刚刚替客户节省了大量的时间和金钱，并以更短的时间提供给更好的产品！

现在，你可能会想：“但我们不是应该通过前期的客户背景和需求分析来知道那些吗？”说得好。但在我见过的大多数现实生活中的产品开发场景中，无论前面你做多少分析，当把第一个发布版本交到真实用户手中时，你都会感到惊讶，并且你的很多假设最终都错得离谱。

所以，没错，要提前做一些分析，在开发前要尽可能发掘客户需求。但不要花太多的时间，也不要太相信分析结果 –取而代之的是要开始开发原型和发布版本，那才是真正的学习时间。

无论如何，回到故事。也许客户想要更多特性。有时他需要去另一个城市，而骑自行车实在太慢和太累。因此下一个迭代，我们增加了一个引擎。

这种模式特别适合于软件，因为软件是…嗯..“软的”，你可以随意“改变”软件产品。相对来说，硬件基本上每次都需要重新构建。然而，即使是在硬件项目，通过提供原型并观察和学习客户如何使用您的产品，仍然能得到巨大的好处。只是迭代会要长一点（一般是几个月而不是几周）。就算是实际的汽车公司，如丰田和特斯拉，在生产一款全新型号的汽车前，也会制作大量的原型

（例如草图，3维模型，同尺寸粘土模型，等等）。

那么现在呢？再次，客户可能会对摩托车感到满意。我们可能会提前结束这个项目。大多数产品都充满了复杂且没用的功能。迭代方法真的是一种能够减少功能的方式，或是一种找到最简单和最便宜的客户问题解决方式的方法。尽量接近完美。很有点禅理。

或者，再次，客户可能会选择继续，以及是否修改需求。事实上，有可能我们最终得到的，是与最初设想的一模一样的汽车。然而，更可能的是，我们在过程中获得了重要的见解，并最终结果会略有不同，比如下面这样的汽车：

客户会感到喜出望外！为什么？因为我们在过程中了解到他喜欢呼吸新鲜空气，所以我们最后做了一个调整。 他最终确实得到了汽车——但却是比原计划更好的汽车！

因此，让我们做个回顾。

什么是你的滑板版本？

上面那个场景（交付一个前轮）太差劲了，因为我们不断交付的是客户根本不能用的东西。如果你了解正在做的东西——你的产品没什么复杂度和风险，或许之前你已经做了几百次同类产品——那么就去做吧，直接上大爆炸方式，构建产品并在完成时交付。

然而，我见过的大多数产品开发工作都极具复杂和风险，而大爆炸方式往往只会导致巨大而昂贵的失败。所以，问题的关键是：“什么是你的滑板版本？”

在产品开发中，你要做的第一件事（在描述完你要为谁解决什么问题之后）就是识别出你的滑板等价物。考虑把滑板作为对最小的、可以交到真实用户手中并获得真实反馈的最小产品的隐喻。或者如果隐喻效果更好，也可以使用“公共汽车票”。

这将给予你急需的反馈环，并让你和客户一起来控制项目-你可以进行学习和作出改变，而非只是一味地遵循计划和希望做到最好的。

让我来看一些现实生活中的例子。

第1个例子：Spotify音乐播放器

“有超过7500万用户，很难让人记得什么时候不用Spotify。但有时会有。当我们琢磨如何才能得到新的CD的时候，当我们在Napster上盗版音乐的时候，当我们被迫在iTunes以2美元每首的价格购买歌曲的时候，来使用Spotify吧。” - Tech Crunch

现在的Spotify是一款极其梦幻的产品 。但它并不是一开始就这样的。我过去很幸运能够很早就参与到这个令人惊叹的历程中（现在仍是）。

Spotify启动于2006年，产品建立在一些关键的假设上——人们更喜欢流式音乐（而非下载到本地），唱片公司和艺术家们都愿意让人们合法地收听流式音乐，并且快速、稳定的流媒体在技术上是可行的。请注意，这是在2006年，听流式音乐（类似于Real Player）的体验仍然非常糟糕的，而对音乐进行盗版复制也几乎是常态。技术上的挑战是：“是否有可能制作这样一个客户端，当你按下播放按钮时，立刻就能播放流音乐？是否有可能摆脱那个可恶的“缓冲”进度条？”。

小起点并不意味着不可以有大抱负。这里是早期他们心目中的一篇草稿：

但开发者们并没有花几年去构建一款完整产品，然后再去确认假设是否仍然成立；而基本上只是坐下来建立一个技术原型，把时间花在任何便携式电脑上播放不流畅的音乐上，开始进行各种试验以找到实现快速而稳定播放的方法。驱动的度量指标是：“从按播放键到听到音乐要消耗多少微秒”。播放应该是非常即时的，并且持续播放应该流畅无停顿。

“当别人不关注的时候，我们却花了巨量的时间来专门处理延时问题；因为我们有着该死的癖好——想让你感觉就像是把全世界所有的音乐都装进了你的硬盘。专注于微小的细节有时候却能够产生巨大的差异。我认为，对最小可行产品概念的最大误解是在MVP的V上”。 - Daniel Ek，联合创始人兼首席执行官

一旦有什么像样的东西，他们就会开始在自己、家庭和朋友中进行体验。

初始版本也不可能发布给更广泛的受众，因为它完全未经打磨，并且除了能够查找和播放少数硬编码音乐外，基本没有什么其他特性，也没有任何合法协议或者经济模式。这就是他们的滑板版本。

但他们厚脸皮地把滑板版本交到了真实用户——朋友和家人们——的手中，并且快速得到了他们需要的答案。是的，在技术上是可行性。并且，是的，人们非常喜欢这个产品（或更喜欢修改后的产品）！假设得到了验证！这种可运行的原型帮助说服了唱片公司和投资人，其他的事情就众所周知了。

第2个例子：Minecraft游戏

Minecraft是在游戏开发史上最成功的游戏之一，如果考虑开发成本就更是如此。Minecraft也是尽早发布和频繁发布理念的最极端例子之一。只经过了一个人的6天编码，就制作和公开发布了第一个版本。第一个版本基本上干不了什么事情——基本上它就是一个丑陋的块状3D景观，你可以把方块挖出来，放在其他地方，去建造粗糙的建筑。

那就是滑板版本。

然而用户却被强烈吸引住了（大部分开发者与用户间的通信都是通过Twitter进行的，相当有趣）。早期的用户中就有我和我的四个孩子。仅在第一年里，就有超过一百个版本被制作和发布。游戏开发至始至终都在寻找玩点（在一些游戏公司，我曾在工作中使用术语“玩点的定义（Definition of Fun）”来替代“完成的定义（Definition of Done）”），而寻找玩点的最好方法就是找真人真地玩游戏–在本案例中，竟然有数千名真人花钱来试玩早期评估版本，因此他们也有动机去帮助改进游戏。

渐渐地，围绕这款游戏，形成了一个小小的开发团队（实际上大多数情况下只有2个人），而这款游戏在全世界则成为了一个大热门。我想我还没碰到过任何不玩Minecraft的孩子。并且去年（译者补充：是2014年11月）这款游戏（嗯，基于这款游戏，成立了一家公司）被微软公司以25亿美元的价格收购。太惊人。

第3个例子：大政府项目

大约2010年，为了能让警察把时间更多的花在现场而非警局，瑞典警方启动了一项重大举措——PUST（polisens utrednings STöD）。这是一个非常吸引人的项目，我作为教练参与，并写了一本关于我们做了什么以及学习到什么的书（《Lean from the Trenches》）。

产品的设计理念是在警车中配置便携式电脑，警察能够通过定制软件实时登录到所需的系统，例如在询问嫌犯的时候（这时候还属于平板电脑以前的时代）

过去他们曾试图建立类似的系统，但都不幸地失败了，主要是因为采用了大爆炸思维。他们告诉我，之前的一次尝试，从开始开发到发布首个版本，一共花了7年时间。七年！到发布的时候，当然什么都变了，所以这个项目彻底失败了。因此这次他们想换种方法来做。

这个60人的项目（后来被称为“PUST Java”）获得了惊人的成功，尤其是这还是一个大政府项目（它甚至在CIO奖项“年度项目”的评选中得到第二名）。这个项目成功的最主要因素之一，就是他们没有试图一次构建整个产品——他们把这个庞然大物从两个维度进行了拆分：

• 通过地区拆分。我们不需要一次发布就覆盖瑞典的所有地区，我们可以从只覆盖一个地区开始。

• 通过犯罪类型拆分。开始我们不需要支持所有的犯罪类型，我们可以从只支持1-2种犯罪类型开始。

第一个版本，1.0，就是他们的滑板版本。

这是一个小系统，只支持几种犯罪类型，由东约特兰省的少数几名警察进行现场体验。其它的犯罪类型处理时，仍然需要采用以往的方式——开车回到警局和做文书工作。他们知道自己在充当小白鼠，也知道产品还没有完成。但他们非常愿意去体验，因为他们清楚替代方案。他们过去也曾见识过那种缺乏早期用户反馈的过程中产出的系统有多么的蹩脚，现在他们终于有机会在构建过程中就对系统施加影响了！

他们的反馈是严厉而又坦诚的。我们抛弃了很多假设，并出现了一个大的窘境——该如何处理那些精心制作的、但是随着真实用户反馈信息的到来而显得越来越没有意义的用例说明书（这是个有着瀑布历史以及习惯做大量的前期分析工作的组织）。

不管怎样，长话短说，早期反馈被用于产品改进，并且东约特兰省的那些警察逐渐开始喜欢上这款产品，我们现在可以添加更多的犯罪类型和扩展到更多的地区。到发布1.4这个大版本的时候，我们已经推广到全国范围并对12000警察进行了培训，而且对此我们毫不担忧。因为我们已经发布了这么多的版本，经过了这么多的用户体验，所以在对全国进行发布的那天晚上，我们都睡得很安稳。

不幸的是，成功是短暂的。可能是由于老的习惯，接下来的项目（PUST Siebel）却回到了瀑布思想，并且搞砸了。下一代产品在没有任何发布和用户体验情况下，在为期2年的分析和测试之后，向12000名警察进行了一次大爆炸发布。这绝对是一场灾难，经过半年的折腾之后，他们关闭了整个项目。开发成本约为2000万欧元，但内部的研究估计，瑞典的社会成本（因为糟糕的系统给警察工作造成了障碍）相当于10亿欧元！

真是极其昂贵的学习方法！

第4个例子：乐高

现在我在乐高工作，我对他们年复一年从不失败地发布新亮点的能力赞赏不已。关于他们如何做到这一点，我听到过很多有趣的故事，共同的主题都是要做原型和早期用户体验！我经常在办公室看到一群群的孩子，设计师与当地的幼儿园、学校和家庭合作，现场体验新产品的设计理念。

这是一个最近的例子– nexo knights （2016年1月发布的）：

当他们第一次开始探索概念的时候，他们制作了纸上原型并交给孩子们。孩子们的第一反应是：“嘿，谁是坏人？我看不出谁好谁坏！”哎呀。因此，设计师们不断迭代，直到他们找到一个对孩子们有用的设计方案。我打赌，甚至连你都能看出上图中谁好谁坏……

在本故事中，无法精确辨别哪个是滑板版本，但是你收获了理念——来自真实用户的早期反馈！不要只进行设计和完整构建产品。想象一下，如果他们只是基于他们最初的设计假设去构建产品，在向全世界的商店发出几千箱货物后才学习到存在什么问题，会有什么的结果！

乐高也曾经历过惨重的失败。乐高宇宙（Lego Universe）就是个例子，这是一款大型的、多玩家的、在线的乐高世界。听起来好玩吧？问题是，他们野心太大了，结果终结于试图在发布前就完美构建出所有事物。

大概有250个人，工作了4-5年（由于完美主义导致了持续的项目范围蔓延）。当最终发布版本时，却遭到了…冷遇。最终完成的游戏很漂亮，但并不如预期的那样好玩，因此2年后这款产品被关闭了。

没有滑板版本！

为什么没有？因为滑板版本不够好（至少当你期望得到汽车时不够好），而乐高的文化完全是追求提供完美的用户体验！如果你在丹麦比隆的乐高总部工作，你每天都会走过下面这幅巨大的壁画：

可以粗略翻译成“只有最好才是足够好”。自从80年前公司成立以来，这一直是乐高的指导方针，并帮助他们成为世界上最成功的公司之一。但在本案例中，这个原则被误用。 对完美的追求耽误了获取至关重要的反馈，这意味着对用户的喜好做错误的假设。而这与Minecraft的工作方法正好相反。

十分有趣的是，乐高宇宙的开发团队其实是在严格地使用Scrum和迭代——与Minecraft团队的做法非常类似。但只进行内部发布，滑板版本、自行车版本等等十之八九是有的，但那些产品从未到达过真实用户。这就不是Scrum所预期的使用方法了。

是一个昂贵的失败，但乐高从中吸取了教训，并在早期体验和用户反馈上越做越好。

对“MVP”的改进

让我们深吸一口气，讨论下MVP（最小可行产品）这个话题。

背后的理念是伟大的，但这个术语本身却会导致很多困惑和焦虑。我见过很多的客户说：“我没办法做MVP交付——那就是我要获得的最终交付。”大多数情况下，团队交付了所谓的MVP后，就快速转向下一个项目，给客户留下一个有问题的、未完成的产品。对某些客户来说，MVP=MRC(Minimum Releasable Crap，最小可发布废物)

我明白，我很清楚，这些问题来自于管理不善而非MVP这个术语，但是…这个术语本身会招致误解。对于“最小”和“可行”，仁者见仁、智者见智，这就带来了问题。

因此，这里换一种说法。

首先，用“早（Early）”替换“最小（Minimum）”。发布MVP背后的整个理念是要获得早期的用户反馈——通过提供一个最小产品而非完整产品，我们才能更早的得到反馈。

很少有客户会想要“最小（minimum）”，但大多数客户都希望“早（early）”！因此，那就是我们的第一个改变：

最小（Minimum）=> 最早（Earliest）

下一步，删除单词“可行（Viable）”，因为这个词太模糊。对你来说是“可行的”，对我来说却是“可怕的”。有些人认为可行（Viable）就意味着“我可以体验和从中得到反馈”，其他一些人则认为可行（Viable）意味着“客户可以实际使用”。因此，让我们更明确地表述，把它分成三个不同的事物（可体验的（testable）/可使用的（usable）/令人喜爱的（lovable））：

最早可体验的产品是滑板版本或者公共汽车票版本——这是第一个客户可以实际用来做事情的发布版本。可能并不能解决他们的问题，但至少能引发某种反馈。我们非常清楚，学习是这个版本的主要目的，获得的任何实际客户价值都是红利。

最早可使用的产品可能是自行车。这是第一个早期用户愿意使用的发布版本。虽然离最终完成还差得远，可能也不讨人喜欢。但它确实让你的客户进入到比以前更有利的位置。

最早令人喜爱的产品可能是摩托车。这是第一个客户喜欢的、会告诉朋友的并且愿意为之买单的发布版本。虽然还是有很多的改进空间，我们仍然可能继续改变，例如变成飞机或别的什么。但我们已经实现了一个真正有销路的产品。

我考虑过增加一个更早的环节“最早可反馈的产品”，这基本上是一个纸面原型之类的东西，你可以用来从客户那里获得第一次反馈。但四个环节看起来太多了，而且“可反馈的”这个术语…嘿嘿。然而，这也是一个重要环节。有些人可能会把纸面原型称为最早可体验的产品，但我认为这取决于你如何定义“可体验的”。看看Martin的 MVP Guide ，可以学到更多——他有大量超级具体的例子说明了如何以最小的投入来获得早期反馈。

当然，人们可能会误解“最早可体验的/可使用的/令人喜爱的”，但这个说法至少比模糊的“最小可行产品”更加明确。

关键点

OK，到总结的时候了。没想到篇幅会这么长，感谢你的坚持！关键点：

• 对于复杂、创新的产品开发，要避免大爆炸交付。你已经知道迭代和增量开发了，但你实际上真是这么做的吗？
• 从识别滑板版本开始——最早可体验的产品。可以志存高远，但要收起你的骄傲，从交付滑板版本开始。
• 避免使用术语MVP。实际谈论的要使用更加具体的语言。最早可体验的/可使用的/令人喜爱的只是一个例子，也可以使用其他任何不会对你的相干关系人造成困惑的术语。

记住–滑板/汽车图只是一个隐喻。别把它当真。:o)

PS——这里有个有趣的故事，是关于我和我的孩子们如何使用这些概念来赢得机器人相扑比赛 。:o)

感谢Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, 以及其他Crisp, Spotify and Lego的同事，以及其他所有提供了很多有用反馈的人。