先用当年亨利·福特老先生的一句话镇一下：如果我当年去问顾客他们想要什么，他们肯定会告诉我：“一匹更快的马”。
现在把这句话放在这，既令人警醒，又有一丝讽刺的意味。但现代生活的节奏，已经不允许我们像福特老先生生活的时代那样，不断制造“成品”来验证。那么在当下的环境中，如果我们遇到了类似的问题，究竟应该培育更快的马，还是应该生产汽车呢？（先留着，后边给出我的答案。）
自从各种创业理念火起来之后，紧跟着各种概念也被炒起来。为了解决这类需求验证的问题，比较著名的方法论当属MVP。比较正式的接触到MVP的概念，是在精益创业的理念中。MVP告诉我们要尽快将“最小可行”的产品推向用户，来验证我们的想法。这种方法有诸多的成功案例，也因此受人追捧，人们开始广泛的讨论如何“做减法”并尽快交付。
不得不说，这样做好处多多。但这也导致的一个负面影响，就是我们开始完全站在需求的角度，随需求变化而变化，却忽略了技术研发本身带有的刚性工作量。这与先前的“功能视角”站在了两个极端：前者是见招拆招、各个击破；后者则是兵来将挡，以一敌百。既然是极端，不论哪种，都会有鲜明的优缺点，令人难以抉择。这不由得让我想起一个题外话：高考报志愿，究竟是报自己喜欢的专业，还是报热门专业呢？
由此可见，MVP不仅是一种产品层面的思维，它需要有架构的基础支持，就像持续交付需要有持续集成来支持。我们既需要从技术的层面做到应用的层面来形成闭环，又需要保证各个环节之间的松耦合，以应对不同的变化。如果缺少了这一点的考虑，特别是对于平台型的产品，将会是致命的缺陷。
换句话说，当面临多样性需求的时候（就平台型的产品），MVP是逻辑上的各个击破，而非逐个处理需求。这与面向终端用户的应用型产品具有很大差别。
举个具体的例子吧：
缺少架构支持的项目进度
当我们从需求出发，能够保证我们现有的需求接近令人满意的程度。但紧接着，更多的需求会接踵而至。由于缺少基础功能的支持，这些新需求的初始完成度就非常低（比如10%），再加上数量庞大，拉低了整体项目的完成度。由此，虽然我们在两个需求上做得出色，却会因为31.25%的整体进度而备受指责。
保证架构支持的项目进度
但如果我们将松耦合的架构作为重点之一，确保模块之间的协议稳定性，并花更多时间，以不一样的模块切分方式来各个击破。虽然我们在每个需求上都没有太多亮点，但却能坐拥51.88%整体进度。并且每个新需求，都能从更高（假设50%）的初始完成度开始。
所以，回到最开始的问题，我们是养马还是做汽车呢？或许，我们应该设计更通用的车身、轮子和传动装置，管它是马还是汽油引擎。
What's more, my 数据思维 is coming soon.
网友评论