PM学项目管理 : 什么是敏捷开发

前段时间，微信的创始人张小龙在WXG（微信事业群）领导力大会上的讲话又一次刷爆了互联网人的朋友圈，圈内人士纷纷拜读一篇名为《张小龙最新内部演讲:警惕 KPI 和流程》的文章，其中就讲到了敏捷开发。产品大神张小龙是这么描述“敏捷开发”的：

实际上，就这么小的一个团队在后面几年里面做的事情远远超过之前几十人的努力，这个小团队是怎么样工作的？这个小团队是当时用了一个方法，叫敏捷项目管理，这里可能在座的一些同事都已经不太了解这个词了，但是当时在腾讯挺鼓励用这样一种方法，我建议在座的如果没有去好好研究过的可以好好研究一下。我们真的做到一种非常敏捷的一种项目的推进方式。

我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个星期再去改它。这是一个能够持续实现你的想法的过程。

其实，敏捷开发这个词对产品经理来说并不陌生。近年来，国内越来越多的互联网公司也开始采用敏捷开发的方法来做项目管理，你可以在很多公司的办公桌椅旁边到处可见白板和贴满各种颜色便签的任务墙，然后，每天早上上班的时候，几个人围着白板开个站会，这其实就是敏捷开发的典型特征。在国外硅谷等地，敏捷式开发也早已经被Google、Facebook、LinkedIn等企业应用。

另一方面，理论上来说，如果一家公司有专职的项目经理，那么产品经理是不需要做项目管理的，而且，一个优秀的项目经理在产品迭代的过程中，有着不可小觑的作用。但国内大部分创业型公司，由于团队规模的限制，产品经理又往往会承担一定的项目管理职能，那么对于产品经理来说，了解一些关于项目管理的知识和技能就显得很有必要。

什么是敏捷开发？

那究竟什么是敏捷开发，我们来进行一一拆解下。

敏捷  vs  不敏捷

敏捷的反义当然是不敏捷，但是这个“不敏捷”在软件工程里面却有个专业的术语叫做“瀑布式开发”。

所谓的瀑布式开发，其实是经典的软件工程方法为了定义出一套完备的过程规范，使得软件开发的运作就像是机器设备一样正常的运转而总结出来的项目管理方法论。这套方法论分为5个阶段：需求分析、设计、编码、测试和维护。需求分析阶段通常定义系统的需求，明确系统的目标；设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能；编码阶段用编程语言实现设计阶段的任务；测试阶段主要测试功能是否实现，以及是否正确没用Bug；维护阶段是根据用户新的需求重新修改系统，使系统运行正常，更加稳定。

瀑布式开发的局限性也非常明显，比如对市场变化和用户需求的响应慢，更改成本高等，有可能出现的情况是产品一推出市场就宣告失败。

而敏捷开发则是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的一种方法。所以，在瞬息万变的互联网、移动互联网时代，大家已经渐渐体会到敏捷的优势，我们也看到越来越多的互联网产品出现了一周发布一次的快节奏，这么快的速度，就是为了迅速响应市场与用户的需求。

敏捷开发的一些特点

1.小步快跑，尽早交付

在互联网时代，尤其是移动互联网时代，随着时间的变化，市场环境、用户需求、竞争对手等因素都在时时发生着改变，需求方（比如用户、市场、运营、老板或者是产品自己）会不断地赋予产品新的需求来应对这种变化。为了让需求方尽早地看到结果，并给予反馈，我们就应该以小步快跑的姿势来做产品，尽早地交付新的版本。对于敏捷来说，可用的软件胜过完备的文档。比如之前传统的瀑布式开发要求的使用产品需求说明书来写详细的需求，这个时候我们采用敏捷开发的方法，或许有时候只画一个原型加点备注来告知需求，又或者直接通过口头沟通来告知需求，这就大大简化了项目交付的时间，从而达到了尽早交付的目的。

小步快跑，意味着产品交付的时间间隔越短越好，也就是产品有较短的迭代周期，通常是2-4周。传统的瀑布式开发最大的缺点之一，就是产品投放市场的速度太慢。当然，通过这种频繁地迭代是为了与用户形成良好的合作关系，及时反馈，不断地完善和提高产品的用户体验，对于不能给用户或者产品带来价值的功能需求，则坚决不做。

2.有项目计划，但也“拥抱变化”

敏捷不代表不做项目计划，恰恰相反的是，敏捷更加注重计划的制定。因为敏捷开发就是为了能够及时地响应用户和市场的需求，所以并不会死守着计划不进行调整，一旦市场发生变化，即使到了开发后期，敏捷也欢迎改变需求，不断地修正自己原先的计划，利用变化来为产品创造竞争优势。同时，参与敏捷项目的团队成员也不害怕变化，因为这些改变意味着自己更了解了市场需求，让团队本身能够与市场、用户需求同步。

