瀑布型流程、敏捷型流程和精益型流程，这是业界三种最典型、最流行的产品研发流程。首先和大家介绍一下这三种研发流程的异同。如果单从独立的工作环节上来看它们并无太大的不同，总体来说，要实施完成一个产品或者项目，工作环节都要包括几个大的阶段：产品战略方向研究和产品功能定位、设计原型来将概念设计进行落地、通过UI设计对原型进行包装和细化、按照原型设计&UI设计&交互设计进行开发、最后投入运营，收集用户反馈并不断迭代改进。在一个完整的产品/项目实施过程中，这些步骤都是必不可少的，但如果把这些独立的环节衔接起来，放在团队合作过程中，这三种模式就产生了很大的区别。
瀑布研发流程：在项目开始就从整体上确定好项目的需求和计划，在实施产品之前就做大量的调研和需求文档的撰写，在后面会按照明确的需求和计划进行实施和把握，每个阶段都有明确的分工和界限，每个阶段全部完成、交付了各种产出物和标准文档，并且验收通过之后，才能进入下一步阶段。把每个环节都走完之后，结束了一个完整的流程，才会进行下一个版本的迭代改进，工作流程和上一轮基本相同。
在瀑布流程中，直到整个项目周期的最后一刻，用户才能开始真正使用产品。如果用户体验和预期出现了较大偏差，那么返工迭代的时间是很漫长的，成本也是相当高的。
瀑布流程假定项目需求在早期就可以完全敲定、定稿，然后直到软件开发生命周期的最后一刻也不会再发生变更。在需求明确的前提下，大家在项目运作过程中按照标准规范产出各种文档，按着流程一步步走下去。瀑布开发流程跟传统工业流程是一样的，设定好初始目标，并且由初始目标决定后续一连串的线性流程。这个初始目标实际上被假定为已经得到验证的需求。
但实际上，这个假定很可能并不成立。尤其是在日新月异、充满变革的现代社会。即使验证好的需求，在开发实施即将结束的时候，外在环境可能就已经发生了某些变化。再说即使自己认为验证好的那些需求，实际上可能只是主观想象，和真实的用户需求存在着相当大的鸿沟和差距。
事实告诉我们，对于任何软件类的系统或项目，即使前期花在需求上的时间足够长，我们也很难在需求阶段真正的分析和挖掘出所有的需求。有些需求注定会在设计实现或用户使用过程中才逐渐出现。我们要承认软件开发中存在这种不确定性。而瀑布模型将这种对需求误差的觉察延迟到测试或用户使用阶段才发现，极大的增加了返工或变更成本。
既然如此，为什么还有很多项目中依然在采用瀑布型研发流程？一方面这个企业的组织架构有关，一方面和项目本身的特征有关。有些大规模的传统企业，部门之间缺少便捷高效地沟通机制，本身就需要层层审核、层层验收才能进入到其他部门和环节，在企业组织架构和企业文化未能改变的情况下强行推进敏捷或者精益研发流程，反而可能因为企业缺少这种基因无法适应而适得其反。另一方面，有些项目本身就是面向某个传统的B端企业，用户人数少，而且比较确定都是谁将来会使用，在进行需求调研和分析时得到明确答案的概率也较高。这种情况下，采用瀑布型研发流程在某个时间段内仍然算是相对稳妥的一种合作方式。
敏捷研发流程：在初期就把一个整体项目切分为多个相互联系，但也可独立运行的N个子项目，并分别完成。对每个独立的小项目都会执行一遍从概念设计、原型设计、UI设计、开发实施、测试使用这些完整的环节。
在敏捷流程中，需求分析、产品设计并非只属于第一个阶段，定下来之后后面就再不改动了，而是几乎贯穿始终，一直持续到最后一个子项目完成。这种流程要求先尽快地做点东西出来，然后在实际场景中去修改、弥补需求分析和产品设计环节的不足，快速迭代修改，再次发布新版本。如此循环，直到用户满意。因为要尽快做东西出来，所以很多时候会忽略标准文档的作用，用更加高效简洁地方式进行交流沟通。而且用户会在项目早期就有机会使用产品，表达对产品的使用体会，帮助产品在下个阶段及时进行调整，而不是到最后才发现问题所在。通过短周期迭代，尽可能早的交付可用的迭代版本，使用敏捷流程实施的产品更能拥抱和适应变化。
在现代社会，无论是对于传统巨头，还是对于后起之秀，恰到好处的创新都是决定企业成败的关键。传统巨头如果躺在功劳簿上失去对周边世界的敏锐洞察和持续创新，不知道什么时候就会成为突然倒下的巨人，诸如柯达和诺基亚，都是活生生的例子。后起之秀如果缺少足够的创新，在各个传统领域都人满为患的市场下，很难取得一席之地。
既然要创新，就面临相当大的不确定性，没有人敢说自己的idea是可以成功的创新，我们见到过无数具有新奇想法，甚至是很好的、很有创造力的想法都成为了先烈。对用户的真实痛点把握地不够精准，对用户使用产品的场景把握地不够到位，对周边环境认知不够，市场时机不够成熟，种种因素都会造成一个原本不错的创新想法胎死腹中。
既然【创新】是走向未来的关键要素，而成功的创新又是那么扑朔迷离、难以捉摸，即使世界上最优秀、最聪明的领域专家也无法准确预测和捉摸，人们作为普通创业者，又如何能够在产品实施早期就非常明确的验证想法的正确性呢？对于一个致力于创新产品解决方案的人来说，用户需求是无限的，意味着无限的探索和发掘空间。
大家看一下，微信、QQ、淘宝等一些产品的最初形态，发展到现在它们经历了无数版本的迭代，而且还将无有止境地继续迭代，直到生命周期彻底终止。互联网时代，客户需求原本就变化快速，产品研发永远无法一次性满足客户的所有需求，而是要通过一次又一次的迭代让产品功能逐渐丰满。所以，敏捷产品流程适用于那些需求不明确的项目、创新性的项目。
精益研发流程：虽然它不像敏捷流程那样将项目分割成N个子项目，但提出了MVP（最小可用产品）的概念，做出一个能展示给用户使用，又能突出你的产品和价值的最“小”产品。在早期即通过一个非常小的可用产品，直观的被客户感知，最快提供验收，确定产品功能是否切实满足需求。通过精益流程研发的产品保证每项功能都是基于客户反馈，一切活动围绕真实需求进行，而不是拍脑袋决定的。
MVP（Minimum Viable Product）最早来自于Eric Ries所写的著名创业书籍《精益创业》，这也是精益创业的核心思想之一。Eric写到：“MVP是指是让团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。”
如果客户认可了这个产品，那么你可以继续完善和增加其他功能。如果用户对于这个最小化可用产品都没有兴趣的话，那你可以考虑调整方向和思路。好在，投入还不多，损失也不大。
精益流程和敏捷流程相似的地方在于尽早地让用户参与到产品研发流程中来，提供真实的使用反馈来不断调整产品需求分析和设计思路。两者都体现了一种面向用户的产品设计思维，贯穿着一种非常人性化，以人为本的理念。
两者的不同之处在于着力点有所不同，敏捷流程注重将项目分解成若干可以独立运行的子项目，精益流程则注重将项目浓缩成一个最核心的功能点MVP。一个是阶段性地【分解】目标产品，分解完之后再分阶段完成，每个阶段都可以按照用户反馈进行调整；一个是将目标产品【浓缩】成最核心的功能点，抓住产品的核心和关键，从验证最核心、最关键的功能点着手，也就是要一阵见血、毫不拖拉地验证一个产品最本质的精髓。
另外一点着力点的不同在于：敏捷流程更加注重合作沟通的高效，致力于如何更加高效地做完这个产品。而精益流程则更加注重产品与市场的匹配度，致力于验证是否在做正确地产品。在真实的开发流程中，敏捷流程和精益流程并非矛盾，而是互为补充、相辅相成，共同完成高效地产品实施。
网友评论