难以察觉的产品负责人
本文由PSTs Sjoerd Kranendonk和Wilbert Seele共同撰写。
在Scrum指南中，关于PO的角色有如下描述:“产品负责人负责最大化产品价值和开发团队的工作。”为了让产品负责人取得成功，整个组织必须尊重他或她的决定。产品负责人的决定在产品待办事项列表的内容和顺序中可见。没有人被允许告诉开发团队从不同的需求集工作，并且开发团队不被允许根据任何人所说的采取行动。
在实践中，这通常意味着产品负责人开始扮演开发团队的守门人的角色。一开始，这甚至可能不是坏事。让所有涉众与开发团队的沟通都通过产品负责人进行，可以让开发团队专注于他们在Sprint中打算做的工作。如果开发团队的流程经常被新请求打断，这可以创造一种平静的感觉。但如果保持这种状态，它就会变得不那么有用。
在某种程度上，这就是为什么我们希望产品负责人不那么“显眼”。不是说不存在，而是说涉众和开发团队应该在产品负责人的帮助下直接互动。就像Kniberg在他的《产品所有权》一书中所说的那样:产品负责人能够促进开发团队和利益相关者之间的沟通。
实现开发团队和涉众之间的沟通意味着从Scrum Master的书中学习一页。当涉众与团队协商时，试图不断地进行沟通或照顾涉众，会导致产品负责人疲劳和信息流的瓶颈。不要在每次交流中都被需要，以促进为目标。这意味着要确保沟通达到3个目标:
1.它会在需要的时候及时发生(不会阻塞开发流程);
2.沟通双方都了解自己的角色和责任(明确责任及其界限);
3.结果是充分理解交付有价值的产品增量(对项目目标的共同理解)。
传奇的产品负责人通过在尽可能多的领域分散沟通和决策来管理价值的交付。他们不怕把权力下放到有信息的地方:让相关人员决定什么对实现更大的目标是重要的。正如大卫·l·马凯所写:给予控制权，创造领导者"．
采用这种方法进行产品所有权是有价值的，因为:
没有单点故障
- 您是企业开发的重要产品的产品负责人。你已经让自己成为价值交付过程中的关键。你过马路的时候也忘了看两边，结果没看到那辆公共汽车开过来。所以接下来的六周你都要在医院里现在产品会发生什么?产品上的愿景是否足以帮助开发团队完成接下来的几个sprint ?特别是当开发团队不习惯与其涉众紧密合作，甚至不习惯说彼此的语言时?有风险的,对吧?然而，如果你花了一些时间来培养他们的关系，那么对产品愿景的清晰理解可能就足以让事情保持正轨，直到你恢复。
持续的团队成长
- 开发团队成员的职业前景如何?就此而言，产品负责人的职业前景如何?Scrum并没有说太多，只是说团队会成熟，他们交付的质量也会随之成熟。成熟不仅仅是技术技能，它还包括通过理解Scrum团队作为一个整体正在开发的产品来获得更多的所有权。允许开发团队的个人和涉众之间的交互意味着您可以自由地花更多的时间在产品的愿景上，但也可以熟悉产品所有权的更广泛的元素，例如跟踪您的sprint的总拥有成本和投资回报。这意味着你可以成长为Scrum在成熟度曲线末端看到的“创业产品负责人”。但只有在Scrum团队的其他成员和你一起成熟的情况下，你才能这样做，而这只有在你让开的情况下才会发生。
增强团队对价值的理解
- 当待办事项项不够清楚时，授权的开发团队将直接与受影响的涉众协作，以适应他们新发现的见解的解决方案。以这种方式工作，团队成员可以直接了解对涉众有价值的东西。换句话说，通过放松对价值导向的控制并让开道路，团队可以通过更少的交接和更少的多层解释来验证他们的假设。然而，只有当所有参与的人都在共同的愿景或战略上工作时，分散的决策才会产生大量的利益。如果在更大的目标中没有这种清晰度，就不会有一致性，导致混乱的方法:缺乏重点，阻碍团队“作为一个整体行动”。另一个好处是省去了“中间人”，可以减少等待时间。这样，产品负责人就可以将时间投入到其他活动中，例如在一个更大的产品开发工作中与多个开发团队合作。请注意，虽然开发团队可能会做待办事项管理相关的工作，但产品负责人仍然负有责任!
所以，亲爱的读者们，这是我们送给你们的礼物:核心收获。如果你的野心是成为一个传奇的产品负责人，不要阻碍开发团队和利益相关者之间的互动。记住敏捷宣言:个人和交互胜过过程和工具。作为利益相关者和开发团队之间的纽带可以是一种促进协作和共享理解的好方法，特别是在一开始，如果你仍然是唯一的沟通者，这将使一个过程抑制对提高敏捷性至关重要的交互。