了解MVP（最小可行产品） - 以及为什么我更喜欢最早的可测试/可用/可爱

几年前，我画了这张照片并开始在关于敏捷和精益开发的各种演示中使用它：

从那时起，绘画已经病毒化！在文章和演示文稿中，甚至在一本书中都可以显示出来（Jeff Patton的“ 用户故事映射 ” - 顺便说一句，这是一本非常好的读物）。许多人告诉我，绘图确实抓住了迭代和增量开发，精益创业，MVP（最小可行产品）以及不是什么的本质。然而，有些人误解了它，当你从它的原始背景中拍出照片时这是很自然的。有人批评它过于简单化，这是事实。图片是一个比喻。它不是关于实际的汽车开发，而是关于产品开发，使用汽车作为隐喻。

无论如何，有了这些嗡嗡声，我认为是时候解释它背后的想法了。

 

第一个例子 - 不喜欢这个

第一行说明了关于迭代，增量产品开发（又称敏捷）的常见误解。

许多项目都失败了，因为他们做Big Bang交付（直到100％完成并最终交付）。由于这个原因，我已经失去了我见过的失败项目的数量（向下滚动一些例子）。然而，当敏捷被作为替代品出现时，人们有时会不愿意提供未完成的产品 - 谁想要一半  的汽车？想象一下：

“先生，这是我们的第一次迭代，前轮胎。你怎么看？”

顾客就像“你为什么要给我送轮胎？我点了一辆车！我该怎么办呢？“

（顺便说一句，我在这里使用术语“客户”作为通用术语来表示产品经理，产品所有者和早期采用者用户）。

随着每次交付，产品接近完成，但客户仍然生气，因为他实际上无法使用该产品。它仍然只是一部分汽车。

最后，当产品完成后，客户就像“谢谢！最后！你为什么不首先提供这个，并跳过所有其他无用的交付？“

在这个例子中，他对最终产品感到满意，因为这是他订购的产品。实际上，这通常不是真的。在没有任何实际用户测试的情况下，很多时间已经过去，因此基于对人们需要的错误假设，产品很可能充满设计缺陷。因此，最后的笑脸非常理想化。

无论如何，第一行代表“卑鄙的敏捷”。从技术上讲，它可能是增量和迭代交付，但缺乏实际的反馈循环使其风险很大 - 而且绝对不敏捷。

因此，“不喜欢这个”标题。

第二个例子 - 像这样！

现在是第二排。

这里我们采取一种非常不同的方法。我们从相同的背景开始 - 客户订购了一辆汽车。但这次我们不只是制造一辆汽车。相反，我们专注于客户想要实现的基本需求。事实证明，他的潜在需求是“我需要更快地从A到B”，而Car只是一种可能的解决方案。记住，汽车只是一个比喻，想想任何一种定制的产品开发情况。

因此，团队提供他们能想到的最小的东西，让客户测试事物并给我们反馈。有些人可能称之为MVP（最小可行产品），但我更喜欢将其称为最早的可测试产品（更多关于此问题）。

称之为你喜欢的东西（有些人甚至称他们的第一个版本是产品的“滑板版”，基于这个比喻.......）。

客户不太可能对此感到满意。这远不及他订购的汽车。但那没关系！这是踢球者 - 我们现在并没有试图让客户满意。我们可能会让一些早期采用者感到高兴（或者是痛苦的实用主义者），但我们在这一点上的主要目标只是学习。理想情况下，团队会提前向客户清楚地解释这一点，所以他不会太失望。

然而，与第一种情况下的前轮相反，滑板实际上是一种可用的产品，可以帮助客户从A到B.但不是很好，但比没有任何东西好一点。所以我们告诉客户“不要担心，项目没有完成，这只是许多迭代中的第一个。我们仍然打算建造一辆汽车，但在此期间请尝试这个并给我们反馈 “。想想大，但以功能上可行的增量递送。

我们可能会学到一些令人惊讶的事情。假设顾客说他讨厌滑板，我们问为什么，他说“我讨厌这种颜色”。我们就像“呃...... 颜色？就这样？”。客户说：“是的，把它弄成蓝色！除此之外，没关系！“ 你刚刚节省了*很多没有建造汽车的钱！不太可能，但谁知道呢？

