有人问: 组织应该如何设计?
有两个潜在的答案,实际上并不像它们在第一个站点上那样矛盾。
第一个很简单:不要。
也就是说,不要设计您的组织,不要制定组织结构图,不要制定计划,并且要根据该计划重组您的组织。
我想这是“设计”(意思是“为您想要的事物的方式制定计划”)和“设计”(意思是“事物的排列方式”)之间的区别。 为了区分它们,第一个可以称为“意图设计”,第二个可以称为“紧急设计”。
这并不一定意味着所有涌现的结构都是好的。 正如我们在代码中看到的那样,紧急设计有时并不总是最好的,随着时间的流逝,它们需要重构。 这意味着在某个时候需要进行故意设计。
这样说:我希望您的组织负责设计,而不是您将设计推送到组织上。
组织结构本身就是业务战略的功能。 两者都需要部分突现和部分故意。 尽管您可能已经注意到,但我趋向于突如其来,而世界上的大多数趋于于有意为之!
因此,帮助您建立一个有关您对组织的看法的参考模型,也许是可以引导组织走向的参考模型。
因此,该问题的第二个答案将更长:
- 创建嵌入业务线本身的常设交付团队。 有时这就是所谓的流团队,或者基于流的开发,或者是“与价值流保持一致的团队”,或者是我现在想到的其他几个名字。
- 每个业务线本身就是一连串的工作,数字交付团队支持该工作。
- 团队拥有完成该业务流所需的所有技能和权限。
- 团队是团队的一部分,因此业务/技术鸿沟应该消除。 我称之为BusTech 。
- 团队追求价值和创造价值:团队寻求机会为企业创造价值并实现最有价值的价值。
- 尽可能将权力下放给团队。 团队是小型企业。 (请注意,我故意不使用授权一词。)
- 当业务成功并且需要更多的数字能力时,团队就会成长。 当资金紧张或需要更少的能力时,团队就会萎缩。
- 团队可能会不时分裂( 变形虫风格 )。 新团队可能在同一业务线(解决另一个问题)中,或者在另一个可能是新业务线的一部分中。
- 主动–或敏捷–项目组合管理位于顶部,以监视进度,提供额外的资源,删除资源等。甚至可能有多个项目组合过程,一个在业务线级别,一个可能在多个业务线之上。
- 最低限度可行的团队开始探索新的计划,有时这些会成为常设的团队,但是如果想法不成立,它们也可能被解散。
- 寻求最小化团队之间的共同服务,因为它们会造成瓶颈,冲突和延误。 每个团队都应该独立。 这可能意味着一些重复,因此会产生一些额外费用,但是请您接受。 一旦您的模型开始工作,您就可以在以后进行微调。
- 不必担心团队之间的计划和同步,也不必担心使团队更频繁地发布并在出现问题时处理同步问题。
无论如何,它们是要点。
翻译自: https://www.javacodegeeks.com/2018/07/organizational-structure-agile-age.html