大家好 ，欢迎来到半个产品团队出品的产品经理系统课程 ，这节课我们讲迭代开发计划 ，在开发的过程当中 ，我们首先需要解释一个概念 ，叫做产品迭代 ，产品迭代指的就是产品快速地响应着来自外界不断的变化的需求 ，通过不断地推出新的版本来满足或者引领需求 ，我们要做到永远快于对手一步 ，产品迭代 ，它是整个产品生命中非常重要的一环 ，一个好的迭代呢 ，它往往能够延长产品的生命周期 ，甚至成为一款优秀产品 ，所以一个产品在上线之后 ，我们还是要去去不断地做迭代 ，做更新 ，来跟随市场快速变化的节奏 ，以及用户他可能会存在的 ，对于我们的产品有更多的需求等待着被满足 ，产品经理 ，我们在这个过程当中就要去负责去筛选需求 ，把我们初步评估出来的需求进行一个可行性的分析 ，可行性的话 ，我如果说这个需求它可以实现 ，我们再去跟各个部门一起做评估 ，来确定最终的需求到底是什么 ，然后当我们出了解决方案 ，换好了原型之后 ，再去跟进行设计 ，跟进开发 ，他们来实现整个产品的落地 ，那么一个互联网产品多久迭代一次呢 ，这一点其实每一个公司的产品迭代周期是不一样的 ，但是大多数的产品迭代周期啊 ，它都会维持在两周到三周这样的一个时间段 ，因为如果说周期太短 ，功能开发不过来 ，或者说开发的功能就会比较少 ，并且呢 ，迭代的太频繁 ，对于用户来说 ，他们可能要经常的更新 ，我们要经常提示他们 ，就会造成它们的体验非常不好 ，

如果说迭代的周期太长了 ，那用户提出的部分需求或者一些存在的问题 ，可能就会长时间得不到解决 ，这这就会导致用户它存在流失的风险 ，所以我们产品迭代周期大概是在两周左右 ，会比较多 ，开发模式给大家简单的介绍一下 ，像过去有螺旋式开发 ，瀑布式开发 ，但是现在呢 ，大部分公司用的都是敏捷式开发 ，很多大型的软件也都开始采用了敏捷式开发的东西 ，瀑布式开发呢 ，就是像这张图一样 ，它是一个串行的结构 ，它每一个流程完成之后 ，才能够进入到下边的流程 ，一层一层的这样走完 ，它是必须要上一个节点完成之后才能够进入到下一个节点的过程 ，那这种形式现在用的会比较少 ，一般是一些常见的大型的 ，比如说 crm 客户管理系统 ，erp 进销存系统这种大型的项目 ，它会用瀑布式的开发 ，那敏捷的开发呢 ，它就是随着市场规划一个周期一个周期的去做检测 ，然后快速的去推进 ，去进展 ，就比较适合现在的互联网公司快速发展的节奏 ，我们整个的研发团队基本上都是按照这样的开发方式来做的 ，我们再来看详细来看一下瀑布式开发 ，了解一下它的一个历史过程 ，瀑布式开发呢 ，它是一种传统的软件开发模式瀑布法 ，它是一种刚性的线性需求 ，其中包含顺序阶段 ，包含的顺序阶段从概念到分析到设计到编码到测试 ，每一个阶段他的目标性都非常强 ，而且在进入到下一个阶段之前 ，每个项目必须百分之百地完成 ，

才能进入到下个阶段 ，但是这种模式如果说进行回溯进行修改的话 ，就会非常的麻烦 ，比如说我发现上一个环节有问题 ，有遗漏 ，我需要回溯过去 ，那这个项目可能就要重新的排布一次 ，就又要从零开始跑一遍 ，这个就是不太便捷的瀑布式开发的方法 ，敏捷式开发呢 ，它是一种叫做循序渐进的方法来进行开发 ，也就是说我们这个产品它是一个大项目 ，它可以被拆分为多个有联系的 ，同时又能够独立去运作的小项目 ，分别的去做开发的完成 ，在整个的过程当中 ，产品它一直是处于一个可用的状态 ，就比如说我们做一个 app 的时候 ，我们先把它的核心功能 ，或者把它的主流程先做出来 ，这个过程就已经可以实现我们的产品基础操作体验的 ，可以在这个过程当中拿去做检验 ，这个检验是内部的团队 ，或者说测试的人员去做功能的体验测试 ，来保证这个功能已经开发完善了 ，就一个一个的去这样去搞定它 ，那在这个过程当中开发它还会它还可以不断地去完成其他的之前我们没有做完的这些小项目 ，这些小功能 ，那些就这些有联系的 ，但是又可以独立运行的小小项目 ，通过这种方式来实现敏捷的迭代 ，那像瀑布式的开发方式啊 ，刚才说了 ，就需要每一个环节 ，比如说从需求到分析阶段 ，到需求的调研阶段 ，策划包括视觉设计到开发编码的阶段 ，以及测试到后期最后的验收发布这样的过程 ，它是一个线性的过程 ，前面的必须做完了 ，后面的才能做 ，在这个过程当中 ，只有遇到最必要的改动 ，