关键问题是“ 我们可以开始学习的最便宜和最快的方式是什么？“我们能提供比滑板更早的东西吗？公交车票怎么样？

这有助于解决客户的问题吗？也许，也许不是，但我们肯定会通过把它交到真实用户手中来学到一些东西。精益创业提供了一个很好的模型，基于列出您对用户的实际假设，然后系统地工作以验证或使它们无效。

您不需要在所有用户上测试产品，也不需要构建产品来测试某些东西。甚至在单个用户上测试原型也会教会你什么。

但好的，回到滑板的例子。

在办公室里玩弄它后，客户说：“好，很有趣，它确实让我更快地进入咖啡机。但它不稳定。我太容易掉下来“。

因此，下一次迭代我们会尝试解决这个问题，或者至少了解一下这个问题。

客户现在可以绕过办公室而不会掉下来！

快乐？不是真的，他仍然想要那辆车。但与此同时他实际上正在使用这个产品，并给我们反馈。他最大的抱怨是，由于车轮小而且没有休息，很难长途跋涉，比如建筑物之间。因此，下一次发布时，产品会像自行车一样变形。

现在，客户可以放大校园。Yiihaaa！

我们沿途学到了一些东西：顾客喜欢脸上清新的空气。客户在校园内，交通主要是在建筑物之间绕行。

自行车可能比最初设想的汽车要好得多。事实上，在测试这款产品的过程中，我们可能会发现道路对于汽车来说太窄了。我们只是节省了大量的时间和金钱，并在更短的时间内给了他更好的产品！

现在你可能在想“但我们不应该已经知道了。” 通过对客户背景和需求的前期分析？“好点。但是在我见过的大多数现实生活中的产品开发场景中，无论您做了多少前期分析，当您将第一个真正版本交给真实用户并且您的许多假设时，您仍会感到惊讶结果是离开了。

所以，是的，做一些前期分析，在开始开发之前尽可能多地发现。但是不要花太多时间在它上面并且不要过多地信任分析 - 开始原型设计和发布，而是真正的学习发生的时候。

无论如何，回到故事。也许客户想要更多。有时他需要前往另一个城市，骑自行车太慢而且出汗。所以下一次迭代我们添加一个引擎。

 

这种模型特别适用于软件，因为软件很好。您可以随意“变形”产品，而不是每次都必须重建的硬件。但是，即使在硬件项目中，提供原型以观察和了解客户如何使用您的产品也会带来巨大的好处。只是迭代往往会更长（几个月而不是几周）。即使像丰田和特斯拉这样的实际汽车公司在开发新车型之前也做了大量的原型设计（草图，3D模型，全尺寸粘土模型等）。

那么现在怎么办？也许，客户对摩托车很满意。我们可以比计划更早结束项目。大多数产品都充斥着无人使用的复杂性和功能。迭代方法实际上是一种减少交付的方法，或者找到解决客户问题的最简单，最便宜的方法。尽量减少与Awesome的距离。很禅。

或者，客户可以选择继续，无论是否修改要求。事实上，我们最终可能会得到与最初设想的完全相同的汽车。然而，我们更有可能在此过程中获得重要的见解，并最终得到一些略有不同的东西。像这样：

客户喜出望外！为什么？因为我们沿途了解到他欣赏脸上的新鲜空气，所以我们最终得到了一辆敞篷车。毕竟他确实得到了一辆车 - 但是比原计划的车更好！

让我们退一步吧。

你的滑板是什么？

最重要的情况（提供前轮胎）很糟糕，因为我们不断提供客户根本无法使用的东西。如果你知道自己在做什么 - 你的产品很少有复杂性和风险，也许你之前已经建造了数百次这样的东西 - 然后继续前进，只做大爆炸。构建完成并在完成后交付它。

然而，我所看到的大多数产品开发工作都过于复杂且风险太大，而大爆炸方法往往导致巨大的昂贵故障。所以关键问题是你的滑板是  什么？

在产品开发中，您应该做的第一件事（在描述您要为谁解决的问题之后）就是识别您的滑板等效物。把滑板想象成你可以放在真实用户手中的最小东西的隐喻，并获得真实的反馈。如果这个比喻效果更好，可以使用“公交车票”。

