01 敏捷是管理流程
敏捷开发就是管理流程，不仅仅涉及到组织形态，更关乎整体的组织结构和人员职责，所以敏捷同时还代表着企业管理方式，绩效方式，系统架构方式。敏捷一共有三大特性：
1、产品特性：即聚焦属性，采用小组式的开发方式能将目标做到最小，最快，最优的输出，能快速试错，不断的快速迭代，这也是敏捷的核心作用。
2、产品效率：因为系统的模块化，插件式的方法开发，需要非常强大的系统架构能力，也促进了产品结构化更加合理。
3、产品灵活性：小组小，目标小，整体性考虑低，很容易达成一致，沟通和执行就更加便捷，减少损耗，不但可以达到预想不到的结果，还能有效预防风险。那么敏捷开发是如何做到的这些特性的呢？如下图所示：
1、决策小组：等于是核心智能大脑，主要负责战略规划和资源协调。这样就能最大化的减少资源等待期，只要确定方向资源随取随用。
2、程序模块：等于是把一个大的产品系统，切碎，切碎，在切碎，切到最小的业务单元，这样就能让小组聚焦到一个非常小的范围。大大加快了小组的快速反应能力，每次迭代都是MVP。3、研发小组：只有产品和研发，其他资源都是决策小组和程序模块配置的，这样就大大加快了开发进度，除了研发小组外的成员快进快出。这样就可以提高沟通和执行能力，不用因为开会沟通等琐碎的事务，产生非常长的决策等待期。
02 流程以管理为目标
常见的开发模式有三种，瀑布流开发、迭代开发、敏捷开发。瀑布流开发就是最原始的开发模式，流程是产品经理评估、定义、设计好产品，在评审进入开发流程，项目经理锁定资源进行开发，这样的管理方式因为规划的周期长，开发周期也长，那么就损失掉了灵活性，同时因为资源长期锁定，造成了资源利用率差的现状。所以就产生了迭代式开发模式，这种开发就是把产品切成节点，一点点做，虽然整体规划切小了，但是产品战略没变，只是节点上的资源释放率被加大了。于是就有人想出了敏捷开发，其实就是技术架构的成熟，形成了插件式的开发方法，而这种开发方法又契合了去掉中层管理的理念，所以就被流行起来了。其实、很多企业根本不具备敏捷的条件，产品也没有庞大到能够切分的程度。所以、大部分企业是不适合敏捷开发的。
有童鞋会说，我不信！那我就对比下这三种开发模式都有多大的差别吧，我们分别从产品定义、产品文档、产品设计、产品研发四个角度分析，如下图所示：
产品定义：瀑布流采用的是全局定义，也就是产品经理必须从BRD,MRD,PRD做到一气呵成，完整统一。迭代开发产品只需要定义总体愿景规划后，定义每个节点的产品目标，即任务定义，等于PRD分了阶段，但是MRD不可能分阶段（因为市场需求必须先定义，也不会因为开发改变，如果市场需求真的变了，整个产品规划都要变）。敏捷开发呢，BRD\MRD都由决策层做了，而产品经理只需要做用户行为设计定义，等于产品三大目标，可行性、有效性、可用性，只保证可用性就可以了。是否可行是决策组决定的，是否有效是敏捷教练决定的。这也是这么多年C端产品如雨后春笋般爆发的原因之一。
产品文档：瀑布流开发是完整的产品文档，啥都得写，从市场到业务，从业务到开发，从开发到执行，从执行到运营。屁事都得想多面面俱到，不仅时间长，更有很多老产品开玩笑说自己就是个文档撰写员。迭代开发呢，因为节点比较多，前期调研时间和定义时间是大头，产品一旦进入执行阶段，因为文档量大大减少，而且需求可以分期执行，就存在很大的空间和时间研究下一个阶段的细化工作，但是企业因为产品在开发阶段的轻松，就感觉产品经理没事干了，让产品经理兼顾了用户体验、项目经理、测试经理的职责（迭代开发的产品童鞋是不是很想哭？），这样的配置还不如瀑布流开发呢，产品经理反而更累，更杂了。反观敏捷开发，决策不用管了，方向不用找了，资源有人配了，系统有支持了，那么基本上BRD,MRD都剩了，PRD的大部分结构和逻辑也不用管了，咱就踏实的写信息架构和用户行为路径就好了，所以文档量大大减少，甚至可以减少到零，因为开发量小，需求细碎到每次就改一两个逻辑，技术又是自己小组内的，嘴炮都行。
产品设计：瀑布流是以版本为基础，因为产品目标和产品属性塑造，每次都是整体性开发和改动，一旦立项基本都是一个版本的迭代，很少出现就改一两个功能的情况，不是新产品发布就是全面改版。迭代开发呢？是以功能清单为基础，改动的都是基于某个系统框架的基础上做到改动，简单来说就是产品把要改的功能分别分配到不同的项目中去，然后跟踪不同的项目进度。反观敏捷开发，是以用户行为为基础，改动的时候都是非常小的目标，不用管什么产品结构、架构，不用管资源匹配，甚至不用管一致性和完整性，因为小组只需要管好自己产品目标下单完整性和一致性就好了。产品研发：瀑布流是以项目为单元，基本就是每次产品迭代都要成立项目组，立项评审是必须的。如果是细节的调整基本都是跟着别的项目改动一下，否则都是独立项目制度。迭代开发是以功能模块为单元，基本就是每次产品迭代都要等包，跟包，因为产品不够大所以都要等待资源释放后在成立项目组，打包进去所有产品线的功能一起调整，有时候因为某些产品线涉及到功能模块是独立任务，所以等包时间超级长。反观敏捷开发，是以独立发布形式存在，不用管那个项目组，项目经理直接入场支持，用到那个模块就调用那个模块，灵活到想干啥干啥。
总结：瀑布流设计统一，需要很强大的产品战略能力，布局能力，开发周期长，资源利用率低。迭代开发，需要很强大的产品长期作战能力，一旦中途换产品可能造成无法完成交接，甚至整个产品变样，开发周期虽然短了，管理成本提升了。敏捷开发，需要非常强大的决策支持和系统支持，虽然产品经理的工作变少了，开发也变轻了，但是一旦决策组战略调整或者系统模块资源无法支持，产品经理就变成了无头苍蝇，可能把马设计成飞蛾。
03 决策力和系统决定开发模式？
了解了三种开发模式的优劣，那么我们就看一下什么样的企业适合敏捷开发呢？如下图所示：
产品需要承载市场需求，企业需求，用户需求三个方面。如果公司的产品体量比较小，系统开发能力比较弱适合瀑布流开发，因为整个公司更缺少的是战略规划和设计统一，此时即没有项目经理协调，不存在大量的资源沟通，设计敏捷方式等于设计了非常复杂的组织结构，又没有配合的基础，所以建议中小企业，采用瀑布流开发，还能招聘到好一点的产品经理和开发经理。如果公司的产品复杂度低，产品线少，系统开发能力强适合迭代开发，因为公司需要招聘决策层产品和执行层产品，实际就是等于放弃了大部分都中层产品经理，这样的结构一旦决策层出现问题，执行层根本达不到效果，还损失了统一性。提高的那点点的人员成本，一次就全部耗损进去了。如果公司产品复杂度高，体量大，系统开发能力非常强适合敏捷开发，多产品线的大型公司，产品项目甚至可以达到上万个，敏捷的这种分布式矩阵结构加大了产品灵活性，还能更好做好风险控制，不至于一个产品出问题影响到其他产品项目和产品线。
04 敏捷流程构建方法
最后、讲一下如何构建敏捷开发流程吧，如下图所示：
敏捷开发分三个主要组成：1、决策组、2、程序组，3、敏捷小组。敏捷小组又分三类人员：1、产品负责人（一般是产品经理），2、敏捷教练（一般是技术专家），3、小组成员（一般是研发人员）决策组负责对每个小组的组织架构和小组职责进行划分，并提供完整的产品战略蓝图和产品规划方法，对接小组负责人（产品经理）。程序组对每个小组的敏捷教练（技术专家），提供有效的技术支持。执行人包含两部分，分别是产品负责人（产品经理），研发人员和其他成员（因为其他成员都是共享的，需要时候进小组，不需要就撤离，例如项目经理，发布经理）.OK，这篇文章详细介绍了敏捷开发，您的企业需要吗？有需要产品管理和产品设计咨询，请联系我的微信号：chinwind001（我们做到产品落地层面）
致力推进产品管理模式
