你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

孤岛和壁垒

要想对业务实践、文化或技术操作作出重大改变，必须具有成长型思维。 成长型思维模式的核心是接受变革和提供领导的能力，尽管含糊不清。

一些反模式会阻止想要成长和转型的组织中的成长思维模式。 这些反模式包括微观管理、偏见思维和排他性做法。 其中的许多阻碍因素都是个人会面临的挑战，但它们也为每个人创造了实现个人成长的机会。 但是，IT 中的两个常见反模式（孤岛和禁区）需要解决的不仅仅是个人成长或成熟度。

这些反模式是各个团队自然变化带来的结果，并会催生不良的组织行为。 为了解决每个反模式造成的阻力，了解形成的根本原因很重要。

正常运行、自然发展的 IT 团队

在 IT 部门创建劳动分工是一种自然的行为。 构建具有相似的专业知识、共用流程、共同目标和一致愿景的团队是很正常的一件事。 对于这些团队而言，拥有自己的微型文化、共同规范和观点也是很自然的。

健康的 IT 团队专注于与其他团队合作，以促进成功完成职责。 健康的 IT 团队寻求了解其技术贡献支持的业务目标。 细节和财务影响可能是模糊的，但团队的价值贡献通常在团队中被理解。

尽管健康的 IT 团队对所支持的技术充满热情，但他们乐于改变，并愿意尝试新事物。 这些团队通常是云 卓越中心 (CCoE) 工作的最早和最强大的贡献者。 你想大力鼓励他们的贡献。

本能地抗拒改变

有时，正常运行的 IT 团队所采用的微型文化可能不会积极响应针对推动变革的高层决策或自上而下的决策。 这种反应是自然的，因为具有共同规范的人类集体经常合作克服外部威胁。

人员有时将影响团队日常工作、安全感或自主性的变化视为对集体的风险。 抵制的迹象通常是一个早期的迹象，表明团队成员不会觉得自己是决策过程的一部分。

当云架构师和其他领导者投资消除个人偏见并推动包容性 IT 团队时，对变革的抵制可能会迅速减少，并随着时间的推移而消失。 CCoE 是一种工具，可帮助云架构师和领导者创建包容性决策。

良性摩擦

人们很容易把抗拒和摩擦混为一谈。 现有 IT 团队通常了解过去的错误、有形风险、有关解决方案的部落知识以及无证技术债务。 遗憾的是，即使是最健康的 IT 团队也可能会陷入将这些重要数据点描述为不应更改的特定技术解决方案的一部分的陷阱。 这种沟通方法掩盖了团队的知识，并产生抵制的感觉。

为这些团队提供一种在面向未来的术语中进行通信的机制可以增加数据点、识别差距，并围绕建议的解决方案产生健康的摩擦。 这种额外的摩擦会减少解决方案的粗糙边缘，并驱动长期价值。 只需更改对话即可清晰地了解复杂主题，并产生能量来提供更成功的解决方案。

有关 定义公司策略 的指南有助于与业务利益干系人进行基于风险的对话。 但可以使用同一模型来促进与被视为云防护的团队的对话。 当抗拒感普遍存在时，将抗拒解决实践纳入云治理团队的工作章程可能是明智之举。

反模式

IT 团队创建良好的 IT 团队的规模和响应迅速增长还会导致对立模式，阻止转换和采用云。IT 内部自然发展的响应式成长有助于创建正常运行的 IT 团队，但也有可能催生阻碍转型和云采用的反模式。 IT 孤岛和壁垒与正常运行的 IT 团队内自然形成的微型文化并不相同。 无论采用哪种模式，团队往往都注重于保护他们的“Turf”。 当团队成员面临改变和改进运营的机会时，他们会投入更多的时间和精力来阻止变革，而不是找到一个积极的解决方案。

如前文所述，正常运行的 IT 团队可能会产生本能的抵抗和积极的摩擦。 孤岛和壁垒是一项不同的挑战。 两个反模式都没有记录的前导指示器。 这些反模式往往可以在云卓越中心和云治理团队开展工作的几个月后识别出来。 你可以在抵抗持续出现的过程中发现它们。

即使采用的文化中存在有害因素，CCoE 和云治理团队的努力也应该有助于推动文化发展和技术进步。 努力数月后，有些团队可能依旧不会接受包容性行为，并坚定地抗拒改变。 这些团队可能会运行以下反模式模型之一：孤岛和壁垒。 尽管这些模型具有相似的表现，但它们之间的根本原因和解决抵抗的方法其实大相径庭。

IT 分散孤立

IT 孤岛中的团队成员可能会通过与一些 IT 供应商或技术专业化领域的协调来定义自己。 但是，切勿混淆 IT 孤岛与壁垒。 孤岛往往由舒适和激情驱动，孤岛有时比封地背后的恐惧驱动动机更容易克服。