这将为您提供急需的反馈循环，并为您和客户提供对项目的控制 - 您可以学习和进行更改，而不是仅仅遵循计划并希望获得最佳。

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

示例1：Spotify音乐播放器

“拥有超过7500万用户，很难记住没有Spotify的时间。但是有。我们都在为新CD考虑Target的过道。在我们生活中的一段时间里，我们都成了Napster的小偷。iTunes强迫我们以2美元/片的价格购买歌曲。然后是Spotify。“ - Tech Crunch

Spotify现在是一款非常精美的产品。但它没有那样开始。我很幸运能够在这个惊人的旅程中很早就参与进来（现在还是）。

作为2006年的创业公司，Spotify建立在一些关键假设的基础上 - 人们乐于流式传输（而不是拥有）音乐，标签和艺术家愿意让人们合法地这样做，而且快速稳定的流媒体在技术上是可行的。请记住，这是2006年音乐流媒体（如Real Player）非常可怕的体验，而海盗复制的音乐几乎是常态。挑战的技术部分是：“当你点击播放按钮时，甚至可以让客户端立即播放音乐？是否有可能摆脱那个讨厌的'缓冲'进度条？“

从小开始并不意味着你不能想大。这是他们想到的早期草图之一：

但是，与其花费数年时间构建整个产品，然后查明假设是否成立，开发人员基本上坐下来，破解技术原型，放入他们在笔记本电脑上的任何翻录音乐，并开始疯狂地尝试寻找方法使播放快速稳定。驱动指标是“从播放Play到听到音乐时需要多少毫秒？”。它应该立即发挥，并继续顺利播放，没有任何口吃！

“当没有人关心时，我们花了很多时间专注于延迟，因为我们一心想让你觉得你的硬盘驱动器上有全世界的音乐。对小细节的迷恋有时会产生重大影响。这就是我认为对最小可行产品概念的最大误解。这就是MVP中的V.“ -Daniel Ek，联合创始人兼首席执行官

一旦他们有了一些体面的东西，他们就开始测试自己，他们的家人和朋友。

初始版本无法向更广泛的受众发布，它完全没有被删除，除了能够找到和播放一些硬编码的歌曲之外基本上没有任何功能，并且没有法律协议或经济模式。这是他们的滑板。

但他们无耻地将滑板交给了真正的用户 - 朋友和家人 - 他们很快得到了他们需要的答案。是的，这在技术上是可行的。是的，人们非常喜欢这种产品（或更像是产品可以成为什么样的产品）！该假说进行了验证！这个运行原型帮助说服音乐品牌和投资者，其余的是历史。

例2：我的世界

Minecraft是游戏开发史上最成功的游戏之一，特别是考虑到开发成本。“我的世界”也是发布的最极端的例子之一 - 早期和经常的心态。第一次公开发布是在经过6天的编码后，由一个人制作的！你在第一个版本中做不了多少 - 它基本上是一个丑陋的块状三维景观，你可以挖掘块并将它们放置在其他地方以构建原始结构。

那是滑板。

虽然用户超级参与（大多数开发者 - 用户通过Twitter发生，非常有趣）。早期用户中有我和我的四个孩子。  第一年就发布了一百多个版本。游戏开发就是为了找到乐趣（我曾经使用的一些游戏公司使用“乐趣的定义”而不是“完成的定义”），最好的方法是让真实的人真正玩这个游戏 - 在这种情况下，成千上万真正付钱尝试早期访问版本的人，因此有个人激励来帮助改进游戏。

渐渐地，围绕游戏形成了一个小型开发团队（实际上大多是2个人），这个游戏在全世界都成了热门话题。我不认为我在任何不玩Minecraft的地方遇到过任何孩子。去年，游戏（以及围绕游戏形成的公司）以25亿美元的价格卖给了微软。太棒了。

例3：大政府项目

2010年左右，瑞典警方启动了一项重大举措，使警方能够在现场花费更多时间，减少在车站的时间--PUST（PolisensUtredningsSTöd）。这是一个引人入胜的项目，我作为教练参与其中，写了一本关于我们做了什么以及我们学到了什么的书（来自战壕的精益）。

 

其想法是将笔记本电脑放入汽车，并通过定制软件让警察实时访问他们所需的系统，例如在询问嫌疑人时（这是片剂前期）。

