产品经理如何利用敏捷思维进行版本迭代？

编辑导语：产品经理在日常工作中总会遇到很多需求，一些需要改动或者更新迭代的需求要特别注意，不然很容易出现bug，导致后期问题频繁；本文作者分享了关于产品经理如何利用敏捷思维进行版本迭代，我们一起来学习一下。

做产品时，你是否遇到以下这些情况？

• 需求反复变动，改某一处逻辑，开发的工期就得加倍，项目无限延期。
• 开发做出的项目，bug不但多，而且经常改不好，常常是改了一个bug，又出现另外一个bug，好不容易把一个bug改好了，过了没多久又重现；原本好好的功能，反而因为改bug导致出现更多问题。
• 开发完全不按PRD做，前端逻辑没搞清楚，就按着视觉稿写代码。最终做出来的东西不是产品经理想要的，两边理解的完全不一样。而项目已经开发完了。
• 项目延期不是最坏的结果，更坏的结果是还不知道项目到底要延期多久，没办法准确的衡量工作量，团队成员加班加点，态度端正，精神可嘉，搞但就是搞不懂问题到底在哪里。
• 团队战斗力每况愈下，经常对着干，在项目群打字说话阴阳怪气，不爱语音沟通，各自单干，出现问题后第一时间甩锅，不是我的问题，后端说是前段的问题，前段说是后端的问题。

如果你遇到以上一个或多个问题，那么多半是开发模式存在问题。

最近笔者接触一个项目也遇到了以上问题，于是花了一些时间研究， 发现敏捷开发，是解决这些问题最好的方式；这篇文章，分享下敏捷相关的理论。

敏捷，字面意思是迅速、灵敏的意思，如：行动敏捷、思维敏捷；敏捷通常用于描述快速而灵活的完成某件事情。

敏捷开发，就是快速而灵活的完成开发。在几十年前，互联网项目刚刚起步的时候，做一个系统需要几个月或者几年；这类项目，与传统的建筑或工业项目类似，需要严格按照计划、分析、设计、实施、维护的流程，不能随意变动。

但随着互联网的发展，市场变化越来越快，互联网项目必须快速响应市场变化，传统的这种开发方法已经变得笨拙，敏捷才能快速响应变化。

敏捷有2个特点：『增量』『迭代』；增量是指价值的增量，即每个版本的迭代，都可以带来价值的增量。

价值分为用户价值和产品价值，用户价值是从用户的角度，新增的功能/内容，对用户能够带来某些价值，这些价值可以用经济学中的效用来体现，常见的效用如：货币、时间、情绪等，增量的用户价值可以是增加收入或降低成本。

产品价值是从平台/产品的角度来说的，是所有用户价值的总和，产品价值=(新体验-久体验)-迁移成本；从另外一个角度来说，产品价值还代表着对公司的贡献，比如带来收入、实现社会价值等。

总之，每个版本的迭代，一定能带来增量的价值，如果不能，这个版本是没有意义的。

敏捷的另一个特点是迭代，迭代的核心思路是小步快跑，有句话说的好，好的系统是迭代出来的，而不是架构出来的。

快速打造MVP，然后投放市场，快速试错，当产品方案和问题匹配时，再扩大市场规模，当产品方案和市场匹配时，再进行更大规模的扩张；小步快跑的迭代，是实现精益创业最好的方法。

关于敏捷开发，有个著名的敏捷宣言：

• 个体和互动高于流程和工具：相对于繁琐的流程和固定的工具，个人的主观能动性和团队之间的良好互动，更有利于敏捷。
• 工作的软件高于详尽的文档：PRD写得再完美无缺，如果做出的产品漏洞百出，逻辑不同，也无济于事，敏捷更强调最终的产出，而没那么关注过程；笔者之前就遇到过这样的情况，PRD写得非常细，但研发测试粗心大意，没按需求实施，导致最终做出来的产品，bug非常多，不尽人意。
• 客户合作高于合同谈判。
• 响应变化高于遵循计划：互联网项目，具备短平快的特点，变更需求经常发生，实施敏捷的团队，能响应变化，而不是一成不变的遵循计划。