我们才能去改 ，如果说有一些不太必要的改动 ，我们再我们再去改 ，那它的时间成本就会变得非常高 ，当这个时候如果说有需求变更的话 ，那就没办法再往后做了 ，就必须把这个需求先做 ，因为如果不把这个需求做了的话 ，后面再改的话会非常难 ，因为我们已经浪费很多成本在里面 ，在这个过程当中 ，要实现用户的价值的提升的话 ，只有完成的差不多了 ，才可能有用户价值的提升 ，用户才能够有一个完善的一个功能版本的体验 ，而不是说在这个过程当中 ，我们一小步一小步的分别去做一一些体验 ，这个是做不到的 ，那敏捷迭代它就可以实现 ，当我们在做完需求分析之后 ，要真正的进入到设计和开发的阶段之后 ，我们可以把需求拆分为一个又一个版本做迭代 ，或者说一个又一个小项目 ，每一个迭代做完了之后 ，用户都可以去使用 ，去体验 ，就产生了一定的用户价值 ，那这样的话我们的时间成本其实就没有花太多 ，这个时候我们就有很多可以去变化的机会 ，可以去操作的机会 ，比如说当我们做完第一个迭代 ，用户 ，他发现我们这个版本好像有些问题不太好 ，那我们第二个版本 ，第二个迭代 ，在开发的时候就可以立马的做一些修改 ，改掉之前的一些呃存在漏洞 ，存在疑问的地方 ，做一些调整和变化 ，那这个时候就是拥抱用户的价值的的一个变化 ，当然了 ，在这个过程当中 ，其实整个的效率是非常高的 ，所以它的生产效率是特别高的 ，这个就是敏捷迭代模式带来的一些方便啊 ，可以说是非常节省成本的一种效果 ，那通过迭代开发 ，还有关注互动 ，互动沟通等方法来降低软件开发过程中的风险 ，

同时也减少在开发过程中造成的资源消耗 ，好处呢就是通过早期的发现还有修复缺陷来提高我们的产品效率 ，敏捷开发的核心 ，它讲究的就是四个字小步快跑 ，那提到小步快跑 ，其实还有一种概念叫做 mvp ，就是最小可行性版本 ，每一次我只做一个最基本的最小的版本功能 ，快速的去市场上来做一个试错 ，这都算是敏捷性开发的一种 ，因为现在互联网的一些行情 ，不单单是市场变化快 ，其实竞品变化也非常快 ，也许我们可能过去我们规划要做三个月 ，要做四个月 ，我们通过这种瀑布式开发做出来的功能 ，但是可能我们放到市面上的时候 ，其实竞品早就已经先入为主就已经做出来了 ，那这种情况其实就很不适合市场上的一个适应性 ，我们就必须要通过在这个过程中及时地响应外界的变化来做针对性的调整 ，所以敏捷说的就是以用户的需求变化为核心 ，采用循序渐进的方法进行软件开发 ，这里有五种价值观 ，首先 ，第一个 ，沟通团队中绝大多数的问题都会归结于是人的问题或者沟通的问题 ，团队配合过程中开始就约定好明确沟通的计划 ，还有沟通的原则是非常重要的 ，比如说工作日每天晚上6点开一个站会 ，开一个每日站会把最新的信息及时的同步给到相关的人 ，不要藏着 ，不要噎着啊 ，具体的约定 ，我们背后的这些目的 ，我们要马上告诉其他人 ，

要实现团队成员之间的相互信任 ，互相的认可 ，第二 ，