浅谈产品推进过程中的“敏捷式开拓与瀑布流开拓”

一. 敏捷式开拓的限定

目前已经有不少产品团体通过以“敏捷式开拓”的办法去管理与完本钱身的产品，只管在我看来“敏捷式开拓”有诸多优点，但是我们始终要服膺敏捷式开拓的源头是定制软件做事，最早的敏捷开拓出身于1986年的日本；

所有流程的初衷也并非完备适用于用户产品软件开拓，如果初创团队决定利用一套完全的敏捷式开拓流程来完本钱身产品的话，这个团队需有明确理解作甚敏捷开拓的职员；如若没有，那么全体团队将面临一些空前的磨难，只有经历不断忍过这些阵痛才能体会到“敏捷式开拓”所带来的上风。

本本文仅列出须要敏捷开拓过程中所把稳的事变，如果大家想与我一起理解后续，会另开文章详细先容如何组建一个真正的敏捷开拓团队，详细的敏捷开拓过程也须要根据公司的实际情形进行调度。

二. 在敏捷开拓过程中的把稳事变

我将其归类为8点：

1. 产品经理便是项目卖力人

在敏捷开拓过程中产品须要做好代表全体用户需求的浸染，须要与开拓团队保持密切沟通，及时办理开拓过程中的问题，如果有些产品经理认为采取敏捷开拓可以使事情变得更加轻松，那么就大错特错了。
实在如果产品经理与项目卖力人不是同一个人，常日会使全体产品留下非常严重的隐患，产品在全体敏捷开拓过程中必须始终都假如第一任务人；

2. 利用敏捷办法不即是不做产品方案

利用敏捷开拓的过程中产品仍须要明确定义全体产品的方向和目标，设定产品里程碑，只不过在敏捷迭代过程中所有的里程碑可以尽可能缩短其周期，通过利用反复迭代与轻量级的机会评估方法代替冗长的市场机会文档等纸面材料；

3. 产品经理与设计师的事情应领先团队1-2两个版本以上

为了确保在项目推进过程中有足够的韶光占领技能上的难题，须要让产品与交互设计和视觉设计师提前完成产品设计，充分发挥三者在产品设计过程中的主导浸染，同时担保开拓职员在产品设计与交互设计阶段始终处于参与状态及时反馈关于产品的可行性、本钱与办理方案的建议在问题的出发点就将其办理；

4. 只管即便把产品设计拆分成独立的部分

虽然将产品拆分成多个模块，但是也不能将其拆分的过于细碎，好比建造一座屋子，你不能每次只建造一件屋子，目标是设计出符合所有基本需求的产品，在这一过程中哀求设计师需有更快的相应速率，去做经由市场验证后的调度；

5. 产品紧张的事情是定义有代价、可用的产品原型作为产品根本

在敏捷开拓过程中产品更须要把稳，每次交付到技能同学手里的原型是经由测试与目标用户验证的，避免摧残浪费蹂躏任何资源，哪怕是一个开拓迭代周期；

6. 让开发职员自主掌握所有迭代周期

有的产品功能可以在一个迭代周期内完成，而有些需求确须要多个版本的迭代才能完成，而这些迭代周期该当尽可能的让技能同学去方案，产品只需把控终极的判断是否与方案相符合；

7. 除非达到预定目标否则绝不轻易发版

产品经理必须担保给到用户手中的产品是正常符合预期的，过度而过度频繁的更迭会让用户失落去安全感，以是没有达到产品预期里程碑与阶段预期时绝不可妥协上线；

8. 每次迭代之后需向全体团队展示下个版本的需求设计与上个版本的数据回归

让大家看到事情成果可以极大的加深全体团队的信心，在敏捷开拓过程中每一个产品即是一个小团队的领袖，产品经理须要让这个团队有更加积极的状态。

三. 瀑布式开拓

传统瀑布式开拓，至今为止该当已经有不少于30年的历史，瀑布式开拓流程也分为正式流程与非正式流程，正式的瀑布式开拓流程可以追溯到美国国防部软件开拓标准2176A及后续改动的498，在网上有详细的阐述每一个阶段所须要供应的必要性文档，本文想解释重点在于非正式流程，也便是我们很多公司的开拓流程；

