一. 敏捷开发变革
敏捷开发、快速迭代，是近十年来软件行业正在发生的巨大变革。正是这些变化，和由此诞生的优秀的工具与方法论，催生了行业的快速发展，诞生了一个个独角兽公司，乃至巨头企业。
但故事并不总是这样美好。身在其中的你我，估计总是能遇到这样的人和这样的事，应该经常能感受到这其中的魔幻、诡异之处：某些说法高大上，做法却山寨风格满满，知其然不知其所以然的家伙；在对外展示时有120分，内部技术自评不到60分的项目...
前些天打得正火热的某两家问答社区中某家的某技术向软文，其中关于最小可行产品和迭代的内容，让我一时思路迸发，不吐不快。
二.故事中的MVP
就先从这张介绍MVP的图片开始吧：
怎样构建一个最小可行产品（How to build a minimum viable product (MVP)）？好了，你有两个选择：
-
先造前轮，再造后轮，再到车骨架，逐步地，你最终会得到一台看上去还不错的汽车。但是，看到零件和汽车上方的客户上帝了没？看到这一个个苦大仇深的表情没？客户上帝也就是在最后来了个满意的笑脸，而公司恐怕是笑都笑不出来了。所以MVP不建议这样（Not like this）
-
那MVP建议怎样呢（Like this）？我们推出了小滑板儿，Bingo！我们又推出了滑板车，Amazing！我们又推出了自行车，Excellent！我们又推出了摩托车，Incredible！我们最终推出了汽车，Fabulous！……客户满意度在这一连串的惊喜中冲破天际。哦买糕的，咱是不是又做成了一笔十亿美金的生意？！
或许真有不少创业者被第二个故事的美好所打动。但是等等，难道你就没发现这故事中的诡异甚至魔幻之处吗？
对比中规中矩的故事一，（让我们暂时忘记客户的苦脸，）我好歹知道这产品的最终目标一步一步是怎么来的，我知道这一二三四步是怎样的依赖和继承的关系，每一步从上一步继承而来，也为下一步打下基础。而故事二呢？你倒是告诉我，这个“能够滚动的代步工具”，从小滑板儿变成四轮机动车，拢共分几步？！
所以故事二的最显著特征，就是完全放弃了对方案可行性的论证，对实施步骤的渐进性的考虑。就像某些小说里会提到的“因果律武器”，毫不讲理地无视了你的推理和分析。就像逻辑上的降维打击，让打算讲点道理的你无从说起。每个步骤都是彻底的改头换面似的革新，客户就像是看魔法表演（魔法师：我们也要讲究基本法，这锅我们不背……）。这难道不就是这故事的诡异、魔幻之处吗？
三.一个将MVP的故事说圆了的尝试
作为一个典型的工程师和技术人员，遇到这种情况我们的内心一定是崩溃的。不幸的是，这种情况恐怕在行业内并不少见。如果我们设定一个“程序员崩溃指数”，上面的这故事显然能得个高分。但是崩溃的次数多了之后，我反而淡定了。自虐性质地，咱们来做个尝试，看看怎么把这第二个故事说圆了。
怎么说圆呢？就是去找到这样一套方案：首先是可行性，即整体上看，方案的所有环节均不存在不可实现之处；其次是可操作性，通过对方案的充分细化，我们能够给出一套清晰的执行任务步骤，并用于进度和风险评估。
那么对于故事二，我们换一个角度，把它从一条线延展为一个平面，并试着给它加上些更为自然的步骤，看看会发生什么变化。
有没有发现故事开始变得更有意思了？
a) 五个阶段而非五个步骤
原先的五种呈先后关系的“代步工具”，变成了五条相对独立的阶段/生产线。我们没法直接把滑板变成汽车，但我们能先尽快向客户提供滑板车，并于此同时开始摩托车乃至汽车的研发。
b) 不同阶段的关系
“代步工具”的生产线复杂程度与其产出的复杂程度正相关，并且几乎总是向着更复杂的方向发展，例如小滑板儿——两步，汽车——四步。不同阶段/生产线的生产步骤可以存在一定程度的共享，例如图二中1.1和2.1的情况。但由于这几个阶段的产品实在太不一样了，所以共享程度有限。在时间上，阶段/生产线可能存在重叠、并行的情况。并行的程度越高，进化的速度越快，但需要的资源必然成倍增长。
嗯……这回故事二看上去没那么魔幻了。但故事已经说圆了吗？没有。
四.新瓶装旧酒的怪象
可能你身边就有这样的一些人，刚看了些书、学了些新名词，就恨不得马上来给所有人布道。技术方面的重灾区，包括但远不限于这些：分布式、敏捷开发、NoSQL、大数据、机器学习……产品方面的多样性会更多，不过有一类典型的模式：拿着手机说“我要做像微信这样的”，对着屏幕说“就做个淘宝那样的店铺”，还有就是读了篇最小可行产品的文章就兴冲冲地打算照着故事二来依葫芦画瓢了。
如果这么说和这么做的是客户这样的需求方，我还能苦笑一下，背地里翻个白眼或是心里吐个槽。可怕的是，你的团队合作伙伴们也这样。在很多概念和方法论上，只学了层皮，却没学到里。拿着新概念的瓶，装上老做法的酒，就这么给大家灌下了：
- 测试框架和集成工具整的稀烂，还在使劲鼓吹持续集成和降低测试人员比重的“敏捷导师”
- 从来都只用GET和POST，却不知道内容协商、HATEOAS为何物的“REST布道师”
- 只有汇报用的PPT和几张竞品截图，就闹着“只差一个程序员”的“金牌产品经理”
若是不幸碰上他们，你的“崩溃指数”很可能会长期居高不下，而这基本上就是悲剧的开始。就比如有人拿着图一来找你谈MVP，你怎么办？嗯，为了不被坑的太惨，让我们由表及里，再深入一下。
这时候我们还是得再分析下图一和图二。
首先，单看图二中最后一个阶段本身，这不就是前面说到的故事一么？也就是说，尽管实施方案和花费代价存在不同，故事一和故事二的最终目标基本是一致的。只是故事二采用了相对复杂，但客户感知更平缓渐进的方案。
接下来，我们在图二中从上到下，观察这五个阶段的最后成果，直接把他们串连起来。发现了没，这不正是图一中所表达的故事二么？也就是说，在图一中，相对于故事一的描述细节程度，故事二的大部分细节被有意或无意地隐藏了。或许作者是为了强化对比，突出重点，但我们必须要认识到，这不是全部的事实。
相对更完整的事实是这样：
-
构建最小可行产品，与其说是一个战术，不如说这更像是一个战略。所以图一从刚开始，就把两种不同性质的东西在做对比，即“构建汽车的战术”和“构建产品的战略”
-
战略讲究宏观方向的正确性，从抽象层面去表达无可厚非。但遗憾的是，图一给大部分人造成一个误会：是故事一还是故事二，这是个选择题。然而实际情况更可能是，为了达到相同的目标，以故事二的方式，你的团队需要做大量的铺垫工作，大幅增加的复杂度和成倍增长的时间、金钱、人力成本。所以MVP甚至更像是个关于资格和门槛的问题
-
既然需要付出如此巨大的代价，为何MVP还要建议故事二呢？至少有这两个原因：a) 客户的满意度和有效反馈的重要性实在是太高了，高到以至于若未能取得客户的早期认可和反馈的情况下，产品和团队将可能不复存在，这是一个生或死的问题；b) 大部分现实情况中，战略的方向和战术的方案不可能从制定完成之后就一成不变，谁也不是未卜先知的预言家。像故事二的情况，可能在做阶段一时，恐怕连阶段二都没那么完整、清晰，而后面阶段四、五，恐怕要过过个几年才会有眉目
能达到这个认识阶段，并以适合自己的方式进行了一定的实践的话，或许你的团队已经甩掉了一大半的竞争对手了。但其实我们的故事还没讲完。
五.产品进化的挑战
随着产品进化得越发成熟，很多时候会围绕着产品产生一个小环境、小生态。很多人都不会意识到这个生态的复杂，甚至是产品相关负责人，也难以一览全貌。还是以故事二为例，我们来看看进化中的产品带来的挑战。
随着研发工作的持续进行，我们获得了一个又一个的阶段性成果。我们陆续发布了多达5款交通工具。于是，在市场上，在这个产品的小生态中，同时存在多种产品子类型。宽阔的双向四车道上，小滑板儿、自行车、汽车各类交通工具穿梭其中，好一幅热闹的景象，但说实话也挺诡异魔幻的。你可能会想，小滑板儿、自行车、汽车这些车速和安全性能差异如此之大的车辆为何要在一个路面上行驶？哎等下，不是说好5款交通工具吗，这异型自行车（3a）和异型机动车（5a）又是个什么情况？
我来试着回答一下。很多的产品和技术几乎不关注产品的小生态问题，因为他们可能根本就没看清这个生态，或是他们认为这并不重要（刻意忽视、不认为需要负责以及考核中不涉及）。至于3a、5a的情况，可能是拍脑门儿的产品死命压缩研发时间，导致发布的半成品；也可能是不靠谱的技术挂羊头卖狗肉，图省事儿糊弄出来的四不像。
不管怎样，产品已经发布了，这些已经成为生态的一部分。好的坏的生态差距巨大，公司也将更大地受到生态质量的影响。而随着产品的进化，维护生态的良好状态将不仅仅是个产品和技术问题，也是个管理和引导问题。坏的生态往往都是由于之前的忽视和不佳的工作欠下的债造成的，因此想要改变，就需要拿出态度和勇气，该改进的改进，该还债的还债。
或许很多人都没意识到所谓的MVP是怎样的一盘大棋，而在实践中的人们，有的可能万全准备、脚踏实地，也有的就是梦做得太多，书读得太少。
因此还请擦亮双眼，冷静思考以及担起责任。这就是不断进化中的软件行业，这就是你我天天经历的魔幻迭代。