组织树设计_设计产品方法的组织，第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

组织树设计