这种反模式通常源于对特定解决方案的共同热情。 由于对该特定解决方案的投资，团队的高级技能会进一步强化 IT 孤岛。 如果你能够克服对变革的抵制，这种卓越的技能是云采用工作的加速器。 如果孤岛被打破或团队成员无法准确评估不同选项，它也可能会成为主要障碍。 幸运的是，通常可以克服 IT 孤岛，而无需对组织结构图进行任何重大更改。

解决来自 IT 孤岛的抗拒

可以通过以下方法解决 IT 孤岛问题。 最佳方法取决于阻力的根本原因。

创建虚拟团队：云采用框架的组织就绪情况部分介绍了用于集成和定义四个虚拟团队的多层结构。 此结构的一个优点是可跨组织呈现及包含。 引入 云卓越中心 可创建一个高调的有抱负的团队，顶级工程师希望参与其中。 此更改有助于创建新的不受组织结构图约束约束约束的跨解决方案对齐方式。 它还促使那些被 IT 孤岛庇护的顶级工程师纳入其中。

引入 云策略团队 可立即了解有关云采用工作的 IT 贡献。 当 IT 孤岛为分离而战时，这种可见性可以帮助激励 IT 和业务领导者适当支持抗拒变革的团队成员。 此过程是利益干系人参与和支持变革的快速途径。

考虑尝试和接触：有段时间以来，IT 孤岛中的团队成员可能不得不以某种方式进行思考。 打破狭隘的思维是解决抗拒的第一步。

尝试和接触是打破孤岛障碍的有力工具。 团队成员可能会抵制竞争解决方案，因此让他们负责与现有解决方案存在冲突的实验并非明智之举。 但作为云中首个工作负载测试的一部分，组织应当实施竞争解决方案。 组织应邀请孤立的团队提供意见和进行审查，而不是作为决策者参与测试。 在进入生产解决方案之前，请向团队明确传达此方法，并承诺以决策者的身份与他们进行更深入的接触。

在评审竞争解决方案期间，使用 定义公司策略 中概述的做法来记录试验的有形风险，并制定策略，帮助孤立团队更适应未来状态。 此方法向团队公开新的解决方案，并强化未来的解决方案。

实现“无边界”：推动云采用的团队发现，通过探索令人兴奋的新兴云原生解决方案，可以轻松地突破界限。 这是删除边界的方法的一半。 但这种思维可能会进一步强化 IT 孤岛。 太快地推动变革，不尊重现有文化，将会催生非良性的摩擦，导致团队本能地抗拒变革。

当 IT 孤岛开始抵制变革时，一定要在你自己的解决方案中实现“无边界”。 请注意一个明显的事实：云原生并非始终是最佳解决方案。 可以考虑实施混合解决方案，因为这种方案有可能将 IT 孤岛的现有投资扩展到未来。

此外，还应考虑 IT 孤岛团队当前使用的解决方案的云版本。 尝试解决方案，并了解在 IT 孤岛中工作的团队成员的观点。 至少，你将获得一个新的视角。 大多数情况下，你可能会获得 IT 孤岛团队足够多的尊重，从而减少抵抗。

教育投资：由于能够不断延伸教育水平，许多生活在 IT 孤岛中的人对当前的解决方案都充满探索热情。 针对此类团队的教育投资很少出错。 可以分配时间让这些人参加自学、课程甚至会议，以打破对当前解决方案的日常关注。

要使教育成为一项投资，你必须从费用中看到一些回报。 作为教育投资的交换，团队可能要向参与云采用的其他团队展示提议的解决方案。 他们可能还要提供有形风险、风险管理方法和采用建议解决方案所需策略的相关文档。 每个权益都会让团队参与解决方案，并利用其部落知识。

将路障变为减速带：IT 孤岛可以减缓或阻止任何转型。 试验和迭代找到了一种方法，但前提是项目不断移动。 专注于将路障变成速度颠簸。 定义每个人都能暂时适应的策略，以换取持续发展。

例如，如果 IT 安全性是障碍，因为其安全解决方案无法监视云中泄露的受保护数据，请建立数据分类策略。 防止将分类数据部署到云中，直到找到一个可接受的解决方案。 邀请 IT 安全人员使用混合或云原生解决方案监视受保护的数据。

如果网络团队作为孤岛运作，请确定自包含且不具有网络依赖性的工作负载。 同时，可以在处理混合或替代解决方案时试验、公开和教育网络团队。

要有耐心和包容性：在没有 IT 孤岛支持的情况下保持前进是很有诱惑力的。 但这个决定会导致中断和障碍。 改变对 IT 孤岛的看法可能需要一段时间。 耐心等待他们的自然抵抗力。 将其转换为值。 要以包容心态引入良性摩擦来改进未来的解决方案。