3. 版本周期内尽量不加任务

尽管敏捷的目的是为了尽量让产品能够适应市场需求的变化，但也并不意味着可以毫无节制地添加和修改项目任务。事实上，从这个角度来看，我们可以把每个版本迭代看作一次小的瀑布式开发，敏捷并不是全盘否定了瀑布式开发，而是借鉴了它优秀的部分。比如说，瀑布式开发对于那种需求比较确定的项目来说还是不错的，比如工厂里面的生产环节就可以采用瀑布式开发的项目管理方法。

每个版本都有自己的开始时间和结束时间，也在项目刚开始的时候就配置了相关的资源来实现产品的需求，如果临时突然插入新的需求或是修改需求的话，多少会对项目的进度产生影响。所以，我们还是尽量在版本开始前就思考地清楚一些，除非碰到特殊情况，尽量做到版本内不加任务。

4. 团队配置也要敏捷

为了实现项目的敏捷，在团队组成上也是需要进行敏捷处理。一般来说，一个项目团队要小于20个人以下，太多了的话可以进行团队分割（事实上，很多大公司已经在这么做了）。有过异地沟通经验的人都知道，异地沟通的成本有多高，如果可以，项目成员在一个办公室进行办公将会大大提高沟通效率，有什么问题可用直接面对面地解决。这样的话，也可以充分利用办公室里的白板和墙壁。

在互联网公司里，应该都听说过“站立晨会”这么一说，这种形式也是要基于敏捷的团队的配置才能更好的完成。想象一下，如果一个场地，站满了几十上百号人，每个人说一下自己的日常工作，那么基本上一个上午的时间就过去了，这是效率非常低下的一种表现形式，如何谈的上敏捷二字呢？

5. 敏捷也需要反思

项目团队成员需要定期对前一个或者前一段时间的迭代进行反省总结，以便调整自己的行为，提高项目的开发效率。因为很多不确定的因素都会导致项目的原计划失败，比如项目需求的变更、人员的流动、市场的变化等等都会让我们做出不同的反应。在每次失败中进行反思，吸取经验教训，其实是对敏捷的进一步认识，团队成员只有通过不断地总结、反思和调整，才能更好地保持团队的敏捷性。

了解了敏捷的基本概念和特点后，我们来看看敏捷的本质是什么——

事实上，敏捷的背后是两个在当下非常流行的概念，一个叫做MVP，一个叫做精益分析。

什么是MVP和精益分析

MVP是最小化可行产品（Minimum Viable Product）的简称。这个概念是Eric Ries 在《精益创业》里提出来的，简单地说，就是指产品开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。

MVP模型也是《精益创业》中最为崇尚的方法，在产品的生命周期中，产品处于探索期时，产品价值、市场切入点、用户群、用户体验平衡点、商业目标等都模糊不清，这时候就需要低成本快捷的MVP去探索以上问题，让产品找到更好的发展方向。

mvp的版本迭代思路

如上图所示，传统的产品设计思路是一步一步，从车轮、车轱辘、外壳、动力装置、内部装饰一个流程一个流程做起，最后得到一个完善的产品。正确的敏捷迭代应该是每一步的产品都是最小可行的，虽然第一版滑板车和最后的汽车相去甚远，但也是能够滚动的代步工具，在验证了用户对出行工具的认可程度后，我们就可以去生产更加高级、完善的摩托车、甚至小轿车。

MVP的几个原则可以和大家分享下：

1、抓住产品核心主流程

MVP要求我们抓住最核心的产品流程，剔除多余的功能或者高级功能。比如电商产品，核心目标就是让用户在产品上下单买东西。那核心流程就应该是：浏览商品——挑选商品——下单付款——查询物流信息。那就围绕这个流程，剥离其他多余的功能需求（个性化推荐、活动推荐、秒杀大促、分享评论、积分等），做一款MVP产品。

当然，一款产品的核心主流程具体包含哪些，这个是需要团队和产品经理一起去商量出来的结果，不同业务，不同场景下的核心流程会有所差异。

2、不同阶段的MVP目标不同

在产品从0到1的阶段，产品刚刚上线，这个时候MVP1.0的目标就是验证需求，设想的需求是真实存在还是伪需求？设想的需求是高频还是低频？是刚需还是非刚需？