非正式瀑布流程，也是目前很多互联网公司依旧在利用的方法：由市场/运营进行需求网络，交由产品对需求进行产出文档，统一进行研发和设计评审，评审之后由开拓制制订开拓操持、设计软件架构，由设计进行交互与视觉设计等细节设计，末了正式进入开拓、测试与支配上线。

四. 瀑布开拓的利害

瀑布式开始是目前大多数团队仍旧在利用的一套开拓流程，虽然无论是开拓还是产品同学都对其十分的不满，但其仍能在不断拥抱变革的互联网公司被推崇利用必定有其上风。
以是在谈论瀑布式开拓的局限性前，我们须要先聊下瀑布式开拓的基本准则与上风

瀑布式开拓的基本原则：

采取阶段式开拓，即软件开拓过程等分为固定几个阶段：完成需求文档、设计软件架构、完成交互细节、编写代码、测试、支配；采取阶段式评审，每个阶段结束由上到下进行相应的评审，评审通过后进入下一阶段。

瀑布式开拓的上风：

（1）对付管理层而言有可预测性，在理论上只要在产品评审阶段前将所有产品细节确认并完善，且不再变动需求，那开拓团队就可以为超大型及繁芜项目制订相应的开拓操持，虽然不进行需求变更这种情形很少见，但是并非不能做到，相反迭代性开拓的迭代次数无法预估，很难让管理者做到心中有数；

（2）在瀑布式开拓过程中每个阶段都会由对应的卖力职员供应相对完善翔实的文档及其他书面材料，这会让项目在开拓过程中给人一种觉得，这些项目都经由了所有人的寻思熟虑才会进行的相应推进，但是问题在于利用书面材料当作稳定剂多少都会有些靠不住，由于他并不能实际的在你面前演示。

瀑布式开拓的劣势的劣势：

（1）产品验证滞后

产品验证滞后是瀑布式开拓过程中最让产品头疼的部分，产品职员必须等到项目进程尾声的时候才可以对产品进行验证，也便是说在投入大量的人力物力之前所有的产品观点都是无法得到充分的验证的，验证滞后也意味着所有阶段不能涌现任何疏忽否则将导致整体项目变得失落控；

（2）需求变更困难

在瀑布式开拓过程中，任何对之前决策的修正与调度都将打乱原来的开拓流程，大量已完成事情须要重新评估与推进严重耗费全体团队的精力，产品经理在跟踪用户需求的过程中，难免会产生需求的变更，如果发生需求变更那修正需求必定在所难免，只这天夕的问题，而且延迟到下一个版本开拓也只是一个权宜之计，无论从本钱或是用户体验上考虑肯定都是越早改动越好；

（3）难以适应变幻的市场

瀑布式开拓过程中的所有事情都严重依赖于流程与文档，任何一点改动都会牵一发而动全身，也使得产品经理压力倍增，产品经理在这一流程下提交给开拓的所有产品必须确保通过严格的验证且没有缺陷，另一方面发布过后产品也会意惊肉跳，随时做好快速线上修复的准备。

五. 实际推进项目过程中，我们该如何选择

在理解了瀑布式开拓过程中的毛病就不难明得为什么要改用各种敏捷开拓，瀑布式开拓流程过于空想化，须要人们在开始的时候就预见到所有的问题，全面的把握需求；终极实践证明，每每瀑布式开拓只适用于规模很小的项目开拓，对付大型项目来说，瀑布式开拓就显得难以顺利推进且如果采取瀑布式开拓，产品的交付韶光常日都会比一开始所估量的韶光晚，而且常常是产品上线后创造各种毛病，产品与全体技能团队不得不用费更多的精力去进行修补。

通过这些解释，我也更希望文章前的你看到两种办法的局限性，并选择一个真的适宜你团队的开拓流程。

希望本文可以帮助那些还在犹豫的人，往后也会更多的深入各个问题进行探究~

作者：Lonny，公众年夜众号：gatf_yl

本文由 @Lonny 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 Pexels，基于 CC0 协议