前几天在《最好的产品满足的不是需求，而是“要求”》中，我们提到“想尽办法地满足用户的要求，让他们无可救药地爱上你的产品。”文章中对用户的“要求”与“需求”做了区分，很多朋友回复消息说蛮有启发，但我也注意到一些创业者仍有疑问：既然我要想尽办法地满足用户的要求，但是用户的要求无止境，而且差异性也较大，那我怎么办?
我绝不能冒充专家，我只是说说我的看法。
从事软件开发的朋友们可能都知道，软件开发比较普遍的有两种模型，一是瀑布模型，一是敏捷模型。事实上这两种模型背后所呈现的思维逻辑，也是创业过程中所常见的。
瀑布模型把软件开发分成各个阶段，需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等，每个阶段都严格定义了输入和输出，如果达不到输出的要求，则下一个阶段就不展开。系统测试完成后，软件交付给用户，于是整个过程就完成了。
瀑布模型的思维模式是很容易被人接受的模式，感觉理所当然，先了解用户要什么，然后一步一步直到交付为止。这种模式曾经被广泛采用。然而它有它的缺点，最大的问题在于无法及时应变。一个项目短则几个月，长则一两年，用户的要求在这期间很可能发生变化。就像用户要定做一件合体的衣服，你给他量了尺寸，然后闷声不响地做了几个月，结果发现几个月后，用户长胖了，这个时候返工的成本就太大了。
后来就有了敏捷模型。敏捷模型的核心是迭代，最终目标是让客户满意，所以能够主动接受需求变更。它的宣言我比较认同：个体和交互胜过过程和工具，可以工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。尤其是最后一句的”响应变化“，也是我们精益创业的本质。
在敏捷开发过程中，一般两个星期就会出一个版本，每一个版本与上一个版本相比，会增加几个特性，用户的要求如果有变更，可以在最近的一个版本中及时应对。在这种方式下，用户不需要等待几个月后直接看到最终版本，而是可以在过程中不断地参与进来，这对产品满足用户的要求是非常重要的。
还是拿刚才定做衣服做例子，在敏捷开发的思维下，裁缝可能先做一件样衣，布料可能很粗糙，甚至上面划满了标记，然后让你试一试大小，是否合身;过几天后，再让你试一试，这时已经用上了正式的面料，你可能觉得衣领的样式不合适;再过几天后，你又试了一次，这样交互下去，直到你心满意足地拿到了你喜欢的衣服为止。
微信的开发是敏捷模型很好的代表，我们每升级一次版本，就会发现微信的功能有一些变化，语音对讲是在2.0版本中出来的，“摇一摇”功能是在3.0版本出来的，到了5.0版本，又对订阅号做了折叠处理。这种迭代开发的方式，使得它能够及时把握市场的反馈从而做出应对。
用户的要求无止境，所以我们需要借鉴敏捷模型，不断地调整产品，创业的整个生命周期，就是在不断地接受反馈，不断地满足用户的要求。
所以不要去担心用户要求得太多，你要做的，就是一点一点地做起。
我们经常接触到一些创业项目，创业者很容易进入一个误区。他们在一开始就过分完整地规划了产品的所有细节，然后付出了很多的时间和精力把这些细节实现。钱烧了很多，市场的时机也耽误了，结果产品一上市，反应很一般。这就是瀑布型的思维模式，试图完美，想一次性满足用户的所有要求，结果发现现实并不完美的时候，改变已经来不及了。
别妄想一次性满足用户的所有要求，因为即使是用户自己，也不一定知道他的所有要求是什么，更别说用户的要求会随着时间的推移而发生变化。
好吧，很多人可能会问：“那我从哪里开始?”
我的建议是从最为基础的“可用”开始，微信1.0时，也仅有即时通讯、分享照片和更换头像等简单功能。裁缝给客人定做衣服，第一步要保证他们能穿得进去，然后再考虑穿得是否舒服、外观是否漂亮的问题。
说得通俗一些，用户对产品的要求就像人类活着的要求一样。人活着要吃饭，要穿衣，要车子，要房子，要配偶，要看电影，要听音乐，甚至要登陆月球，这么多要求，怎么办?很简单，从解决温饱开始。
在解决“可用”的问题之后，那些让用户“好用”的东西该怎么加上去?我认为这应该去问用户，而不是在办公室里折磨自己。产品和软件一样，也是迭代着向前进步的，上一个版本推放市场后，听一听用户说什么，尤其是说得最多的是什么，然后，你也许就知道你该怎么做了。