敏捷，强调的是一种思想，类似于面向对象，具体要实施敏捷，有多种实施的框架，最常用的是Scrum，我把Scrum简单的梳理成了几个部分：两个工件、三个角色、四个会议，简称二三四。

1）两个工件：需求列表Product Backbog、迭代(冲刺)计划Sprint Backbog；产品经理将收集到的用户需求，汇总到需求列表，然后从其中选出优先级高、有价值的需求，组成迭代的版本计划。可以关注刀哥公众号（刀哥说），获取需求列表模板。

2）三个角色：产品负责人（Product Owner）、敏捷教练（Scrum Master）、技术团队（Team）；产品负责人通常就是产品经理，敏捷教练是团队的服务型领导，负责团队协作、组织会议、处理相关问题等，技术团队包含前后端、UI、测试、运维等所有实施角色。

PO的重要性，不亚于一个技术团队，PO主要对产品价值和验收负责，如果提出的需求没有价值，相当于整个版本的迭代就是在白做；所以，作为产品经理，一定要把更多的精力放在『如何实现用户价值/产品价值』上面，画原型、做项目管理都是过程而已，PO要拿结果说话，对价值负责、对技术团队负责。

产品经理如果一直把精力放在功能设计、产品设计上面，很难有提升，要提升还得多关注用户和产品价值，产品大佬唐韧把产品分成四个阶段，你可以对比下当前处于哪个阶段。

3）四个会议：迭代启动会、站立会、评审会、回顾会。

迭代启动会是PO给技术团队过需求，需求有问题PO进行调整，直到完全澄清，然后技术团队开始评估工期。

站立会是在迭代周期内，相关成员每天早上开站立会议，一般不超过5分钟，成员依次描述昨天已完成工作、今天计划、当前问题。

评审会是有技术团队给PO演示开发成果，由PO进行验收。

回顾会议则是迭代版本上线后，收集本次迭代的问题，提出建议，以便下一次更好的合作；如果当前版本有遗留问题，则将问题加入下一个版本的需求列表。

敏捷和瀑布是两种开发模型，瀑布模型更像是传统建筑工程的模型，这种模型强调步骤和过程，每个阶段都需要输入详尽的文档到下个阶段，下个阶段才能开启；比如拿盖楼来说，没有设计图纸，就不能开工，并且设计图纸一旦确定，是不能轻易变动的。

在传统的软件时代，也更多的采用这种模型，但这种模型有个最大的问题是，不能拥抱变化，一有变化，将付出巨大的成本。

而敏捷开发，则更多强调拥抱变化，PO、SM、Team做为一个团队，彼此相互合作，为最终的结果负责，没有绝对的中心，每个人都是中心，技术团队会思考业务，PO也会思考技术；总之，大家都为最终的价值和结果负责。

去年看过一本书，叫《赋能》，里面说到一个很重要的理念，叫『扁平化、去中心化、赋能』，敏捷开发，就符合这个理念。

当然，不是说瀑布开发就完全没有价值、不能采用，在做外包或者规模巨大不易变化的项目时，瀑布开发也有其应用场景。

做产品，很讲究一个节奏感，有节奏感的产品，才能稳定的产出价值，而这个节奏感，很大程度来源于对版本的把控。

产品经理一定要做好两件事：需求分期、价值优先级判断；能做好这两件事，产品能力才会稳步上升。

而敏捷的这种思想，对产品做好这两件事情，是很有帮助的，一定要熟练掌握敏捷思想，善于利用SCRUM框架方法，远离无限延期，摆脱甩不完的锅。

相关文章：

产品经理怎么做可行性分析？

7年产品经理的工作流程，与你分享

产品新人没有完整项目经验？这篇文章帮你打开思路

PRD到底该怎么写？更全面的文档范例来了

作者：刀哥；公众号：刀哥说。

本文由 @刀哥 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。