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

刀哥 2023-07-27 17:19:47

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

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

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

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

01 敏捷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

产品经理，产品经理网站