PO在scrum中是一个很重要的角色,很多公司在转型敏捷的时候,往往忽视了对PO的重视和培养,从而使得scrum团队在管理需求,创建用户故事和交付产品时候产生了很多困惑和混淆。那么今天我们就讲一下如果做一个称职的PO
首先我们用一个小故事来解释一下PO和团队的关系吧。
有一天,一个人从客户手里拿到了一个项目,那么他就是PO,他需要一个团队来帮助他完成这个项目,这个时候有S(crum)和W(aterfall)两个团队, S团队承诺每个月都可以交付一点功能(虽然不完整),PO可以拿这个功能去跟客户换一点钱回来。W团队则说6月之后把产品所有功能都做好,一次把钱拿到。
如果你是PO,你需要什么样的团队呢?
从上面可以看出来,PO和团队的关系可以简单理解为PO把产品需求给团队---团队交付合格的产品。
所以我们可以看出,作为开发团队的开发列表输入源头,PO实际上负责把产品的价值和开发团队的工作价值最大化。
在实际工作中, PO的职责可以参考下图:
既然PO的职责和工作内容如此重要,我们怎样才能做一个称职的PO呢。作者参考以往参加过的企业敏捷转型经验,总结出以下几点(并不限于):
1. PO要有很强的领导力:
PO应对产品表现出热情和信念,对于这个产品/版本带来的价值表现出强烈的信心。优秀的PO能从“为什么”开始,来传递和解释产品的定位及其核心功能的思路。PO还能感召团队,调动团队成员为其开发这个产品/版本的兴趣,同时对开发出来的成果制定高的期望,包括质量的标准和用户体验等等。但是这个地方要注意,领导力并不代表管理,PO虽然领导团队,但是并不对团队进行管理,团队应该是自组织和自管理的,很多企业转型的时候,因为PO是由原有的PM/Manager/Leader等转变而来的,所以天然带有授权管理的能力,这样就造成team实际上和PO形成了report的关系,这是scrum所不提倡和不推荐的。
2. PO要能对目前PB负责:
PO要不断地梳理Product Backlog,并做出正确的决策。极优秀的PO勇于去说“不”,去做减法,因为PO要面对大量来自不同干系人的声音和信息。好的Product Backlog管理不是左右逢源,PO应该不允许PB无休止的膨胀,而应该能让团队工作聚焦,全力以赴地关注最重要的东西。附和及迎合所有人的意见的产品管理不是最优秀PO所追求的。
3.PO要和团队紧密工作在一起:
PO要保证足够的时间和team还有客户工作在一起。一方面,PO对产品功能和体验需要决策力,并是最终的权威。另一方面,PO应该具备开放的心态,尊重其他人的想法和意见,在很多细节之处愿意与他人合作,也擅于综合利用他人的智慧,整合出最棒的功能集。PO愿意投入精力和时间,与利益干系人和团队频密地互动,以听取和讨论各种想法及创意,了解开发团队碰到的问题,并频繁检验团队产出的成果,确保能不断把控和调整方向,为了获得最优的研发效果和最大化投资回报。
下面几点是称职的PO最好不要做的一些行为:
1. 把交付能力作为团队的唯一评价标准:
总所周知,scrum团队的velocity是衡量team的一个标准,但不应该是唯一标准。因为team的交付能力是随着团队成熟度的上升而达到一个平衡,不能无限增加。笔者看到很多团队的PO考量团队的时候,如果交付能力多的就是好的团队,交付能力少的就是不好的团队。这样会对团队传输一个不好的信号,就是会在日后的工作中片面强调交付,还有相关的数据,从而使得团队的成长走向一个错误的防线。
2. PO过多参与开发细节:
很多大型企业,PO是由原来团队中的技术专家转型而来,这样的好处是PO对产品技术很熟悉,但是带来不好的一点是在scrum的日常工作中,PO往往会惯性的纠结于各种实现细节,从而让团队觉得PO对团队的工作干涉过多。其实在这种产品开发模式中,PO更应该注重资源的调配和需求还有PB的管理,避免使自己陷入技术细节的讨论。
3. 同时lead多个团队:
很多企业在转型的时候,由于企业文化和产品架构的问题,往往让一个PO带领多个团队,这样的好处是PO可以对多个有关联的团队的工作进度有总的把握,而且能够更好的移除团队之间的相互依赖,但是同时带来不好的一点是由于精力有限,可能无法同时兼顾多个团队的PO工作,顾此失彼。最好的规模是一个PO带2-3个相同领域的团队为合适。
其实要做好一个PO还是非常有挑战性的一个工作,需要做的和学习的有很多。在这里笔者只是抛砖引玉,希望能够就此和各位爱好敏捷的朋友深入的讨论下去。
下一篇准备讲一下“”神坛上的SM“”