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

0 评论 3915 浏览 20 收藏 12 分钟

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

做产品时,你是否遇到以下这些情况?

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

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

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

01 敏捷

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

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

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

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

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

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

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

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

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

02 实施敏捷

关于敏捷开发,有个著名的敏捷宣言:

  • 个体和互动高于流程和工具:相对于繁琐的流程和固定的工具,个人的主观能动性和团队之间的良好互动,更有利于敏捷。
  • 工作的软件高于详尽的文档: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进行验收。

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

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

03 敏捷和瀑布

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

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

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

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

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

04 写在最后

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

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

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

相关文章:

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

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

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

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

 

作者:刀哥;公众号:刀哥说。

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

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

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!