Product Owner工作坊准备

如何准备一个Product Owner工作坊?这里有最详细的攻略。

在准备一个工作坊的时候,除了直接跳入到培训框架和内容的准备外,前期的准备工作中更重要的还包括工作坊目标的澄清,可以用埃里克森教练的四个计划性问题闪亮登场了。
1. 做这个工作坊的目标是什么?
2. 为什么这个目标对于当前的组织和团队来说那么重要?
3. 怎么样来定义这个工作坊就是做成功的?
4. 如何更有效的去交付这场工作坊呢?
 
这四个问题其实都需要去采访利益相关人,他们的想法才是决定一个工作坊是否应该举办或者能够成功交付的关键,而不是培训者想当然去交付一个我认为的Product Owner的工作坊。利益相关者有4类:
1. 研发总监
2. 产品总监
3. 产品经理(对应到Scrum中的Product Owener)
4. 内部敏捷教练
 
1. 工作坊交付的背景
回答第1和第2个问题需要了解下组织当前的背景。作为一个互联网的初创公司,Scrum转型有半年多了,目前有3个scrum团队。宏观上是运用OKR的模式来管理产品的愿景和年度、季度的产品交付目标,微观层面就是应用Scrum来推行产品和团队的开发工作。
 
现状是在OKR和Scrum的衔接过程中,是有割裂的,并没有很顺畅的运作起来。在一个季度开始前的一个半月,每个Scrum团队产品经理会和研发经理,设计师,甚至是团队一起开始调研和整理OKR中Objective和Key Results。有了相对清晰和确定的Key Results后会转化为工程侧可以执行的EPIC,EPIC是史诗级的用户故事,接着需要再Breakdown成每个迭代用可执行的用户故事。
 
我们也借用了ACT中对于需求的沙子(一个idea对于Why,What,How都不清晰)、板砖(idea有了清晰的Why,What和How还需要进一步明确)和钻石(Why,What, How都已经比较清晰,用户故事梳理也达到迭代可执行的状态)的三种状态来管理EPIC的状态,如下图所示。现状是从Key Results转化成EPIC再到用户故事的过程,是现在的一大痛点。比如这个季度已经进行到一半,每个Scrum团队中的EPIC还有一半是在沙子和板砖阶段。更具体的来说,就是每个团队的Product Backlog中没有可供未来2-3个sprint可执行和已经就绪的条目,我们如何去达到这个理想的状态呢?
Product Owner工作坊准备
这个难产的过程中,到底谁应该来负责推行呢?现状是产品经理负责OKR中的Objective和Key Results的产生,研发经理兼Scrum Master来负责把Key Results转化为工程侧的EPIC以及每个迭代内的用户故事梳理。
 
2. 工作坊目标澄清
那理想情况是什么呢?按照《2017-Scrum-Guide》中对于Product Owner的定义如下:
产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨 组织、Scrum 团队和团队成员个体的不同而有所不同。产品负责人是负责管理产品待办列表的唯一负责人。
 
1)内部敏捷教练的目标
作为敏捷教练,其中一个职责是确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值,如果我们的Scrum转型和实践中,产品经理是作为Product Owner这个角色,那我就应该推进产品经理成为产品待办列表的唯一负责人。不过上述的Scrum Guide中确实也提到如何实现这一点根据组织和团队会有所不同。那这个就要和下面的两大利益干系人研发总监和产品总监去沟通,针对现状,我们下一步想要达到的状态是什么?
 
2)研发总监的目标
作为研发总监(也是我的老板),他的想法是让产品经理承担好Product Owner的角色和职责,有效梳理好Product Backlog。而研发经理承担好产品研发的迭代流程、发布和工程改进/技术创新和兼职Scrum Master的角色(由于团队规模和其他因素的考量,目前没有全职的Scrum Master),而团队更加专注的在实现产品的功能上,各司其职。
 
3)产品总监的目标
作为产品总监,当前确实由于业务比较繁多,产品经理要负责的事情也比较多,现状是由研发经理来梳理用户故事,但长远的也还是希望产品经理能够全部承担起Product Owner的职责。
 
4)工作坊的目标
既然和两位大佬都有了一致的预期,那这次工作坊的目的就非常清晰了,如下:
  • 统一部门内不同的角色对Scrum框架和实践的认知
  • 明确Product Owner、研发经理兼Scrum Master的职责(开发团队的职责比较清晰)。强化产品经理作为Product Owner的职责,负责推进生成Product Backlog
  • 重新认识用户故事。Product Backlog作为衡量最后OKR的最终输出,Scrum的输入,怎么去更有效的产出Product Backlog呢?Product Backlog的条目就是用户故事,那我们就需要来重新认识下用户故事。(现状是产品经理更多的是用PRD和研发用技术文档的方式来工作,用户故事的实践只是刚起步不久,有的团队的用户故事更多是一个技术任务)
  • 加速从OKR中的Key Results到Sprint中可执行的Story这一过程(这一点,是我观察到现在团队用OKR和Scrum的一大痛点,我希望通过用户故事地图这一实践来解决这个问题)。PO作为Product Backlog的唯一负责人,PO的工作内容比较繁多,如何让PO不成为OKR和Scrum这一个工作流的瓶颈呢?希望借助用户故事地图这个工具来进行团队协作快速生成高质量和达成共识的Product Backlog。
 
