数字和敏捷时代的组织结构

有人问： 组织应该如何设计？

有两个潜在的答案，实际上并不像它们在第一个站点上那样矛盾。

第一个很简单：不要。

也就是说，不要设计您的组织，不要制定组织结构图，不要制定计划，并且要根据该计划重组您的组织。

而是创造条件让结构出现。

我想这是“设计”（意思是“为您想要的事物的方式制定计划”）和“设计”（意思是“事物的排列方式”）之间的区别。 为了区分它们，第一个可以称为“意图设计”，第二个可以称为“紧急设计”。

这并不一定意味着所有涌现的结构都是好的。 正如我们在代码中看到的那样，紧急设计有时并不总是最好的，随着时间的流逝，它们需要重构。 这意味着在某个时候需要进行故意设计。

这样说：我希望您的组织负责设计，而不是您将设计推送到组织上。

组织结构本身就是业务战略的功能。 两者都需要部分突现和部分故意。 尽管您可能已经注意到，但我趋向于突如其来，而世界上的大多数趋于于有意为之！

因此，帮助您建立一个有关您对组织的看法的参考模型，也许是可以引导组织走向的参考模型。

因此，该问题的第二个答案将更长：

• 创建嵌入业务线本身的常设交付团队。 有时这就是所谓的流团队，或者基于流的开发，或者是“与价值流保持一致的团队”，或者是我现在想到的其他几个名字。
• 每个业务线本身就是一连串的工作，数字交付团队支持该工作。
• 团队拥有完成该业务流所需的所有技能和权限。
• 团队是团队的一部分，因此业务/技术鸿沟应该消除。 我称之为BusTech 。
• 团队追求价值和创造价值：团队寻求机会为企业创造价值并实现最有价值的价值。
• 尽可能将权力下放给团队。 团队是小型企业。 （请注意，我故意不使用授权一词。）
• 当业务成功并且需要更多的数字能力时，团队就会成长。 当资金紧张或需要更少的能力时，团队就会萎缩。
• 团队可能会不时分裂（ 变形虫风格 ）。 新团队可能在同一业务线（解决另一个问题）中，或者在另一个可能是新业务线的一部分中。
• 主动–或敏捷–项目组合管理位于顶部，以监视进度，提供额外的资源，删除资源等。甚至可能有多个项目组合过程，一个在业务线级别，一个可能在多个业务线之上。
• 最低限度可行的团队开始探索新的计划，有时这些会成为常设的团队，但是如果想法不成立，它们也可能被解散。
• 寻求最小化团队之间的共同服务，因为它们会造成瓶颈，冲突和延误。 每个团队都应该独立。 这可能意味着一些重复，因此会产生一些额外费用，但是请您接受。 一旦您的模型开始工作，您就可以在以后进行微调。
• 不必担心团队之间的计划和同步，也不必担心使团队更频繁地发布并在出现问题时处理同步问题。

无论如何，它们是要点。

翻译自: https://www.javacodegeeks.com/2018/07/organizational-structure-agile-age.html