他们过去曾试图建立类似的系统并且惨遭失败，这主要是因为大爆炸的想法。他们告诉我，他们之前的一次尝试从开始到首次发布需要7年时间。7年！到那时，一切都发生了变化，项目完全失败了。所以这次他们想要以不同的方式做到这一点。

这个60人的项目（后来被称为“PUST Java”）取得了令人惊讶的成功，尤其是作为一个大型政府项目（它甚至在CIO奖项“ 年度最佳项目 ”中排名第二）。其中一个主要的成功因素是他们没有尝试同时建造整个东西 - 他们将大象分成两个方面：

• 按地区划分。我们不需要立即向瑞典所有国家发布，我们可以从发布到一个地区开始。
• 按犯罪类型。我们最初不需要支持所有犯罪类型，我们可以从支持1-2种犯罪类型开始。

 

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

这是一个小型系统，只支持几种犯罪类型，并且在Östergötland（瑞典一个地区）的少数警察进行了实地测试。其他犯罪类型必须以旧方式处理 - 开车到车站并做文书工作。他们知道他们是豚鼠，并且产品远未完成。但他们很乐意测试它，因为他们知道替代方案。他们已经看到了什么样的糟糕系统来自缺乏早期用户反馈的流程，现在他们  终于有机会在系统构建时影响系统！

他们的反馈是严厉和诚实的。我们的许多假设都飞离窗外，其中一个困境就是如何处理所有精心设计的用例规范，这些规范随着真实的用户反馈而变得越来越不相关（这是一个拥有瀑布历史的组织）和做大前期分析的习惯）。

无论如何，长话短说，早期的反馈被引导到产品改进中，逐渐地，随着Östergötland的那些警察开始喜欢产品，我们可以添加更多的犯罪类型并将其传播到更多地区。当我们进入大发布（1.4）时，在全国范围内推出并培训了12000名警察，我们并不那么担心。我们做了这么多的发布，如此多的用户测试，我们在全国发布之夜睡得很好。

不幸的是，胜利是短暂的。后续项目（PUST Siebel）对它进行了拙劣的研究并回到了瀑布式的思考，这可能是由于旧习惯造成的。在没有任何发布或用户测试的情况下进行了2年的分析和测试，随后向所有12,000名警察同时发布了“下一代”产品。这是一场绝对的灾难，经过半年的出血，他们把整个事情关闭了。开发成本约为2000万欧元，但内部研究估计瑞典社会的成本（因为警察被可怕的系统所困扰）大约10亿欧元！

相当昂贵的学习方式！

例4：乐高

我目前正在Lego工作，我很惊讶他们年复一年地提供新的粉碎技能的能力。我听到很多关于他们如何做到这一点的有趣故事，共同的主题是原型设计和早期用户测试！我经常在办公室看到一群孩子，设计师与当地的幼儿园，学校和家庭合作，对最新的产品创意进行现场测试。

这是最近的一个例子 - Nexo Knights（2016年1月发布）：

当他们第一次开始探索这个概念时，他们做了纸质原型并带给了小孩子。孩子们的第一反应是“嘿，谁是坏人？我看不出谁是好人，谁不好！“ 哎呀。因此，设计师不断进行迭代和测试，直到找到适合孩子的设计。我敢打赌，即使你可以看到上图中谁是好人，谁是邪恶者......

不确定滑板在这个故事的确切位置，但你明白了 - 来自真实用户的早期反馈！不要只是设计产品并构建整个产品。想象一下，如果他们根据他们最初的设计假设构建了产品，并 在向世界各地的商店提供数千个盒子之后了解了这个问题！

乐高也有一些来之不易的失败。一个例子是  乐高宇宙，一个大型多人在线乐高世界。听起来很有趣吧？问题是，他们过于雄心勃勃，最终试图在向世界释放之前将整个事物构建完美。

大约250人工作了4 - 5年（由于完美主义导致范围不断变化），当发布终于到来时，接待是......不冷不热。完成的游戏很漂亮，但没有预期的那么有趣，因此产品在2年后关闭。

没有滑板！