3. 工作坊内容准备
作为敏捷教练,为团队,Product Owner,Scrum Master或者是领导层提供敏捷相关的培训也是一项基本的工作内容。可是作为没有做过Product Owner的敏捷教练来说,要去给一群产品经理专家们提供培训还是非常有挑战的。本来是要请外部的培训师来进行CSPO的培训,可是由于后面经费有限,那就内部敏捷教练上了。关于这个工作坊我做了以下的准备:
1) CSPO培训
参加了Jim Wang的CSPO的培训,主要是了解了在Scrum中Scrum Alliance 对于PO的培训的框架和体系是什么。两天的PO培训包含了以下内容:
  • Scrum的基础
  • Scrum中3个不同角色的职责划分
  • PO角色的定义、职责和活动
  • 产品愿景(工具箱有Vision Box,电梯演讲,杂志采访等)
  • 实验画布(experiment canvas)
  • MVP
  • 产品待办列表,优先级排序
  • 用户故事定义,写用户故事的工作坊,用户故事估算
  • 用户画像
  • 用户故事地图实践规划release和MVP
  • 产品的Roadmap和规划发布
  • Business values排序(工具箱有theme screening, theme scoring, relative weighting)
  • 沙盘演练的团队开发游戏
 
2)梁宁的《产品思维32讲》
这个课程让我了解互联网的产品经理到底需要什么样的技能和思考模式,如何去构建自己的产品能力。梁宁用非常浅显易懂的语言说清了很多产品相关的工作,比如作为一个产品经理如何构建一个真正解决用户痛点和痒点的产品呢?你的产品里面其实是包含你的整个人生阅历在里面,是做一个不痛不痒的产品呢还是做一个让用户超级爽的产品?
关于用户画像中大明,笨笨,小闲的三类划分非常清晰地解读了一个产品到底是针对哪类用户,让用户画像这个实践非常容易理解。
 
3)推广用户故事地图实践
开始时,先是在网站上看了些用户故事地图的资料,也请教了几位敏捷大牛。Lance直接说你就看那两页slides就行,这个简单啊。对于大牛来说,一些都是大道至简。育铭推荐了一个网站,写得很详细。Ella给我了英文版电子书,因为她喜欢看原汁原味的英文版。Lucy说你第一次做这个工作坊,还是去看下书比较好,了解下作者设计的原理等。
 
现在大家可能买了很多专栏或者书籍,这些专栏或者书籍很有可能提供的是是二手、三手知识。而让我们进步最快的方式是追溯知识的源头,学一个东西确实还是从最本源的地方出发去啃下书,这种慢才是最快的方式。
 
Jeff Patton的《用户故事地图》确实是敏捷教练和Product Owner的必读书籍之一啊,非常多的启发,简单的列几点吧:
 
  • 校准了我对于用户故事的认知,以前我对用户故事更多还是刻板的表层的认识,它是一种需求的表达方式,有固定的模板,它是敏捷转型的一个显性标志之一等。但这些其实都不是最重要的甚至一点也不重要,那重要的是什么呢?用户故事是为了让团队在协作中更好的使用它,如果团队没有聚在一起对用户故事进行充分的讨论,就说明你们运用用户故事的方式不对。用户故事的3C对于你的团队就是3条文字的准则,你没有任何体验,就是像陌生的一个公式而已,还是你们就在实践3C(Card,Communication,Confirmation)呢?
 
  • 这幅图完整的呈现了一个产品从一个idea,评估机会,发现MVP,梳理用户故事,迭代执行,迭代评估review,到最后的发布,再到发布后的学习到新的idea,是一个完整的闭环。弥补了Scrum框架和实践这个不完整的体系,Scrum其实已经假设PO正在或者已经准备好一个排列好优先级的Product Backlog,更多的是团队开发和迭代的过程,那前期一些产品规划,设计调研等是没有涉及到的。关键这个图完美匹配了我们的团队目前OKR和Scrum的结合的方式。
Product Owner工作坊准备
4)学习芬兰引导大师Pepe的CSA引导课程
引导对于敏捷教练来说是非常重要的技能之一,这次跟着Pepe系统的学习了引导的实践,发现有了这个技能,很多工作可以举重若轻的完成。还记得那些年开过的N多形式化又没有产出如同鸡肋一般存在的Retrospective的会议吗?没有引导技能的时候,你觉得团队有很多需要改善的地方,你去刻意引导团队或者直接说出这做得不好那还需要改善,团队还不一定买账。
 
有了引导技能,你可以选择合适的工具,先是团队成员发散再收敛到下个迭代中可以去执行的具体行动。在这个过程中,你可以保持中立客观,只是全然相信团队创造一个空间,只有当团队意识到这个问题需要去改进的时候,改变才有可能真正的发生,不是吗?
 
工具本身不是最重要的,更重要的是你观摩和学习到这一领域的Pepe大师级的引导状态,这个更能指导自己前进的方向,真正有效的引导是什么样的?引导师的内在状态决定了一场引导的成败。那种谦逊的态度,我只是一名小小的引导师,重要的是参与讨论的人等。
 
另外对培训和引导非常感兴趣,觉得传统的说教式的培训效果并不理想,想在自己的培训中也运用引导的技术让学员能够有更多的互动性和群体共同激发学习等。这次的用户故事地图其实我也是第一次做,但是我用了引导的方式就是我只拥有流程和大致的指导,内容全然由团队来创造。当你全然相信一群聪明人时,给他们框架和空间,他们就能够自主的学习,去碰撞和激发出新的想法。这样的方式,比传统的我是专家,你们是学生,我来说你来做的方式有效得多。
 
这么一总结,发现为了这个培训还是花了很多心思和时间来准备的。当然,全然的投入到你热爱的事情中,是把一件事情做好的捷径!
 
 

本文来自投稿,不代表TobeAgile立场,如若转载,请注明出处:https://tobeagile.cn/2020/02/19/product-owner%e5%b7%a5%e4%bd%9c%e5%9d%8a%e5%87%86%e5%a4%87/

发表评论

邮箱地址不会被公开。 必填项已用*标注