“假敏捷”到“真敏捷”:产品经理与敏捷相爱相杀的岁月

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

做任何改变都是需要付出一些代价的。

从半年之前,为了快速相应市场的变化和为无数的ABtest做基础准备,产品开始初步响应敏捷的速度,版本由每月一个发布改为做每周一个版本。

一个月之前,团队迎来了敏捷教练,在敏捷教练的带领下,我们逐步由“假敏捷”渐渐开始尝试 “真敏捷”,作为产品经理的我,也开始了和敏捷相爱相杀的过程。

这里总结和分享下:

  1. 什么是假敏捷和真敏捷?
  2. 用户故事的魔力
  3. 敏捷中的团队精神
  4. 敏捷给产品经理带来的成长。

一、真敏捷还是假敏捷?

事业部是在去年年底开始实时每周一个版本的迭代,那个时候,在全公司我所在的项目组是第一个开始做频繁发布的。

在变幻莫测的互联网环境下,快速的响应和发布是非常必要的,并且能得到ABtest的快速验证。

但是在这种快速迭代的初步尝试中,团队慢慢出现了一些问题。

1.假敏捷-7个团队各自为营

我们从一个需求从产生到落地的过程来看,首先需求的来源有一些问题。

3月份在敏捷诊断的时候,几乎所有的产品都把最需要解决的问题投给了“产品定位”。

产品定位可以没有明文规定,但是在快速奔跑的过程中,每个人都要有一致的目标。

当项目组的每个人对产品的理解不一致的时候,我们传达给用户的,也是一些非常矛盾的东西。

举个例子,本着一个服务于全球女性的APP,在一次商务的合作当中,商务的同学拉来的合作是“恐怖电影”。可想而知用户看到了这些启动页广告、banner大图的时候被惊吓的状态。

同时,需求的产生是在每一条业务线中产生的;按照不同的业务线,产品、开发、测试被分成了7个团队,团队之间更多的是一些同步的工作,缺乏沟通和讨论。

没有总体的共识,一个APP被分为7个团队,需求的产生比较分离,没有重点。

在需求迭代的过程中,每个组是只有一个开发和测试加入到需求讨论中,最后把会议精神带回团队;更多开发和测试的同学是直接按照PRD进行开发和测试的——团队缺乏沟通,对需求细节的把控没有那么到位。

最后,在需求交付的时候,功能核对大概几种是在上线前1-2天。

这会导致很多风险项都没有办法提前暴露,需求理解不一致的情况没有办法得到有效的处理。

2.真迭代-两个团队试点,每周一个敏捷冲刺

敏捷项目启动初期,在面对一个需求从开始到落地的五个环节:“产品定位”-“用户定位”-“需求挖掘”-“需求开发”-“需求跟踪”时,几乎项目组所有核心人员都把最紧急、最缺失的一票投给了“产品定位”。

我们发现,因为没有清晰的产品定位,所以每个人的着力点是不同的;大家像一盘散沙,看似忙碌充实却绵软无力。最致命的是:因为没有清晰的RoadMap,大家走一步算一步的状态影响团队士气和凝聚力。

于是,产品团队利用将近一个月时间的依据公司战略、产品目标、用户需求和市场环境确定了清晰的产品定位“打造用户的专属摄影师”,以及根据产品定位确定了接下来1-2年的长期目标和近三个月的短期目标。同时,每条线也根据共同目标制定了版本迭代的计划。

“计划的结果是无意义的,价值在与计划的过程本身”,在互联网瞬息万变的环境下,RoadMap肯定是会变的,但RoadMap能够让全项目成员做到“心中有数”,往同一个方向一起冲刺,这就是它最大的价值所在。

在同一个产品目标下,我们把小组分为几个线,在产品内部共同讨论下形成了需求池。

在需求迭代对过程中,我们也发生了一些改变。

例如产品经理开始用用户故事去表达和拆解需求(用户故事会在接下来展开来说),基于用户故事,开发测试的同学参与到了需求细节的讨论中,逐步达成共识。

在需求交付时,大家能够按照故事点做得点对点的每天交付,甚至为了迭代目标的达成,出现交叉开发、交叉测试的现象。

3.Srum Master是谁?

在需求迭代和落地的过程中,敏捷引进了一个非常重要的角色“Scrum Master”(以下简称SM);项目组渐渐弱化项目经理的角色,开始培养每一个团队的SM角色。

SM是一个对产品迭代推进帮助特别大的人。

目前跑下来在产品看来,SM可以帮忙解决这样几个问题:

  • a.服务产品,确保每个团队成员都尽可能的理解目标和需求细节;
  • b.服务开发,移除开发工作中的障碍,帮助开发梳理交付流程;
  • c.服务组织,带领每一个迭代的进行并持续提升效率。

SM和传统的项目经理最大的区别在于:驱动形式不同。

项目经理是以任务范围驱动时间和资源成本,而SM则是要以时间去驱动任务范围,保证产品以一个节奏持续得往前走。

在敏捷框架下,每周一个迭代是死的(这个死是相对的死,可以根据实际情况做调整)。

每个团队都像赶火车一样在固定的时间点上车,如果没有赶上,把优先级高的需求先保证发布,这样就能保证我们总是在做有价值的事情。

所以每一周,我们就是一个冲刺——时间点基本上是固定的,整个产品是有节奏的一步一步向前。

二、用户故事的魔力

第二部分,想分享一下敏捷实施以来,产品这边最大的一个感受:需求思考和表达的维度从原本的流程图变为了用户故事。

我们首先来看一下:用户故事解决了一个什么样的致命的问题。

我们必须承认的是:文档并不等于共识。

