开发诊所_诊所：产品负责人/经理

开发诊所

一个老产品经理朋友写道……。

“刚刚开始了新的演出，担任blah blah的高级产品经理

发现Scrum团队不是围绕产品组织，而是围绕工程组件。 例如，产品经理必须与三个不同的Scrum团队合作：

- 前端

–后端

–数据科学

这使产品经理难以管理，但我认为工程设计更容易。 我以前从未遇到过。 有什么想法吗？

在任何特定的Scrum会议上，可能有两个或更多的产品经理，而不是每个Scrum团队只有一个产品经理。”

好吧，让我们来看看…

该组织是水平组织的，不好–我们回到了康韦定律。 要获得任何有价值的业务价值，可能需要让前端团队去做某事，让后端团队去做其他事情，然后让数据科学团队去做某事……

现在这可能是工作失败的方式。 很可能许多工作都属于一个组件，例如数据科学，仅此一项就能带来业务利益。 如果大部分工作都是这样的，那么横向组织是有意义的。

但是，以我的经验来看，这种情况很少见，您的评论也表明这也是对的。

用用户故事的术语来思考：故事很少与一个功能相关，而您更可能需要每个功能团队的一点点。 没有一个团队可以完成整个故事，他们需要其他团队来做某事。

这使项目经理类型的工作得以完成– 团队A做好了工作，以便团队B可以启动，为什么团队C不与团队A对话？

敏捷人员通常提倡的方法是垂直团队。

每个团队都应配备人员，以实现自身的业务价值：如果每个团队都需要一位代表，那就可以了，如果团队成员需要更多培训或需要获得许可以进入代码的不同部分，则必须这样做。

横向组织并不少见，它通常是基于您需要专家并且专家需要专注于一件事的理由而采用的。 尽管您可能仍需要专家，但您希望人们跨越边界并受到业务优先级的驱动。

然后是产品经理和产品负责人的问题，再也不是……

在这种情况下，产品经理是产品所有者。 拿起Scrum书，将“产品负责人”的每个实例替换为“产品经理”，情况会更加清楚。

并且可以在Scrum会议中有多个产品人员–顺便说一句，当您说“ Scrum Meeting”时，您是指“ Stand up”还是“ Planning”会议？ 无论哪种方式都没关系，每个中可以有两个产品人员。

重要的事情，尤其是在您要召开计划会议时，尤其是：产品人员可以用一种声音说话。

也许他们有一个共同的积压。

也许他们有自己的计划前会议来确定优先级。

也许他们将工作划分为战略产品负责人/经理和战术产品负责人/经理。

也许他们同意一种看待X段，另一种看待Y段，然后比较音符。

但是他们做到了，他们需要用一种声音说话。 他们需要同意。

一个更有趣的问题是：您为什么还要两个？

每个人都专注于不同的市场吗？ 产品的不同方面？ 还是不同的时间范围？

如果您有两个垂直团队而不是三个水平团队，则完全有可能一个PM喂一个团队，另一个PM喂另一个团队。 在这段时间里，他们都走出去看客户，并在他们之间决定什么是长期战略，策略和计划。

翻译自: https://www.javacodegeeks.com/2017/05/clinic-product-ownermanager-question.html

开发诊所