产品快速迭代的五大要点

标签： 产品 迭代 | 发表时间：2013-03-29 10:03 | 作者：超凡艾瑞克
出处：http://www.geekpark.net/

作者头像
作者： 超凡艾瑞克 / 产品观察家
仰望星空，脚踏实地。新浪微博@超凡艾瑞克
[核心提示]我们时常听到许多产品团队提到“小步快跑，快速迭代”，但它到底指的是什么？对此不了解的同学可以看看这篇文章。

今天在微博上又一次看到有人转发小马哥的：“小步快跑，快速迭代”理论，刚好鄙人近期收集了一些 快速迭代的资料，接下来结合自身的经验来浅谈产品的快速迭代方式。这篇文字可能会偏项目管理一些，不过我认为项目管理也是产品经理基本素质之一。

关于立项

这一点相信大家都不陌生，每个产品在经过 BRD、 MRD (当然，这两个过程并不是所有产品经理都能参与)之后，就会进入立项阶段。在传统的立项过程中，我们更多的是走流程，项目负责人提出立项申请，项目组进行可行性讨论分析，然后召开大会进行立项评审，负责人根据评审结果进行相应修改，最后再召开一次轰轰烈烈的项目启动会。而快速迭代的立项方式没这么复杂，基本上 10 分钟之内一页幻灯片就可以确定，一般会阐述这么几个问题： 我们为什么要做这件事？有没有更重要的工作要做？项目完成的标准是什么？项目的风险点在哪里？只要项目组明确了这四个问题的答案，是否立项就可一目了然。

关于晨会

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

关于过程优化

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

  1. 思想优化。在开发过程中一定会出现研发人员的意见与产品经理、交互设计师的意见不一致的情况，因为从人性的角度分析，每个角色都一定会用自己惯性思维去思考问题，比如工程师会告诉这个 Banner 放在左面程序运行效率最高，而交互设计师认为放在右边会更符合行为习惯，产品经理则认为放在更上方一点会换来更多的点击率，此时产品经理一定要引导大家站在更高层、更客观的角度去寻找解决方案。
  2. 代码优化。这一点更多的是指代码 review，一般会采用每天团队成员交叉 review 和每周团队一起进行重点功能 review 两种模式。有句话叫磨刀不误砍柴工，代码 review 是发现潜在 BUG、发现功能偏差的最低成本投入。
  3. 文档优化。推荐使用类似 wiki 的系统来统一管理产品文档，产品经理在写文档的过程中不要因为怕麻烦就降低文档的可读质量，要知道产品很有可能因为你少写几个字就走向了另一个极端，很可能就因为这几个字，工程师就需要返工，这也是为什么大部分工程师都想暴打产品经理的原因所在。因此产品经理在写文档的过程中应该多以工程师的视角去写需求，如果你是工程师，看到需求后是否会出现理解偏差？如果会，那么请用更多的时间来完善需求文档，产品经理应该时刻清楚，需求文档的本质不在写得多么有文采，能让工程师正确理解才是王道，正所谓不管黑猫白猫，抓到耗子就是好猫。
  4. 团队沟通优化。产品经理应该增加与团队成员在一起的时间，可以选择工作时坐在一起，或者一起吃午饭等等，你要时刻找机会把自己的想法准确的灌输到工程师的脑袋里，并且尽可能的在不动声色间解决他们心中的疑惑。
  5. 流程优化，需求管理系统、BUG 管理系统、产品打包机制最好都是高度智能化的，可以让团队成员第一时间找到自己想要的信息。

关于产品质量

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

关于总结

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

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

  • 第一、环境，周围环境在快速变化、产品没有足够的时间来进行需求分析及相关测试；
  • 第二、用户，用户不知道自己真正想要什么，产品需要通过迭代的方式进行试错；
  • 第三、成本，一般情况下可迭代产品的成本都很低，并且可以快速的进行版本更新。

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

极客观察均为极客公园原创报道，转载请注明原文链接。

原文地址： http://www.geekpark.net/read/view/175914

关注极客公园，即时获得最新内容： Twitter | 微信：极客公园 | 新浪微博 | 花瓣网 | 人人小站 | Google+ | 点点

相关 [产品 迭代] 推荐：

论迭代式的产品开发方法

- david - 所有文章 - UCD大社区
对基础构思的完善和原型化. 一款游戏从创意到开发，抽象来看可以分为两大阶段：基础构思的阶段，和迭代开发的阶段. 任何游戏在最早的时候都只是一个或者一组零散而不确定的构想，策划人员将这组构想加以整理，抽取其中相互联系的规则组成核心规则集，这就是产品最初的框架. 譬如说俄罗斯方块最初的规则可能包括：方块连成一行就消除并加分；头顶随机掉落新的方块；方块可旋转，等.

产品快速迭代的五大要点