永远不要竞争：IT 孤岛的存在是有原因的。 IT 孤岛出于某种原因才会存在。 维护团队成员所热爱的解决方案是一项投资。 直接与解决方案或 IT 孤岛竞争会分散对实现业务成果的真正目标的注意力。 这个陷阱已经阻碍了许多转型项目的开展。

请专注于目标，而不是目标的单个构成部分。 帮助强调 IT 孤岛解决方案的积极方面，并协助团队成员明智地制定未来的最佳解决方案。 不要侮辱或贬低当前的解决方案，因为那样会适得其反。

与企业合作：如果 IT 孤岛没有阻碍业务成果，为什么要关注它呢？ 没有完美的解决方案或完美的 IT 供应商。 竞争的存在是有原因的；每个方法都有其自身的优势。

通过支持和协调强大的云策略团队，接纳多样性并将业务融入其中。 当 IT 孤岛支持阻止业务成果的解决方案时，可以更轻松地传达该障碍，而不会听到技术争吵的噪音。 支持非阻止 IT 孤岛演示了如何合作实现所需的业务成果。 当 IT 孤岛提供合法的阻止程序时，这些工作将赢得更多的尊重和更多的企业支持。

IT 壁垒

IT 壁垒中的团队成员可能会通过与特定流程或职责范围保持一致来定义自己。 团队的运营假设是外部影响对其责任领域造成问题。 菲夫多姆往往是一个恐惧驱动的反模式，这需要大量的领导支持才能克服。

Fiefdom 在 IT 规模缩减、IT 人员频繁动荡或 IT 领导能力差的组织中尤其常见。 当企业将 IT 仅视为成本中心时，就更有可能出现壁垒。

一般来说，壁垒是直线经理担心失去团队和相关权力基础所造成的结果。 这些领导者往往对团队有责任感，并觉得有必要保护下属免受负面后果的影响。 “保护团队免受变革”和“保护团队免受流程中断”等短语表明，一个过于谨慎的经理可能需要领导层的更多支持。

解决来自 IT 壁垒的抗拒

IT 部门可以通过遵循 解决 IT 孤岛阻力的方法来证明增长。 在尝试解决 IT 领域的阻力之前，建议先将你的团队视为 IT 孤岛。 如果此类方法未能产生任何重大变化，则有抵抗表现的团队可能正在经历 IT 壁垒反模式。 IT 领地的根本原因是解决起来有点复杂，因为这种阻力往往来自直接经理 (或组织中高层领导) 。 IT 孤岛驱动的挑战通常更容易克服。

当来自 IT 壁垒的持续阻力阻碍了云采用工作时，与现有 IT 领导一起评估情况可能才是明智之举。 IT 主管在做出决策之前，必须仔细考虑来自云策略团队、云卓越中心和云治理团队的见解。

注意

IT 领导者决不能轻易更改组织结构图。 他们还应该验证并分析每个支持团队提供的反馈。 但是，像云采用这样的转型往往会放大在做出这项努力之前就被长期忽视或未解决的潜在问题。 当 IT 壁垒阻碍公司取得成功时，可能就有必要变更领导层。

幸运的是，删除领地的领袖并不总是以终止而告终。 这些才能卓越又充满激情的领导者往往都会在经过短暂的反思后，转入管理岗位。 在正确的支持下，这种变化对领地和当前团队的领导者来说是健康的。

注意

对于 IT 壁垒的管理者来说，保护团队免受风险损害属于一种明确的领导价值。 但保护和分离之间，其实仅有一线之隔。 当团队被阻止参与驾驶变更时，可能会对团队产生心理和职业后果。 抗拒变革的冲动可能非常强烈，尤其是在变革明显的时期。

任何孤立团队的管理者都可以通过尝试前几节中与正常运行 IT 团队有关的指导，来最有效地展示成长型思维。 积极乐观地参与治理和 CCoE 活动可以让个人收获成长。 IT 壁垒的管理者最有能力改变压抑的工作心态并帮助团队开发新想法。

IT 领地有时是系统领导问题的迹象。 为了克服 IT 领地，IT 领导者需要自由地更改运营、职责，甚至有时甚至为特定团队提供行管理的人员。 如果需要这些更改，明智的做法是使用清晰且可防御的数据点来处理更改。

可能需要与业务利益干系人、业务动机和业务成果保持一致，以推动必要的变革。 与云策略团队、云卓越中心和云治理团队合作，可以提供实现合理变革所需的数据点。 必要时，这些团队应参与小组升级，以应对仅靠 IT 领导无法解决的挑战。

后续步骤

破坏组织的反模式要依靠团队的努力。 若要按照本指南采取行动，请查看组织就绪情况简介，以确定正确的团队结构和参与者：

确定正确的团队结构和参与者