（3）一个称职的PO应该做和不应该做的

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所追求的。

３.ＰＯ要和团队紧密工作在一起：

　　ＰＯ要保证足够的时间和team还有客户工作在一起。一方面，PO对产品功能和体验需要决策力，并是最终的权威。另一方面，PO应该具备开放的心态，尊重其他人的想法和意见，在很多细节之处愿意与他人合作，也擅于综合利用他人的智慧，整合出最棒的功能集。PO愿意投入精力和时间，与利益干系人和团队频密地互动，以听取和讨论各种想法及创意，了解开发团队碰到的问题，并频繁检验团队产出的成果，确保能不断把控和调整方向，为了获得最优的研发效果和最大化投资回报。

下面几点是称职的ＰＯ最好不要做的一些行为：

１. 把交付能力作为团队的唯一评价标准：

　　总所周知，ｓｃｒｕｍ团队的ｖｅｌｏｃｉｔｙ是衡量team的一个标准，但不应该是唯一标准。因为team的交付能力是随着团队成熟度的上升而达到一个平衡，不能无限增加。笔者看到很多团队的PO考量团队的时候，如果交付能力多的就是好的团队，交付能力少的就是不好的团队。这样会对团队传输一个不好的信号，就是会在日后的工作中片面强调交付，还有相关的数据，从而使得团队的成长走向一个错误的防线。

2. PO过多参与开发细节：

很多大型企业，PO是由原来团队中的技术专家转型而来，这样的好处是PO对产品技术很熟悉，但是带来不好的一点是在scrum的日常工作中，PO往往会惯性的纠结于各种实现细节，从而让团队觉得PO对团队的工作干涉过多。其实在这种产品开发模式中，PO更应该注重资源的调配和需求还有PB的管理，避免使自己陷入技术细节的讨论。

3. 同时lead多个团队：

很多企业在转型的时候，由于企业文化和产品架构的问题，往往让一个PO带领多个团队，这样的好处是PO可以对多个有关联的团队的工作进度有总的把握，而且能够更好的移除团队之间的相互依赖，但是同时带来不好的一点是由于精力有限，可能无法同时兼顾多个团队的PO工作，顾此失彼。最好的规模是一个PO带2-3个相同领域的团队为合适。

其实要做好一个ＰＯ还是非常有挑战性的一个工作，需要做的和学习的有很多。在这里笔者只是抛砖引玉，希望能够就此和各位爱好敏捷的朋友深入的讨论下去。

下一篇准备讲一下“”神坛上的SM“”