|
在这种情况下，只有在产品真正的卖给客户之后，我们的初创公司才能获得客户来的有实际意义的反馈。而事实往往更悲催的是，在你的产品经历了几个月甚至几年的闭门造车的开发过程之后，你最终却发现客户根本就不会付钱买你的产品，因为他们可能压根就不需要你的产品所提供的大部分功能！ 瀑布开发模式下，一个产品往往需要经历三个版本才能真正走向正轨满足客户的需求。第一个版本毫无疑问是个闭门造车的产物了，根本没有用户反馈可言，所以就更谈不上满足客户需求了。而第二个版本的开发往往又是在第一个版本还没有完全获得用户大量反馈之前，就已经密锣紧鼓的开始的了。所以，我们往往只能在第三个版本中才能真正基于用户的反馈进行产品的打造（其中微软的Windows3。0这个产品的开发过程就是一个很典型的例子）。 到了2000年初，敏捷开发逐渐成为软件开发的最佳实践方式。这种方法通过引入迭代和邀请用户参与的方式来对陈旧的瀑布开发模式进行大幅的改进。这其实已经是一个很大的进步，但问题是它没有一个行之有效的框架来指导我们如何在市场上验证那些商品化方面的猜想。所以在这种情况下在你的产品开发过程中盲目的运用敏捷开发的话，就算你将一个客户所要求的所有功能都实现了，你的产品也难免会碰上滑铁卢而最终铩羽而归。 这时，精益创业所提倡的“打造-衡量-学习”这个框架模型就应运而生了！ 一波未平一波又起 “打造-衡量-学习”关于这个“打造-衡量-学习”的循环，首先我们必须明白这个循环的目的并不是要去让我们打造出一件最终的产品或者产品原型，而是为了让我们在不停的迭代和增量开发的工程中最大化我们对要打造的产品的学习。（这里的学习包括产品功能，客户需求，产品定价以及销售渠道等等…）而“打造”指的当然就是就是去打造出一个MVP（最小可行化产品）了。这里并不是说你只去实现你的产品的一小部分功能就叫做MVP了，明白这一点是非常重要的。事实上，MVP指的应该是一个可以让你快速给客户演示并快速获得用户的反馈以进行学习的那么一个最简单可行的东东。 在创业早期，MVP可以仅仅是几张PPT幻灯片，也可以是一幅线框图，更可以是一个模型，甚至可以只是一些采样数据而已。在你每次进行一个MVP的打造之前，你都需要先去定义好在该MVP中你所需要测试/衡量的究竟是什么东西，然后你才能有针对性的对你的产品、市场和客户等进行学习和认知。随着这方面知识的积累，你的MVP慢慢自然而然的就会往用户真正需要的产品这个目标靠拢。但此时可别得意忘形了，在往下的迭代周期中，你的目标依然是为了继续最大化你的学习，而不是去给你的最终产品打造个产品原型或者Beta版本。相对瀑布模型来说，“打造-衡量-学习”模型令创业变得更为简单，灵活而且有效率。 （责任编辑：职场达人） |
