标签（空格分隔）： 翻译
本文原地址：Minimum Viable Product-Lessons for Software Teams
MVP = Minimum Viable Product
译者注： 本文由精益创业一书里提到的最小化可行产品扩展开来，描述了在创业初期应采取MVP，即先交付一个有关键功能的初期版本给客户体验，然后通过获取用户的反馈去完善你的软件产品，避免一开始就埋头开发，结果做出的产品和用户真实需求背道而驰。在这一点上和敏捷原则是相同的。
PS1: MVP方式在比如前端界面等涉及到用户体验方面的模块开发，会更有用。
PS2: 事实上译者所在创业公司也犯过YY用户需求的错误，翻译本文的目的，是希望对后来者能有所提示。当然，这篇短文只是高屋建瓴的讲述了MVP的实施原则，并没有实施的细节，如何操作还需要结合具体的项目和团队情况去展开。
最小化可行产品的概念或者叫MVP是随着Eric Reis的畅销书《精益创业》而流行开来的。他定义如下：
最小化可行产品是新产品的某个版本，它能让团队花费最小的代价从用户那里收集到最多的体验反馈
创业团队有很多失败的原因，其中一个最可能的原因就是做出的产品并不是用户想要的。而到了那个时候，就又太晚了。他们花费了数月甚至数年的时间去打造一个伟大的产品-一个庞大复杂的版本-但不幸的是，市场并不愿意购买。MVP是一种策略，目的就是为了避免出现这样一个场景：研发出的产品客户并不需要。
Eric援引了Zappos的故事。他们没有一开始就朝着大而全的方向把产品打造成一个超酷的网站和呼叫中心。Zappos开始就为了验证一个简单的假设：消费者是否愿意在线买鞋？
他们去本地的鞋店，拍摄照片并放到他们的网站上。如果有人从网站下单买了鞋，他们就去商店里买下鞋然后邮寄给顾客。在这后边没有什么大生意，只有一个网站和一个愿景，他们能获得多得让他们恶心的订单，因为每张订单他们都得手动的去店里购买然后邮寄给用户。而这一切都只是为了验证他们那个伟大的想法。
MVP非常有用，它可以用于检验真实的情况和假想，这与传统的包括线上调查在内的所有市场调查恰恰相反，事实上这些调查经常都会提供完全误导的结果。
软件团队可以从MVP里学到很多东西，并且能运用到打造符合用户需求的产品。当我第一次接触MVP时，我以为是“持续交付”的一种。但实际上两者有很多的不同，而且如何让软件工程师们明白这些概念也不是一个容易的事。 我咨询了一些开发人对于迭代开发的定义，下边是大部分人告诉我的答案：
在迭代开发的模型里，所有的需求都会分开的放到各个不同的版本里....更容易管理的模块。每个模块都会经历需求，设计，实现和测试这几个阶段。一个可运行的软件版本在第一个模块就产生了，正因如此，你在软件周期的早期就会有一个可运行的软件。在随后发布的模块是叠加在之前发布的版本上的。这个过程会一直持续下去直到完成整个系统的开发。
这篇文章甚至还有一幅说明图，讲的是蒙娜丽莎是怎么通过一点点叠加式的画出来的：
（实际上，以上的说法有问题）。问题是“软件周期早期的可运行软件”几乎不可能在实际中出现。模块的开发会占用大量的时间；码农会就技术和方法，各种架构以及数据库展开讨论，这就使得完成构思会花费大量的时间（译者：都怪码农咯？） 。等到软件发布了，客户都转移注意力开始讨论蒙娜丽莎的衣服应该是红色而不应该是深绿色。
传统的方法会使得软件开发流程一定会确保产品被正确的开发，但是MVP回答了一个更大的问题：我们是否在打造恰到好处的产品？虽然敏捷开发确实促使了开发的进步，在敏捷里每一个迭代后的结果都是可以被展示的，但是，MVP就不仅仅是展示了。它是真正的可以发布给用户的的产品。软件团队可以使用敏捷的方式去打造一个MVP，功能递增的做到持续交付。
因为MVP会发布给客户，它就要求必须得到来自各个组织，客户以及其它部门的支持。打造MVP不是一个容易的事。一方面，你想要只发布少数几个重要的功能，但是另一方面，你想要发布一些用户们也许会觉得很有用的功能给他们。你必须找到一个很好的平衡点。
一直等到产品差不多完全准备好了才发布时一个我经常看到的错误。有用的软件开发会按这样的思路进行：软件团队和他们的客户交流得到他们的需求。 他们构思一个产品的大致形态（或者写一篇功能指标文档）并展示给相关人员看。一旦相关人员同意了需求文档和产品的构想，团队就开始着力实现它们。产品会被拆分成许多层或者子系统。即使有持续集成或者持续交付工具，也可能会花费一周时间。最终，当所有事情都准备好了，产品才被发布给了用户。紧接着用户就会开始要求各种改动或是新的功能。这个情况总是会发生的。有赖于团队怎么去落实需求，重头开始工作可能会花费数周甚至数月的时间。我曾经使用SOA开发一个通信产品，也犯过类似的错误。团队遵守迭代，可我们没有在早期就实现一个用户在早期就可以使用并给予反馈的前端。我们使用了敏捷开发，它在数据库层，业务层，通信层和负载均衡方面都做得很好。当产品完成后，我们发布给大客户作为试点，同一周，我接到了从CEO打来的电话，用很谦逊的口吻问能否做一些很不同的功能。事实证明，一旦客户开始使用产品了，他们就一定会改变他们的想法。发布日期已经过去了一到两个月，而我们却不得不重做主要的工作去实现这些改变。
从这个故事里，我们能学到什么？打造一个MVP系统。如果我们有一个MVP系统，也许我就不会反对重构和接受这些改变了。我们做了原型但是原型的用途也是有限的。在我给的这个例子里，产品的目标是去支持人们在移动菜单上发送消息。我们做了原型，并在Balsamiq模拟了菜单，甚至创建了一个简单的HTML页面允许用户在菜单配置上做交互。但是原型机和视频是不足以让用户产生足够兴趣的。客户随便看了看就说所有地方很好（译者：我知道这是人性，可为什么所有的客户都这幅鸟样）。但是一旦在手机上得到了真正的产品，他们就有了创意和新的点子（译者：没错，用户就是这么随性）。如果我重做项目，我的第一件事情就是要做好前端菜单页，使用一个简单的数据库，让整个产品在真机上跑起来并且交付给用户试用。
不久以前，我使用REST做一个后台。一些客户有了不同的需求，而且有大量的未知因素。来自开发早期阶段产品人员的一个最普遍的抱怨就是，发布之后客户总是在改变他们的想法，使得整个产品混乱不堪而且还背上了很多技术债。因此我们会找出最紧急的需求并定义出发布产品的重要节点。发布的产品会比完整版本少一些功能，但是所有的功能都可以运行起来。它不完美也不完整，但是它将将好有所有的功能可以允许客户们去安装使用并提供反馈意见。我们就可以成长并不断的进步。
我在软件工程里所能找到的最贴近MVP标准定义的，是一个叫做“Tracer Bullets"的概念，Andy和Dave在他们的著作The Pragmatic Programmer里第一次使用：
曾经我们承担任务开发一个复杂的客户端-服务器数据库....服务器有一系列相关和特殊的数据库。客户端的界面，是用Pascal写的，服务器使用了一些用C库写的接口...这里面存在很多未知的不同的环境，没人肯定界面应该长成什么样子。
这是一个很好的机会去使用追踪代码。我们为前端开发了框架，查询库，以及可以把已保存的查询转换成指定的数据库查询。然后我们把所有的组件都放到一起并检验它是否能正常工作。在最开始的版本里，所有我们能做的就是提交一次查询就能列举出表里所有行，但它就证明了UI和我们所写的库是打通了的。在接下来的几个月里，我们一步步的完善这个基础架构，增加有新功能。
因此，当你要去开发一个有很多未知因素的新项目时，建立MVP流程-或者使用Tracer Bullets。确保你做得事情是正确的。下面这幅图你可能看过一千遍了，但是它确实是MVP流程想要去避免的：
Notes
John Mayo-Smith展示了两种打造金字塔的方法：
1 一层一层的建立
2 一开始的时候打造一个较小的金字塔并保持让他不断的完善。交付一个搭载了所有重大功能的“更小的产品”，让客户能实际的用起来，并让客户反馈意见给你。
