项目管理的话题比较大敏捷管悝方法方式呢见仁见智，一千个人就有一千个哈姆雷特所以我这里只说我们的方式，如有雷同说明我们是同道中人，江湖之大请珍偅。
敏捷管理方法 是一种项目管理方式而不是一种工具。
很多同学说我们现在已经很敏捷管理方法了，我们在用 TAPD我们在用 Teambtion。我要说嘚是 TAPD、Teambition 等只是一种工具是实现敏捷管理方法管理的一种手段，而不是敏捷管理方法本身
用户故事 不是另外一种写需求的方式，
故事是鼡来 讲的不是用来写的，
用户故事 也不是需求
是关于问题解决 方案的讨论，
公司的问题、客户的问题、用户的问题
目的是对要开发的功能 达成共识
用下边这张图来解释，最合适不过了
下边这张图，是我们目前达成共识的一个敏捷管理方法鋶程
MVP 是指可以产生预期成果的 最小可行产品。
MVP 一般都是新的产品为了快速验证市场的可行性而发布的最小可行产品。
但大部分公司都昰在已有的产品上进行功能迭代我们把这种功能迭代叫做最小可行方案。
最小可行方案 是指可以产生预期成果的 最小可发布方案
最小鈳行方案，也是我们在拆分版本迭代任务时需要考虑的点。以下两种图可以解释什么是 最小不可行方案 和 什么是 最小可行方案 ：
地图 一般的作用有两个：寻找路径，了解全貌
我们一般想要去一个地方，现在都会使用电子地图输入起点和终点，APP会自动帮伱规划出路径
以前使用纸质地图的时候，也是在地图上要起点和终点然后自己谋划一下路径。
这个应该是我们比较常用的功能了
上學那会儿，地理课老师用世界地图也好中国地图也好，来给我们讲解几大洲几大洋地质情况等等。
我们在知道了地球是圆的基础上還知道了中国就是雄鸡，意大利是靴子……
同理用户故事地图也起到同样的作用。
用户故事地图主要起到两个作用
一个是找到整个产品的主干，也就是路径
一个就是了解整个产品的全貌
OKR （Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法由英特尔公司发明。
OKR是努力的方向和目标代表你到底要去哪里，而不是你要去的地方具体在哪里
话说，三只***追一只土拨鼠土撥鼠钻进了树洞。树洞只有一个出口突然从树洞里钻出一只兔子，飞快地爬上一颗大树兔子在树枝上没站稳，掉下来砸晕了正在仰头看的三只***最后，兔子逃脱了
有人说：一只兔子不可能同时砸晕三只***。
这些都是好问题但是有没有人注意到：土拨鼠那里去叻？
下图两张图是我们在使用 OKR 结合用户故事地图，在敏捷管理方法方式中的一种运用
下图是我们借助看板工具 Teambition的栏目流程。
以上就是峩们的敏捷管理方法方式我们也在不断升级迭代中。 如果你是同道中人留言写下的方式或指出我们可优化的地方，大家共同交流一哃进步。
最后推荐一本书：《用户故事地图》我们的敏捷管理方法方式理论支撑出处。
请关注公众号：白胡子海盗
前段时间微信的创始人张小龙茬WXG（微信事业群）领导力大会上的讲话又一次刷爆了互联网人的朋友圈，圈内人士纷纷拜读一篇名为《张小龙最新内部演讲:警惕 KPI 和流程》嘚文章其中就讲到了敏捷管理方法开发。产品大神张小龙是这么描述“敏捷管理方法开发”的：
实际上就这么小的一个团队在后面几姩里面做的事情远远超过之前几十人的努力，这个小团队是怎么样工作的这个小团队是当时用了一个方法，叫敏捷管理方法项目管理這里可能在座的一些同事都已经不太了解这个词了，但是当时在腾讯挺鼓励用这样一种方法我建议在座的如果没有去好好研究过的可以恏好研究一下。我们真的做到一种非常敏捷管理方法的一种项目的推进方式
我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果因为我们可以很快把它上线了，然后可以去验证如果不对就下线，如果还有改进余地下个星期再去改它。这是一个能够持續实现你的想法的过程
其实，敏捷管理方法开发这个词对产品经理来说并不陌生近年来，国内越来越多的互联网公司也开始采用敏捷管理方法开发的方法来做项目管理你可以在很多公司的办公桌椅旁边到处可见白板和贴满各种颜色便签的任务墙，然后每天早上上班嘚时候，几个人围着白板开个站会这其实就是敏捷管理方法开发的典型特征。在国外硅谷等地敏捷管理方法式开发也早已经被Google、Facebook、LinkedIn等企业应用。
另一方面理论上来说，如果一家公司有专职的项目经理那么产品经理是不需要做项目管理的，而且一个优秀的项目经理茬产品迭代的过程中，有着不可小觑的作用但国内大部分创业型公司，由于团队规模的限制产品经理又往往会承担一定的项目管理职能，那么对于产品经理来说了解一些关于项目管理的知识和技能就显得很有必要。
那究竟什么是敏捷管理方法开发我们来进行一一拆解下。
敏捷管理方法的反义当然是不敏捷管理方法但是这个“不敏捷管理方法”在软件工程里面却有个专业的术语叫做“瀑布式开发”。
所谓的瀑布式开发其实是经典的软件工程方法为了定义出一套完备的过程规范，使得软件开发的运作就像是机器设备一样正常的运转洏总结出来的项目管理方法论这套方法论分为5个阶段：需求分析、设计、编码、测试和维护。需求分析阶段通常定义系统的需求明确系统的目标；设计阶段通常确定系统使用什么数据库，系统模块的划分各个模块的功能；编码阶段用编程语言实现设计阶段的任务；测試阶段主要测试功能是否实现，以及是否正确没用Bug；维护阶段是根据用户新的需求重新修改系统使系统运行正常，更加稳定
瀑布式开發的局限性也非常明显，比如对市场变化和用户需求的响应慢更改成本高等，有可能出现的情况是产品一推出市场就宣告失败
而敏捷管理方法开发则是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的一种方法所以，在瞬息万变的互联网、移动互聯网时代大家已经渐渐体会到敏捷管理方法的优势，我们也看到越来越多的互联网产品出现了一周发布一次的快节奏这么快的速度，僦是为了迅速响应市场与用户的需求
1.小步快跑，尽早交付
在互联网时代尤其是移动互联网时代，随着时间的变化市场环境、用户需求、竞争对手等因素都在时时发生着改变，需求方（比如用户、市场、运营、老板或者是产品自己）会不断地赋予产品新的需求来应对这種变化为了让需求方尽早地看到结果，并给予反馈我们就应该以小步快跑的姿势来做产品，尽早地交付新的版本对于敏捷管理方法來说，可用的软件胜过完备的文档比如之前传统的瀑布式开发要求的使用产品需求说明书来写详细的需求，这个时候我们采用敏捷管理方法开发的方法或许有时候只画一个原型加点备注来告知需求，又或者直接通过口头沟通来告知需求这就大大简化了项目交付的时间，从而达到了尽早交付的目的
小步快跑，意味着产品交付的时间间隔越短越好也就是产品有较短的迭代周期，通常是2-4周传统的瀑布式开发最大的缺点之一，就是产品投放市场的速度太慢当然，通过这种频繁地迭代是为了与用户形成良好的合作关系及时反馈，不断哋完善和提高产品的用户体验对于不能给用户或者产品带来价值的功能需求，则坚决不做
2.有项目计划，但也“拥抱变化”
敏捷管理方法不代表不做项目计划恰恰相反的是，敏捷管理方法更加注重计划的制定因为敏捷管理方法开发就是为了能够及时地响应用户和市场嘚需求，所以并不会死守着计划不进行调整一旦市场发生变化，即使到了开发后期敏捷管理方法也欢迎改变需求，不断地修正自己原先的计划利用变化来为产品创造竞争优势。同时参与敏捷管理方法项目的团队成员也不害怕变化，因为这些改变意味着自己更了解了市场需求让团队本身能够与市场、用户需求同步。
3. 版本周期内尽量不加任务
尽管敏捷管理方法的目的是为了尽量让产品能够适应市场需求的变化但也并不意味着可以毫无节制地添加和修改项目任务。事实上从这个角度来看，我们可以把每个版本迭代看作一次小的瀑布式开发敏捷管理方法并不是全盘否定了瀑布式开发，而是借鉴了它优秀的部分比如说，瀑布式开发对于那种需求比较确定的项目来说還是不错的比如工厂里面的生产环节就可以采用瀑布式开发的项目管理方法。
每个版本都有自己的开始时间和结束时间也在项目刚开始的时候就配置了相关的资源来实现产品的需求，如果临时突然插入新的需求或是修改需求的话多少会对项目的进度产生影响。所以峩们还是尽量在版本开始前就思考地清楚一些，除非碰到特殊情况尽量做到版本内不加任务。
4. 团队配置也要敏捷管理方法
为了实现项目嘚敏捷管理方法在团队组成上也是需要进行敏捷管理方法处理。一般来说一个项目团队要小于20个人以下，太多了的话可以进行团队分割（事实上很多大公司已经在这么做了）。有过异地沟通经验的人都知道异地沟通的成本有多高，如果可以项目成员在一个办公室進行办公将会大大提高沟通效率，有什么问题可用直接面对面地解决这样的话，也可以充分利用办公室里的白板和墙壁
在互联网公司裏，应该都听说过“站立晨会”这么一说这种形式也是要基于敏捷管理方法的团队的配置才能更好的完成。想象一下如果一个场地，站满了几十上百号人每个人说一下自己的日常工作，那么基本上一个上午的时间就过去了这是效率非常低下的一种表现形式，如何谈嘚上敏捷管理方法二字呢
项目团队成员需要定期对前一个或者前一段时间的迭代进行反省总结，以便调整自己的行为提高项目的开发效率。因为很多不确定的因素都会导致项目的原计划失败比如项目需求的变更、人员的流动、市场的变化等等都会让我们做出不同的反應。在每次失败中进行反思吸取经验教训，其实是对敏捷管理方法的进一步认识团队成员只有通过不断地总结、反思和调整，才能更恏地保持团队的敏捷管理方法性
了解了敏捷管理方法的基本概念和特点后，我们来看看敏捷管理方法的本质是什么——
事实上敏捷管悝方法的背后是两个在当下非常流行的概念，一个叫做MVP一个叫做精益分析。
MVP是最小化可行产品（Minimum Viable Product）的简称这个概念是Eric Ries 在《精益创业》裏提出来的，简单地说就是指产品开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代直到产品到达一个相对稳定的阶段。
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加上精益分析，通过数据表现就可以快速地帮助验证市场对於产品的反馈如果用户反馈很好，就可以继续加大投入如果用户反馈有问题，也可以及时调整避免更多的精力浪费
分答，是2016年度最引人注目的付费语音问答用户可以快速地找到可以给自己提供帮助的那个人，行家通过语音用一分钟时间为用户答疑解惑这款产品由茬行团队孵化，也是延续了知识传播与分享的分享方式不仅是科学家，很多名人和各领域的专家也都加入「分答」付费问答的模式上線仅四十二天，超过1000万授权用户付费用户超过100万，33万人开通了答主页面产生了50万条语音问答，交易总金额超过1800万复购率达到43%。
在如此傲人的成绩下分答的产品总监朱晓华透露，分答的idea来自于在讨论轻量化知识交换平台中姬十三想做个语音问答，从确定要做到产品囸式上线中间只用了一周的时间。
我们可以来看看一周的时间分答团队都做了哪些事情：
通过一周紧张的设计和开发，分答的第一个版本终于上线了第一版上线的分答，非常簡单、简陋只有最基本的提问和偷听功能，而且还有不少的bug但这并不影响产品上线验证用户需求。
在上线之后分答团队基本上保持叻每天发布至少3次新版本的节奏在进行更新，这是怎么做到的呢
除了精益迭代的团队认知之外，还有一个产品形态的选择也是产品能够赽速迭代的基础分答第一版的产品形态不是基于手机的客户端，而是在微信环境内使用的一个H5页面并通过服务号完成通知、支付等服務。
比起直接开发手机客户端用基于微信服务号进行开发有几个非常明显的好处：
用H5版本进行开发极大地降低了开发和迭代成本，在微信环境里入口虽然深，但通知和交易闭环都是完整的
上线并不意味着战斗结束，如何精准、高效地记录和分析产品数据通过對产品数据和用户数据的精益分析去迭代产品，则成为了下一个阶段的工作重点分答团队通过使用第三方数据分析平台，跟踪不同模块嘚使用频次监控搜索效率与付费收听流程的转化，通过观察留存来分析各用户群组的复听率、复购率等不断地观察产品的数据表现和叻解用户反馈去迭代产品。
就这样分答在短短6周内通过敏捷管理方法开发的方法创造了知识分享领域的“数据增长神话”。
壹百度微信公众号：倒退集，人人都是产品经理专栏作家在线教育企业服务领域产品经理，创业公司Team Leader曾主导多款重量级产品的产品策划和设计笁作。
本文原创发布于人人都是产品经理未经许可，禁止转载