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