在微博上又一次看到有人转发小马哥的：“小步快跑，快速迭代”理论，刚好鄙人近期收集了一些快速迭代的资料，接下来结合自身的经验来浅谈产品的快速迭代方式。这篇文字可能会偏项目管理一些，不过我认为项目管理也是产品经理基本素质之一。
关于立项
这一点相信大家都不陌生，每个产品在经过 BRD、MRD (当然，这两个过程并不是所有产品经理都能参与)之后，就会进入立项阶段。在传统的立项过程中，我们更多的是走流程，项目负责人提出立项申请，项目组进行可行性讨论分析，然后召开大会进行立项评审，负责人根据评审结果进行相应修改，最后再召开一次轰轰烈烈的项目启动会。而快速迭代的立项方式没这么复杂，基本上 10 分钟之内一页幻灯片就可以确定，一般会阐述这么几个问题：我们为什么要做这件事?有没有更重要的工作要做?项目完成的标准是什么?项目的风险点在哪里?只要项目组明确了这四个问题的答案，是否立项就可一目了然。
关于晨会
现在大部分互联网公司都有开晨会的制度，在快速迭代的产品管理模式下，晨会首先必须是站立式，以此保证会议的简短、高效，一般情况下团队的每个人都会逐一描述三大问题：昨天做了什么事情，今天要做哪些事情，在工作中遇到了什么问题。在会议中产品经理应该重点关注两个方面：其一是昨天工作是否真的完成，这里所说的完成不是代码写完了就了事，也不是自测没问题了就是完成，所谓一个任务的完成应该是真正意义上的完成，即满足用户需求，可立即部署到真实环境中进行使用。我见过太多的工程师口口声声说功能已经完成，但最终部署到服务器上依然需要经历大量的联调测试，然后看着你说：“在我机器上是没问题的”。其二产品经理应该重点关注团队成员在工作中遇到了哪些问题，并想办法通过团队其他人的力量帮助其解决，这里我提到的是其他人而不是产品经理，产品经理在这个过程中应该培养团队的合作能力以及成员相互配合解决问题的成就感、信任感[创业网Cye.com.cn]。
关于过程优化
在产品快速迭代的过程中，有很多地方需要产品经理进行主导优化，让我们来列举几个例子：
思想优化。在开发过程中一定会出现研发人员的意见与产品经理、交互设计师的意见不一致的情况，因为从人性的角度分析，每个角色都一定会用自己惯性思维去思考问题，比如工程师会告诉这个 Banner 放在左面程序运行效率最高，而交互设计师认为放在右边会更符合行为习惯，产品经理则认为放在更上方一点会换来更多的点击率，此时产品经理一定要引导大家站在更高层、更客观的角度去寻找解决方案。
代码优化。这一点更多的是指代码 review，一般会采用每天团队成员交叉 review 和每周团队一起进行重点功能 review 两种模式。有句话叫磨刀不误砍柴工，代码 review 是发现潜在 BUG、发现功能偏差的最低成本投入。
文档优化。推荐使用类似 wiki 的系统来统一管理产品文档，产品经理在写文档的过程中不要因为怕麻烦就降低文档的可读质量，要知道产品很有可能因为你少写几个字就走向了另一个极端，很可能就因为这几个字，工程师就需要返工，这也是为什么大部分工程师都想暴打产品经理的原因所在。因此产品经理在写文档的过程中应该多以工程师的视角去写需求，如果你是工程师，看到需求后是否会出现理解偏差?如果会，那么请用更多的时间来完善需求文档，产品经理应该时刻清楚，需求文档的本质不在写得多么有文采，能让工程师正确理解才是王道，正所谓不管黑猫白猫，抓到耗子就是好猫。
团队沟通优化。产品经理应该增加与团队成员在一起的时间，可以选择工作时坐在一起，或者一起吃午饭等等，你要时刻找机会把自己的想法准确的灌输到工程师的脑袋里，并且尽可能的在不动声色间解决他们心中的疑惑[创业网Cye.com.cn]。
流程优化，需求管理系统、BUG 管理系统、产品打包机制最好都是高度智能化的，可以让团队成员第一时间找到自己想要的信息。\
想认识全国各地的创业者、创业专家，快来加入“中国创业圈”
|