- - 极客公园-GeekPark
[核心提示]我们时常听到许多产品团队提到“小步快跑，快速迭代”，但它到底指的是什么. 对此不了解的同学可以看看这篇文章. 今天在微博上又一次看到有人转发小马哥的：“小步快跑，快速迭代”理论，刚好鄙人近期收集了一些 快速迭代的资料，接下来结合自身的经验来浅谈产品的快速迭代方式. 这篇文字可能会偏项目管理一些，不过我认为项目管理也是产品经理基本素质之一.

产品迭代中的项目流程有哪些

- - 人月神话的BLOG
问题：对于一个全新的产品，可能需要商业需求文档、竞品分析报告、市场调研报告之类的，等待各项评审过关后，还需要找项目申请立项等等. 但是对于一个很成熟的产品，只不过是每个月进行正常迭代也需要搞这么繁琐吗. 之前我们在迭代过程中只是提交功能概要设计，VP评审后就是详细功能设计了，再之后就是交互设计并交付开发，但是新的项目流程出来后就需要搞得和开发一个全新产品一样，还需要提交竞品分析报告、商业需求文档、进行立项等有这个必要吗.

做好用户留存，实现产品优化、迭代

- - 人人都是产品经理
对于一个新产品而言，短时期内的大幅度获客可能不是一件难事. 但是，就长期而言，想要将这一大批的用户牢牢地锁在自己的领地里，却是一件难事. 用户留存率无疑是判定一个产品发展价值大小的重要标尺，那么如何更好地实现用户留存，再以用户使用数据反哺于产品的优化、迭代更新呢. 1月15日，多闪、马桶MT和聊天宝同时亮相，引发了“ 围剿微信”的热议，但个推大数据发布的一份数据报告显示：一个半月过去了，这三款应用的成绩都有些不理想.

敏捷产品管理之发布、迭代计划_Yanelnan的博客-CSDN博客

- -
上篇我带你从理解产品 Backlog 最好的形式 Story 开始，经过建模、搜集、编写、估算这四个步骤，编写出有效并且粒度合适的 Story 来帮助团队成员在理解需求上达成一致. 让“一张卡片”发挥出它的洪荒之力，快速挖掘需求，理解需求. 本篇我会带着你用编写好的 Story 来制定发布计划、迭代计划，并且在过程中进行有效测试和监控.

互联网创业公司融资、产品、运营快速迭代和人才模式总结

- Keen - Tech2IPO
长期以来，创业者们在这些问题上都面临着共同的困惑，在实践上往往手足无措. 本文是天使投资人Luc在长期的创业实践和投资实践中的经验总结，他用量化的方式，鲜明的给创业者们指出了最优路径. 希望能对作为创业者的您有所帮助，有所启发. 第一轮天使投资或自筹资金 融资金额 100,000 RMB                     天使占股5%.

产品快速迭代就叫”精益创业”了吗？不！听听500 Startups创始合伙人Dave的看法

- - PingWest
Lean Startup（精益创业）已经成为创业者，尤其是科技领域的传业者非常推崇的一种创业方式，可是很多人对它的理解仍然停留在“产品的快速迭代”层面上. 硅谷知名孵化器500 Startups的创始合伙人Dave McClure在这周来到了北京，和我们也做了一个短暂的交流，来听听看看他是怎么阐释Lean Startup的.

迭代式开发技术

- - CSDN博客研发管理推荐文章
    迭代是一开发种技术，用来把系统功能传递到一系列的增量的完整版本，每个版本一个特定固定的时间段被开发，该时间段称之为迭代. 图中颜色代表每次开发每项活动所占的比重不同. 1、在进行大规模的投资前，就解决了关键的风险问题. 2、使的早期用户反馈在初始迭代中就能出现. 4、各个目标里程碑提供了短期的焦点.

敏捷开发-快速迭代

- - CSDN博客研发管理推荐文章
今天跟大家分享的是“敏捷开发、快速迭代”. 我们大都采用的是“瀑布开发模式”，有了问题，就得返工，虽然最终的产品会比较齐全完善，但是开发周期太长，开发人员会产生排斥，甚至厌恶的心理. 经过YH系统的开发，也且生体会到了这一弊端. 借鉴敏捷开发模式，来改善软件开发过程，提高项目的开发效率. 要想借鉴，首先得弄懂以下3个问题.

二叉树迭代器算法

- - 酷壳 - CoolShell.cn
二叉树(Binary Tree)的前序、中序和后续遍历是算法和数据结构中的基本问题，基于递归的二叉树遍历算法更是递归的经典应用. 但是，仅有遍历算法是不够的，在许多应用中，我们还需要对遍历本身进行抽象. 假如有一个求和的函数sum，我们希望它能应用于链表，数组，二叉树等等不同的数据结构. 这时，我们可以抽象出迭代器(Iterator)的概念，通过 迭代器把算法和数据结构解耦了，使得通用算法能应用于不同类型的数据结构.