在敏捷的框架中有一个价值观——可交付的版本大于详尽的文档。文档写得再详尽,如果团队成员不够理解,在快速的迭代开发中会大大的影响效率和交付的质量。

我们看这样一张图,当需求评审的时候,大家都说“我懂了”,但是在每个人心里,其实对需求的理解是不一致的;大家需要通过反复的沟通去保证,每个人心中对细节的把控大体一致。

不能够出现产品经理、开发、测试在进入迭代的过程中,最后的交付和产品的预想不一致。

用户故事就是一个梳理需求的框架,它最大的价值是能在迭代开始之前,用这个框架让团队成员迅速对需求达成共识。

用户故事到底是什么样的呢?就是:一个角色,需要完成什么样的活动,最终达成什么样的目的。

例如,作为<一个用户>,我想要<快速拍到好看的照片>,以便我<能够在 朋友圈里分享我的生活>。

用户故事是一个帮助产品和团队梳理需求的一个很好的框架,我们来看一个实例:

左边是用“界面框图+跳转逻辑+逻辑细节”组成的需求,右边是用用户故事+界面框图表达的需求,我们会发现,左边的表达逻辑比较零碎,而右边结构清晰,考虑到所有的场景不会产生遗漏。

用用户故事表达需求的时候,我们会发现用户故事的几个大优点:

  1. 测试和开发不一定有产品视角,但一定会有用户视角,用用户故事去梳理需求能够让大家对该需求的理解更加迅速、深入。
  2. 按照场景拆分,需求在整理把控和细节处理上更容易暴露出问题。
  3. 拆分之后,按照提供给用户的价值划分优先级,甚至帮助产品找到MVP。
  4. 按照用户故事做后期的迭代交付。

三、敏捷中的团队精神

敏捷走了一个月的时候,我们开了一次总结会,回顾敏捷前、敏捷后、敏捷中你认为最大的变化。开发、测试的同学都在最大的变化的关键词几乎都写上了同一个词,那就是“参与感”————之前的需求评审的时候,产品和开发、测试有一种对立的感觉。

产品像是接受检阅,开发和测试像是被通知。这是一种很神奇的社会心理,当人拿出一个经过自己谨慎思考的方案的时候,其实是难以接受修改和质疑的。

产品经理面对一个自以为很周全的需求的时候,实际上把需求框住了,把自己的思路和别人的思路一同框住。一旦别人提出一些质疑,会本能的抗拒,这是一种思维定势练。

需求应该是在团队的讨论下涌现得到的,这个团队不仅包括测试、开发,也包括团队里的任何一个角色。

产品把控方向,团队在讨论中不断得巩固和涌现细节。而且在讨论的过程中,我们经常会发现,开发和测试的同学也会有一些新奇的创意,其实他们渴望表达,渴望产品听到他们的意见;并且产品的方案如何落地,细节的部分开发、测试同学会更了解并提出宝贵的想法。

非常感动的是:有一次一个需求delay了,其实我知道是因为产品在迭代的过程中对需求做了一些调整,但是那个开发的哥哥在回顾的时候,并没有cue到产品,而是自己默默撑起了这口锅。

当然我也做了自我的检讨,但是整个回顾会的过程就会让人觉得:大家是一个集体,没有人会默默甩锅给别人。

四、敏捷给产品经理带来的成长

在敏捷的大框架之下,对产品经理有了更高的要求。

不仅是对需求细节对把控能力,更是对整个产品方向和roadmap的把控能力都需要产品经理跟随敏捷的节奏一起成长。

在这短短一个多月的时间里,非常有幸能够参与到敏捷中,同时我也切切实实的感受到了一些成长上的变化:

1.在需求的不断拆分中重新思考需求的价值。如何在有限的时间里做最有价值的事情,如果需求可以拆分,那么MVP是什么?我们在用户视角去拆分需求的时候,会重新定义MVP。

2.用户故事,强迫产品经理始终从用户视角和用户使用场景去思考需求的价值,这个思维转变非常重要。

3.让产品经理从全局和细节对需求有更多的思考。(1)全局的场景拆分(2)注重验收标准的细节,如果丢失重要的细节部分,产品经理需要背锅

4.团队沟通,带团队的能力得到锻炼。让产品经理更参与到团队协作的方式中和团队文化建设的氛围中,我觉得为未来做一个管理的角色有铺垫作用。

做任何改变都是需要付出一些代价的。

例如产品的发版节奏被打乱,团队的工作方式方法被打乱,甚至会出现刚开始做敏捷时团队的产出效率变低,这都属于正常的“学习曲线”。

经历过一番痛苦的挣扎,我相信在正确的使用敏捷后,团队中的每个人都能收获一定的成长,产品也能在这样的思路和框架下有更大的提升。

 

作者:小梅梅,美图公司产品经理

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

题图来自 Unsplash ,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 我们最近也在实践敏捷开发。说的很好。

    回复
  2. 刚入职4个月的产品小白,看了产品姐姐的所有文章,你的理解真的对于我的阶段来说真的太有帮助了,公司也采用敏捷开发,可惜了公司变动太大,各个leader都相继离开,暂时默默背起了产品经理的锅,没人带让我觉得好孤助无援,似乎是为了敏捷开发而完成用户故事,特别想换到一家能站在巨人肩膀的地方学习,而不是现在的瞎琢磨 同在软件园二期 然而,似乎公司对产品小白不太友好,面试屡屡受挫,当仅能完成二次需求落地任务的助理却总被面试官无情伤害,他们希望我有远观产品的思维以及长远规划,让我对产品道路越来越没信心

    回复
  3. 做任何改变都是需要付出一些代价的。感觉你的理解非常到位。

    回复