MVP：平衡“可行性”和“最小化”

原文作者：Jeremy Bird
译者：付新圆&柴晓燕

“ MVP”或“最小化可行产品”是技术中使用最多，却最难理解的概念之一。

该术语由弗兰克·罗宾逊（Frank Robinson）于2001年提出，如今这个词有很多种解释，但大部分失去了最初的含义。

大家现在似乎都只专注于“最小化”，但忘记了产品的“可行”或“有价值”的部分。

现在大多数技术公司都把MVP定义为一个“可用的最小功能集合”。

但是什么是可用的最小功能集合呢？这样做的目的是什么呢？

弗兰克·罗宾逊（Frank Robinson）清楚地定义了他所说的“ MVP”。

MVP是为您的公司和客户量身定做的产品。它有足够大的规模，能让公司和客户满意的接受，并可以正常销售；但又不至于太大，以至于膨胀到充满风险的程度。—弗兰克·罗宾逊（Frank Robinson）, 2001

换句话说，MVP是一种解决问题的方法，它可以从三个方面提高用户体验：有效性、效率和满意度。

为了最小化风险并且得到最大的投资回报，MVP是精益的。

换句话说，MVP是每次迭代都要交付一个可用的最小功能集合，这个集合的功能可以满足用户的基本需求，虽不完善但至少可用。

Jeff Gothelf和Josh Seidon在他们的书《精益UX》中这样写道：

每个设计都是一个被提议的业务解决方案——一个假设。通过客户反馈，逐步修正产品设计和解决方案，MVP就可以来验证产品是否满足客户的需求。—Jeff Gothelf和Josh Seidon，“精益UX”

大多数公司的问题在于，他们对MVP的理解还只停留在“最小的代价”部分。

只是急于做出一个版本，用来告诉公司上层项目取得了良好的进展。

还有一些公司他们的问题是，完全忽略了客户的体验和反馈。

假设你正在开发一个产品，客户有Frank Robinson、Jeff Gothelf、Josh Seidon，但是他们从来都没有使用和反馈过产品，那就不会有MVP了。

MVP首先着眼于基本的客户需求，快速构建一个可满足客户需要的初步产品原型。

做出最小可用产品，通过销售数字、应用商店评级等形式获得客户反馈后，逐步调整产品战略，尽快达成短期目标。即使它没有任何效益，但满足用户的基本需求，虽不完善但至少可用。

为了避免消耗过多精力和费用得到一个有效的、精益的MVP，基于客户需求进行开发很重要。

滑板&汽车车架

关于MVP这个概念，我最喜欢的总结之一是Henrik Kniberg撰写的《赛车vs滑板》(以下是我的团队成员对原版的改编):

在这个假设的示例中，我们正在改善步行通勤用户的交通状况。

请注意，我们不是从产品功能角度出发达到客户需求，而是把重点放在改善步行交通状况的结果上。

从A到达B滑板的速度比步行快；踏板车吸引了更多人，并且更易于使用；自行车速度很快；摩托车比自行车还要快；汽车更安全，并且可以容纳更多人。

通过以上分析，我们可以迅速地将产品价值传递到用户手中，通过客户的反馈和时间的推移还能不断增加这种价值。

实现一辆汽车传统的产品设计思路是一步一步，从车轮、车轱辘、外壳、动力装置、内部装饰一个流程一个流程做起，同样需要很多时间来完成。

但是在上面的方法中，我们在完成的同时还能为客户提供了更高的价值(因此也提高了效率、效果和满意度)。

这里还要强调的是，从自行车到摩托车是需要一个过程的，无论是制造自行车还是摩托车，都不是一蹴而就的。

通过用户的反馈，你可以用MVP的思想不断的改进、迭代，从而推动获得更好的产品，这就是敏捷和产品进步的意义所在。

即使大家都懂得这个道理，但还是有很多开发人员和领导会因为用户的反馈而感到困惑。

值得再次重复的是：没有什么工作是一蹴而就的，如果想要产品进步，那么它的改善一定离不开你的客户，只有不断的改进、迭代、收集反馈，才能得到更优质的产品。 

如果不是因为从自行车中得到用户的反馈，也许我们永远不会制造出摩托车。

如果我们制造了摩托车后，得到的客户反馈是摩托车已经满足了所有需求，那么我们就不用去造汽车了，防止浪费时间和资源。

MVP和怎么去做MVP

但另一方面，如果我们要做的项目是城市交通呢？

在这种情况下，滑板是否还是MVP吗？当然不是。

但是我看到的许多公司都会犯一个错误，他们只做到了“最小的代价”部分，却忘记了产品的有效性，效率和客户的满意度。

为什么会这样？我观察到，当公司只专注于根据产出衡量成功时，他们就无法预测结果，就会发生这种情况。

在Scrum世界中，大多数开发团队都是在完成所有事务、提高迭代速度和准确估计时间点的基础上进行产出评估的。

当你沿着这个链走下去的时候，就会进入发布时间表会比实际改善用户体验更重要的误区。

快速行动虽然很重要（这就是精益用户体验的意义所在），但是我们应该牢记快速行动的方向：提高效率，有效性和客户满意度。

引导公司专注于成果

那么，在持续产出的敏捷世界中，我们如何将重点转移到结果上呢？

寻找一种让自己的敏捷团队以及利益相关者能够定期与用户沟通的方法。

这种沟通方法可以是远程的，也可以是不定期式的。

一开始需要一些技巧的，甚至需要对潜在客户（而不是实际用户）进行不定期式研究，如果你这样做并找到一种简单的方法汇总结果，与团队其他成员分享学习经验，就会发现你的团队会有很大的转变。

我过去不得不使用了这种方法。我带领的是一支完全不愿意分配时间并拒绝与用户联系的团队，但通过这种方法，我们的用户研究作为竞争优势为公司赢得了数百万美元的交易。

最后一点，不要认为这种变化会在一夜之间发生的，这是一个过程。就像在用户界面中一样，在这个过程中收集用户需求，采访用户（团队成员，利益相关者，业务主管）体验。

了解为什么他们觉得没有时间了，然后想办法让他们知道得到想要的东西的方式。（例如，更快的更新版本）。

当人们认为您试图说服他们改变优先顺序时，他们很难被说服。如果你发现什么对他们来说是重要的，并向他们展示用户研究将如何帮助他们实现他们想要的，事情就会变得容易得多。

另一个有帮助的想法是制定在各个阶段都有成功标准的路线图。你的“MVP”步骤是什么？如何快速地做到这一点，如何进行学习和调整呢？下一步可以看到什么？以这种方式设计组织中的流程更改，能够最大限度地减少挫败感，并随着您的前进而看到递增的结果

总结

随着社会越来越发达，用户的需求越来越高会给开发者很大的压力。

但是，当我们将“最小的努力”和短时间的精力集中在用户反馈和学习上，以提高用户对产品的有效性，效率和满意度时，我们会对开发的产品更有信心，用户会有更好的体验感和购买欲。

如果用户还是不满意，我们就迅速进行调整，以减少失败的损失。