现在大部分互联网公司都有开晨会的制度，在快速迭代的产品管理模式下，晨会首先必须是站立式，以此保证会议的简短、高效，一般情况下团队的每个人都会逐一描述三大问题：昨天做了什么事情，今天要做哪些事情，在工作中遇到了什么问题。在会议中产品经理应该重点关注两个方面：其一是昨天工作是否真的完成，这里所说的完成不是代码写完了就了事，也不是自测没问题了就是完成，所谓一个任务的完成应该是真正意义上的完成，即满足用户需求，可立即部署到真实环境中进行使用。我见过太多的工程师口口声声说功能已经完成，但最终部署到服务器上依然需要经历大量的联调测试，然后看着你说：“在我机器上是没问题的”。其二产品经理应该重点关注团队成员在工作中遇到了哪些问题，并想办法通过团队其他人的力量帮助其解决，这里我提到的是其他人而不是产品经理，产品经理在这个过程中应该培养团队的合作能力以及成员相互配合解决问题的成就感、信任感。

　　关于过程优化

在产品快速迭代的过程中，有很多地方需要产品经理进行主导优化，让我们来列举几个例子：

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

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

文档优化。推荐使用类似 wiki 的系统来统一管理产品文档，产品经理在写文档的过程中不要因为怕麻烦就降低文档的可读质量，要知道产品很有可能因为你少写几个字就走向了另一个极端，很可能就因为这几个字，工程师就需要返工，这也是为什么大部分工程师都想暴打产品经理的原因所在。因此产品经理在写文档的过程中应该多以工程师的视角去写需求，如果你是工程师，看到需求后是否会出现理解偏差?如果会，那么请用更多的时间来完善需求文档，产品经理应该时刻清楚，需求文档的本质不在写得多么有文采，能让工程师正确理解才是王道，正所谓不管黑猫白猫，抓到耗子就是好猫。

团队沟通优化。产品经理应该增加与团队成员在一起的时间，可以选择工作时坐在一起，或者一起吃午饭等等，你要时刻找机会把自己的想法准确的灌输到工程师的脑袋里，并且尽可能的在不动声色间解决他们心中的疑惑。

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

快速迭代所带来的弊端就是产品质量无法保证，因为时间有限，往往无法对产品的健壮性进行足够的测试，甚至有时候一个功能完成后测试人员也是仅凭借着经验随便点点就通过了，这里我建议大家选用一款智能化的 BUG 管理系统，系统每天通过群发邮件的方式来展现 BUG 情况，产品经理自己心中要有一个 BUG 可容忍的最大值，一旦某天的 BUG 数量超过这个值，就要分析原因并采取相应的措施来解决了。

　　关于总结

在产品上线后，我们通过数据来分析产品上线是否成功，并总结上一个迭代过程中所遇到的问题，因为快速迭代的团队人员都不会很多，所以大家可以对出现的问题畅所欲言，评价成员在过程中的表现得分，当然这个评分与绩效无关，我们的目的仅仅是希望团队更好，团队好了产品才会好。

我相信每一个互联网公司对于快速迭代的看法都不尽相同，这是一个仁者见仁智者见智的事情，但是请大家明白，快速迭代绝对不是边改 BUG 边上线的过程、也绝对不是将功能进行分解来逐步实现的过程。快速迭代的实施是有前提条件的：

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

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

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

你的产品，是否可以快速迭代?你是否已经了解如何进行快速迭代了?