快速迭代

出自 MBA智库百科(https://wiki.mbalib.com/)

　　快速迭代是指产品与服务要快速地适应不断变化的需求，不断推出新的版本满足或引领需求，永远快于对手一步，例如苹果。

• 第一、环境，周围环境在快速变化、产品没有足够的时间来进行需求分析及相关测试；

• 第二、用户，用户不知道自己真正想要什么，产品需要通过迭代的方式进行试错；

• 第三、成本，一般情况下可迭代产品的成本都很低，并且可以快速的进行版本更新。

　　快速迭代最大的优点是及时的用户反馈，这样可以快速的调整产品的方向，避免在无用的功能浪费时间和精力，减少风险。也就是说真正的迭代必须把每一个迭代周期的成果交给用户，而且每次的成果都是完整可用的。如果一个迭代周期结束后，成果被内部否定定而没有推向市场，那这就不算是真正的迭代。每一次迭代必须以产品的发布结束。

　　相对一个需求大而全的产品，迭代更加适合创新型的产品，特别是对产品最终形态还缺乏概念的时候。但是迭代仍然应以一个明确的目标和原则为前提，否则容易出现偏离最初意图的情况。从开发的角度来说，对开发人员的整体水平要求较高，因为迭代意味着每一个迭代周期或多或少的代码重构，这对于产品的任何一个开发人员的设计水平和全局观都有一定要求。

　　有些产品或者产品的某些阶段并不适合迭代的方式，比如游戏的第一个版本，因为只有成为一个相对完整的产品以后才能推向市场，不可能像工具类应用一样先推出一个能解决部分问题的比较粗糙的版本，游戏用类似的方式推向市场会自砸招牌。但是开发组内部仍然可以通过阶段性的工作确认成果，也可以称之为迭代，但和前面的迭代含义上有一些差异。

　　在产品快速迭代的过程中，有很多地方需要进行主导优化：

　　1、思想优化。在开发过程中一定会出现研发人员的意见与产品经理、交互设计师的意见不一致的情况，因为从人性的角度分析，每个角色都一定会用自己惯性思维去思考问题，比如工程师会告诉这个 Banner 放在左面程序运行效率最高，而交互设计师认为放在右边会更符合行为习惯，产品经理则认为放在更上方一点会换来更多的点击率，此时一定要引导大家站在更高层、更客观的角度去寻找解决方案。

　　2、代码优化。这一点更多的是指代码 review，一般会采用每天团队成员交叉 review 和每周团队一起进行重点功能 review 两种模式。有句话叫磨刀不误砍柴工，代码 review 是发现潜在BUG、发现功能偏差的最低成本投入。

　　3、文档优化。推荐使用类似wiki的系统来统一管理产品文档，在写文档的过程中不要因为怕麻烦就降低文档的可读质量。

　　4、流程优化。需求管理系统、BUG管理系统、产品打包机制最好都是高度智能化的，可以让团队成员第一时间找到自己想要的信息。