为什么不？因为滑板不是很棒（至少不是你想要一辆车），乐高的文化就是提供令人敬畏的体验！如果你在丹麦比隆的乐高总部工作，你每天都会走过这幅巨大的壁画：

大致翻译为“只有最好的就足够了”。自公司成立80多年以来，它一直是乐高的指导原则，并帮助他们成为世界上最成功的公司之一。但在这种情况下，原则被误用了。在 完美狩猎延迟重要的反馈意见，这意味着什么等，并且用户不喜欢错误的假设。与Minecraft完全相反。

有趣的是，Lego Universe团队实际上正在使用Scrum并进行大量迭代 - 就像Minecraft的人一样。但这些版本只是内部版本。所以很可能是滑板，自行车等，但这些产品从未达到过真正的用户。这不是Scrum的用途。

这是一个昂贵的失败，但乐高从中吸取了教训，他们在早期测试和用户反馈方面不断变得更好。

改善“MVP”

而那（深呼吸......）让我想到了MVP的主题 - 最小可行产品。

潜在的想法是伟大的，但这个术语本身会引起很多混乱和焦虑。我遇到过许多客户，他们就像“我不想要MVP交付 - 这是我最后一次交付！”团队经常会提供所谓的最小可行产品，然后很快就会被送到下一个项目，让客户留下一辆未完成的未完成产品。对于一些客户，MVP = MRC（最小可释放垃圾）。

我知道，我知道，这归结于管理不善而不是MVP这个词，但仍然......这个词会引起误解。“最小”和“可行”对不同的人意味着不同的东西，这会导致问题。

所以这是另一种选择。

首先，将“Minimum”替换为“Early”。发布MVP背后的整个想法是获得早期反馈 - 通过提供最低限度的产品而不是完整的产品，我们可以更早地获得反馈。

很少有客户想要“最低限度”，但大多数客户都想要“早”！这是我们的第一个改变：

最小=>最早

接下来，删除“Viable”这个词，因为它太模糊了。你的“可行”是我的“可怕”。有些人认为Viable意味着“我可以测试并获得反馈的东西”，其他人认为它意味着“客户可以实际使用的东西”。所以让我们更明确一点，把它分成三个不同的东西：

 

 

最早的可测试产品  是滑板或公交车票 - 客户可以实际使用的第一个版本。可能无法解决他们的问题，但它至少会产生某种反馈。我们非常清楚地表明，学习是本次发布的主要目的，任何实际的客户价值都将是奖励。

 

最早的可用产品  也许就是自行车。早期采用者实际使用的第一个版本，心甘情愿。它还远没有完成，它可能不太可爱。但它确实让您的客户处于比以前更好的位置。

 

最早的可爱产品  也许就是摩托车。客户喜欢的第一个版本，告诉他们的朋友，并愿意付钱。还有很多需要改进的地方，我们最终可能会使用敞篷车，飞机或其他东西。但是我们已经达到了一个真正有市场的产品。

我考虑过添加一个更早的步骤“ 最早的可反馈产品 ”，它基本上是用于从客户那里获得第一反馈的纸质原型或等效产品。但是四个步骤看起来太多了，反馈这个词......呃。但尽管如此，这也是重要的一步。有些人会将纸质原型称为最早的可测试产品，但我想这取决于您如何定义Testable。查看Martin的MVP指南以了解更多信息 - 他有很多超级具体的例子，说明如何以最少的投资获得早期反馈。

当然，人们仍然会误解最早的可测试/可用/可爱，但它至少比模糊的最小可行产品更明确一步。

外卖点

好的时候把它包起来。从来没有想过会这么久，感谢你坚持下去！关键要点：

• 避免Big Bang  交付复杂，创新的产品开发。迭代地和递增地做它。你已经知道了。但你真的在做吗？
• 首先要确定你的滑板  - 最早的可测试产品。瞄准云，但吞下你的骄傲，开始提供滑板。
• 避免使用术语MVP。更明确你实际谈论的内容。最早的可测试/可用/可爱只是一个例子，使用对您的利益相关者来说最不容易的任何条款。

请记住 - 滑板/汽车绘图只是一个比喻。不要太字面意思：o）

PS - 这是一个有趣的故事，关于我的孩子和我如何使用这些原则来赢得机器人相扑比赛  ：o）

 

原文链接：https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp