5.1　迭代思维

说起迭代，最好的例证就是如今火爆的移动互联网。从2007年的萌芽状态到2010年后的爆发状态，移动互联网的发展显然比传统互联网要快得多。这是因为移动互联网产品不同于传统互联网产品，任何一个产品面对的都是上亿用户这样一个庞大的使用群体，那么，这个群体的用户主要是哪一种人群，他们有什么喜好，有何种习惯，会怎样使用我们的产品，是否喜欢我们的产品，在使用过程中会出现哪些问题等都是我们需要关注并且加以解决的。

遗憾的是，移动互联网产品的需求并不是通过短暂几个月的用户调研、市场调查、产品规划就能弄清楚的，何况移动互联网的用户群体本身也处于飞速的动态发展之中，他们的产品观、使用产品的习惯，以及当下的产品氛围对用户都有着很深刻的影响。譬如，现在喜欢微信的用户也许过一段时间会喜欢上另外一款社交类产品。在移动互联网时代，行业的迭代可能是由产品自己主导，也有可能被其他产品主导。

简单来说，迭代就是产品不断进步和发展的过程。产品的技术和创新点在进步，每段时间都会出现值得关注的新功能或者新产品，旧的功能或者产品被替代，而随着技术的进步，迭代的速度已经越来越快，机会转瞬即逝。

那么，这种情况下，我们该如何发展产品？如何对各种可能的产品方向和创新点做选择？我们要相信用户将是最好的指南针，用户的选择和黏性才能给产品足够多的指向性，让产品迅速感应用户需求，然后根据用户数据选择产品的功能，在这个过程中不断地升级进化，推陈出新，才是保持领先地位的唯一方式。要不断地倾听用户的反馈，不断地调整修改，然后决定产品接下来的方向。

所以，“快速迭代”是我们对产品的基本要求，能否做得足够快同时足够好已经成为衡量一款产品研发是否成熟的标准之一。在很多移动互联网产品中，不少平均每周或者每半个月就会发布一个版本，甚至还有更多，之所以能做到如此高的产品发布节奏，是由于现在的移动互联网已经越来越容易出现漏洞等问题，同时也有不少的新功能需要优化。

在这个过程中，通过一种有特色的敏捷迭代开发模式，也就是以敏捷的反应力应对产品和产品环境的变化，在发展过程中，小米公司的ROM产品就维持着每周一次更新的频率。

现在的移动互联网研发团队，譬如小米公司的MIUI团队，就由多个角色组成，包括：项目经理、产品、UE设计、前台开发、后台开发、测试、运维。以一周为一个固定的迭代开发周期，这一周时间包括了团队一次完整的各个角色的研发协作过程：迭代前有特性规划，迭代中有迭代规划、开发、测试、发布等过程，迭代后有回顾以及用户反馈跟踪。也就是说，在每个周期的开始都是上一轮产品的总结和新一期产品的迭代规划。这种方式看似简单，但对团队的综合研发能力来说其实是一个巨大的挑战，必须能够快速发现产品中的问题并解决问题。在整个规划中，有如下几点需要重视。

第一，产品更新的特性需要能将这些特性分裂成很细小的可交付的子特性，简单地说，就是要详细分解每一期规划的内容，而这个总工作量通常不超过两天的开发工作量。

第二，产品在迭代前，特性规划、沟通确认、界面交互及视觉设计这些工作均须在短暂的时间内迅速地完成沟通和责任到位，以KPI为基础制定能够完成的工作量。

第三，在规划迭代计划及评估过程中，还要综合考虑人员设置和安排的问题，也就是说，必须考虑到特性与子特性之间以及人员之间的配合，从而合理地安排规划任务，在这个过程中要保证开发过程顺利进行，降低迭代失控的风险。

第四，极速迭代要求团队成员工作协作能力强，同时，个体的自运转能力强，还需要长期默契配合。不管是产品的前台开发、后台开发，还是测试人员，都能够高效率沟通，顺畅协作。

也就是说，在迭代的过程中，只有通过自身不断沟通和协调才能帮助产品在一段时间内顺利地完成迭代，目标精准同时具有高执行力，才能维持迭代顺利进行。

快速迭代的背后是产品的快速开发，而做到产品的快速开发只是所有“快”字诀的第一步，其根本目的就是让用户尽快用到短时间内开发的新版本，从而尽快得到用户的反馈信息，在这个过程中提取下一次迭代必需的进程，以便及时地对下一期产品开发做调整。所以，一个产品团队能否快速获取并顺利解读用户反馈，是否真正重视反馈并及时作出响应非常重要。同时，产品团队也需要对产品的迭代周期有所规划，而不是被用户的反馈牵着鼻子走。

在产品迭代的过程中，要讲究“快”，“错了立即改”以及“谨慎迭代新功能”。优秀的应用产品发布后，可以做周期性的改进，但是新的功能增加频率则不能过快，而要谨慎，每个新增的功能都不是在迭代中出现的，而是在某个恰当的时机推出的。功能上线容易，想要撤下来就难，试错可以有，而且对于一个新功能试错也是有价值的。当超过十万人在使用某产品时，即使一个功能不那么好，同样会有百分之几的人觉得还不错。这时候只能对这个功能进行优化迭代，如果直接取消这个功能，用户就会抱怨，造成不良的反应，导致用户流失。