敏捷遭遇实效营销

实效营销是科技领域的一种产品管理方法论，和那些敏捷软件开发方法相似，它追求价值与原则。所以，当实效营销者遇到了敏捷开发者，会发生什么呢？最近，Stacey Weber 在一篇文章中写道：“文化间的啮合通常是不完美的”。

“严苛”一词是很多公司应用敏捷开发之经验的准确描述，这种方法等于是向快速变化的需求屈服。实际上，我相信正是因为工程师们要处理那些来自执行经理和产品经理的不断变动、又自相矛盾的需求变化，所以产生了敏捷方法。这些工程师与无法决定需求优先级的执行经理一同工作，还有那个忙于想需求而不做市场调研了解真正需求的产品经理……对于工程师来说，敏捷好象就是他们要找的答案，因为他们的团队只关注很少的需求就行啦。他们基本上可以忽略执行经理和产品经理……几个星期后的任何需求变化都可以不管。

先把错误的立论前提先放一边，有一件事是可以肯定的，即敏捷方法并不能解决业务中的根本性问题，尤其是当业务本身不能决定如何做，或无法决定优先级时，敏捷方法根本帮不上忙。Barbara Nelson 和 Stacey Mentzel 在一篇名为《极限项目管理》文章中详细阐述了这一问题。

如果敏捷方法本身可以解决“构建那些大家想要的产品”这一问题的话，那我们就不用写这篇文章了。我们就说“用敏捷吧！”可是，我们一次又一次地听到敏捷方法可以很快交付成果，但如果没有计划和全面蓝图，那所交付的东西（让我们先叫它用户故事吧）可能无法帮助我们卖出更多的软件。

当认识到敏捷方法的这一缺点以后，他们做出下面的反应，即提倡“敏捷瀑布方法”。这一方法实际上是较为强调长期计划的敏捷软件开发方法。一方面，这好象合理且必要的，因为可以让业务人员能够制定长期计划和承诺来销售产品，“有助于创造人们想买的产品”——这是实效营销的口号。然而，业务人员如果过分强调长期计划的话，就不能根据增量开发并实际运行的软件提供的反馈，及时地进行适当调整。毕竟，做产品应该是帮助业务人员更好地理解做什么样的产品，怎么做更好。有点讽刺意味的是，实效营销的应用领域是技术硬件和软件，而真正的技术革新不仅仅是要听市场的呼声；它还要展现市场需要而尚不自知的东西。单凭对营销模拟客户的调查可能发明不出 iPhone 。

然而，实效营销应该还是敏捷方法的倡导者，因为它不但展现了敏捷方法的价值观和原则可以成功地应用在业务方面，而且更重要的是，某种意义上，它还试图说明，在什么情况下敏捷开发实践不起作用。这是为什么呢？我们能做些什么呢？