而在后续的迭代中，如果产品设想的需求的确和市场痛点相匹配，那么MVP2.0的目标则会开始优化产品核心主流程的用户体验，然后增加一些新的功能点。下一个版本的迭代则继续去观察新增加的功能点是否符合用户需求，考虑如何改进或者是下线处理。简单来说，在不断的迭代的过程中，我们对MVP的关注目标发生了一些变化，但最核心要关注的还是产品的核心主流程。

3、可以尝试任何产品形态

随着移动互联网红利期的基本结束，一个创业公司通过开发一款APP而成为独角兽级别公司的可能性已经越来越小了，这个时候APP的开发成本、推广成本也是相当之高。所以很多的创业公司会去纠结到底是做一款APP还是做一个微信公众号，这其实就涉及到MVP的产品形态问题。MVP可以是一个只有基本功能的APP，也可以是一个微信公众号，一个微信群，甚至是一款纸面原型，一个视频。只要是可以让你的用户直观地感知到产品的价值，能激发出他们想要使用产品的体验就可以。

现在更多的产品会通过微信公众号的形式验证，比如知乎的付费问答值乎，最开始的mvp产品形态主要是知乎服务号的自定义菜单或者朋友圈的分享，如果一开始就放在App端，如果用户没有来得及更新，就错失了市场机会（同一时间，分答已经在市场上跑马圈地了）。

那什么是精益分析呢？

所谓的精益分析，首先是你有一个想法或者灵感，然后通过MVP策略让产品快速上线，产品上线后，通过数据来衡量用户的表现，如果好的话就保持、继续优化，不好的就下线反思。

在创业公司，大部分的idea都来自于创始人的灵光一闪，大部分情况下投放到市场上验证时发现用户没有需求。创业团队往往精力有限，要让验证的周期尽可能缩短，而MVP加上精益分析，通过数据表现就可以快速地帮助验证市场对于产品的反馈。如果用户反馈很好，就可以继续加大投入，如果用户反馈有问题，也可以及时调整避免更多的精力浪费。

MVP的实践版——分答的版本迭代之旅

分答，是2016年度最引人注目的付费语音问答，用户可以快速地找到可以给自己提供帮助的那个人，行家通过语音用一分钟时间为用户答疑解惑。这款产品由在行团队孵化，也是延续了知识传播与分享的分享方式。不仅是科学家，很多名人和各领域的专家也都加入「分答」付费问答的模式。上线仅四十二天，超过1000万授权用户，付费用户超过100万，33万人开通了答主页面，产生了50万条语音问答，交易总金额超过1800万，复购率达到43%。

在如此傲人的成绩下，分答的产品总监朱晓华透露，分答的idea来自于在讨论轻量化知识交换平台中，姬十三想做个语音问答，从确定要做到产品正式上线，中间只用了一周的时间。

我们可以来看看一周的时间，分答团队都做了哪些事情：

一晚框架：1个产品经理

一日原型：3个产品经理

一个周末主体：1设计、1后端、1前端、1测试、1运营

一周业余时间完善

两天内测

一日引爆

通过一周紧张的设计和开发，分答的第一个版本终于上线了。第一版上线的分答，非常简单、简陋，只有最基本的提问和偷听功能，而且还有不少的bug，但这并不影响产品上线验证用户需求。

在上线之后，分答团队基本上保持了每天发布至少3次新版本的节奏在进行更新，这是怎么做到的呢？

除了精益迭代的团队认知之外，还有一个产品形态的选择也是产品能够快速迭代的基础。分答第一版的产品形态不是基于手机的客户端，而是在微信环境内使用的一个H5页面，并通过服务号完成通知、支付等服务。

比起直接开发手机客户端，用基于微信服务号进行开发有几个非常明显的好处：

用户使用成本低：不需要下载客户端，打开网页就可以使用

开发成本低： iOS、android客户端两大阵营开发起来就直接双倍工作量，而且还有各种适配问题

迭代成本低： 不需要去应用市场提交新版本，在让用户下载安装包进行更新，直接服务器端进行更新就完成了迭代，用户完全无感迭代

用H5版本进行开发，极大地降低了开发和迭代成本，在微信环境里，入口虽然深，但通知和交易闭环都是完整的。

上线并不意味着战斗结束，如何精准、高效地记录和分析产品数据，通过对产品数据和用户数据的精益分析去迭代产品，则成为了下一个阶段的工作重点。分答团队通过使用第三方数据分析平台，跟踪不同模块的使用频次，监控搜索效率与付费收听流程的转化，通过观察留存来分析各用户群组的复听率、复购率等，不断地观察产品的数据表现和了解用户反馈去迭代产品。

就这样，分答在短短6周内通过敏捷开发的方法创造了知识分享领域的“数据增长神话”。