为产品方法设计组织，第1部分

如果您正在考虑进行敏捷转换，那么您已经了解功能团队。您甚至可以称呼他们/将它们用作产品团队。您可能想知道将所有工作组织为产品工作。

查看您当前的组织

许多组织使用功能来组织人员。 “典型产品开发组织”显示了我最常看到的那种组织。这就是为什么我称其为“典型”。

有一个高级职能经理，其职能是工程或IT或类似名称。在此图中，这就是VP / CIO / CTO。

中层经理（董事）通常反映架构中的各个层次。我在左侧的3层架构中添加了“按功能实现”图像。各种开发主管对应于产品中的各个水平层。

每个董事可能在其“下方”都有几个经理和团队成员。（是的，在组织结构图中，人们实际上是在其名字的下面。这是我们的话语反映我们的文化的一种方式。）

如果您回顾一下典型的组织结构图，则有一个质量检查总监和TechPubs。也许您也有数据库主管。

这是有趣的部分：

每个体系结构层都有一个中层经理，向高级经理报告。

当我们围绕建筑层设计组织时，我们邀请Conway定律参与工作。

请注意，此处没有产品管理和客户支持人员的代表。财务或人力资源或其他“管理员”功能均不可用。这就是我们如何集中“支持”功能并向外界报告损益的遗物。

除了采用敏捷方法外，产品管理（通常通过产品所有者）是高绩效敏捷团队不可或缺的一部分。而且，优秀的敏捷团队通常会在团队附近（即使不是团队的一部分）获得人力资源支持。

“典型”组织中的人员可以为项目使用敏捷方法吗？当然。他们将人们分成团队。运气好的话，这些团队是长期存在的，正如我在Project Work vs. Product Work中建议的那样。

他们可以创造敏捷的转变吗？

也许。员工的组织不会创造支持敏捷文化的环境。

我看到这些问题：

“典型的”组织使用资源效率而非流程效率的思想来构建组织。实际上，组织结构图（即人员的组织方式）与可能的敏捷转型的目标背道而驰。（而且，我们有康威定律，取决于管理人员的数量。）

我们要求人们合作和交付。团队可以使用敏捷方法成功。转型很少成功，因为我们没有改变文化，特别是我们所回报的文化。

以我的经验，除非您更改奖励和表彰系统，否则您将无法进行敏捷转换。

您可能会获得敏捷的项目和程序。您将不会获得敏捷的文化。（请参阅我的“缩放”敏捷系列。）

问题是这样的：如果您想进行敏捷转换，就需要改变文化。

如果我们设计组织以快速创建和交付产品怎么办？请参阅第2部分。

翻译自: https://www.javacodegeeks.com/2018/10/designing-organization-product-part-1.html