Avishai Ish-Shalom是Fewbytes的CTO和的联合主办人，他在最近的上谈到，在当今基于云的、面向服务的世界里，（译注：指对敏捷形式的追捧）。

Ish-Shalom解释说，在高可用的环境中，组织从卖软件产品转向卖服务，导致产生了大量的运维任务。这里面的大部分工作没法提前计划也没法统计。而这些工作又导致了延期，甚至在某些组织里导致了。只有搞定了运维任务和扯皮的事情之后，大家才能致力于业务和IT项目。

在应对快速变化上，敏捷方法可能有用。但如果只是简单地、没有调整组织来应对大量的业务需求、服务需求和运维工作的本质，也会导致同样的老问题：，互相指责、缓慢的交付/反馈。组织需要从对敏捷的“船货崇拜”，转变为持续调整和重组团队，从而交付。

InfoQ问了Ish-Shalom一些关于定期重组组织的实际例子：

\

很多公司尝试了不同的事情，比如；或者，让他们成为自组织的团队；分布式公司也不错——37Signals也是个很有趣的例子。还有些公司会让员工在不同团队间定期轮岗。

\

很少有团队是真正自组织的，Ish-Shalom补充说。团队通常是由高层管理者从功能或工具的角度来定义的，这样一来，两个孤立的团队之间就会产生明显的边界，进而导致过度的切换和，拖慢整个系统的速度。

\

我认为，首先要认识到，文化和组织结构需要一直变化，而且你需要更主动地面对它。通常，人们意识中已经有了“敏捷性”，但却被管理层阻碍了，管理层不允许人们去重新组织——拒绝人们转变的请求，还去强化工作职责定义和岗位等。很奇怪，很多时候一些问题的解决方案只是简单地“顺其自然”，并且让员工自组织就可以了。我们通常看到经理们在私下讨论组织重组，等结果出来后才告诉员工，员工又因此产生对抗和不满。文化建设必须包括每个人，不应该强制。

\

Ish-Shalom提出，要转为动态的组织架构，可以充分利用，灵活地为解决多样的业务问题提供多样的解决方案。主要步骤有：

\

总的来说，每个公司可能会采取不同的路线。至少在引导变化上，我认为下面的步骤可能会有帮助：

\\

1. 承认你受到了旧的模式和结构的限制\\t
2. 跟公司里的每个人分享这些认知\\t
3. 不要再强化旧的结构（比如：开始允许人们挪办公室、做他们团队之外的工作、做他们的工作职责定义之外的事情，等等）\\t
4. 过段时间，再重新评估公司的结构和文化。然后继续从第1步开始。\

这个过程产生的主要结果是：人们会开始习惯于组织结构是动态的，并且明白到他们是可以影响到组织结构的。

\

查看英文原文：

感谢对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。