您正在将您的组织全部或部分转向 DevOps 模型：干得漂亮！ 某个地方的某个人已经迈出了这一步。 为了本文的目的，我们假设您已获得管理层的支持：无论需要跨越什么障碍，无论需要攀登什么高山才能获得重要的“是”。 您已经商定了工具，制定了流程，现在您所需要做的就是说服人们参与进来。 应该很容易，对吧？ 如果真是这样就好了。
事实证明，并非所有人都有您这位文章读者那样开明。 并非每个人都喜欢变化，如果说有一件事您可以确定的，那就是 DevOps 将给您的组织带来变化——您的工作方式、您的工作内容、您如何与团队内外的其他人互动。
我将描述五种可能抵制转向 DevOps 的人或角色，以及一些关于可能帮助推动他们前进的策略的想法。 然而，我们应该记住，您可能无法推动所有人前进，并且人们可能出于充分的理由不想改变他们所做的事情，包括他们目前所做的事情可能对他们和组织都非常有效这一事实。
非我发明：对未知的恐惧
“过去 [1/2/5/10/25] 年我们一直这样做，而且到现在为止一直有效。” 我们都听过这句话。 这可能是真的，也可能不是，但如果您的管理层已决定应该进行 DevOps 转型，即使现有的实践一直有效，也可能已经意识到事情可以更有效率、更快或更安全。
这类人或角色的定义要点之一是，它通常表现为团队关注的问题。 团队习惯于特定的做事方式，并适应对他们有效角色和例程。 您建议的是扰乱该团队，并让人们做不同的事情。 您应该考虑如何最大限度地利用现有团队，甚至可以一起过渡团队成员，或者强调庆祝他们的成功，而不是暗示需要改变是因为他们在某种程度上失败了。
我的领域：害怕失去控制
作为一名具有安全背景的人，这是我在个人层面上非常清楚的一点。 在特定领域或领域获得高度专业知识的人，当被要求改变他们的工作方式或应用他们的知识时，常常会感到威胁。 他们通常会觉得他们被要求放弃控制权，并在“每个人都是专家”的新世界中“淡化”他们的专业知识。
在这种情况下，重要的是要强调，这不仅仅是稀释他们的专业知识，而是在更广泛的流程中应用它的机会。 例如，测试专家需要向开发人员和运维人员解释如何在他们的领域中展示测试方法。 通常，让专家接触更广泛的受众将被他们视为积极的，并且虽然总会有“象牙塔”式的人物难以在更团队化的环境中互动，但在他们承担“咨询”类型角色的方式中使用他们可能会提供积极的机会。
墨守成规：害怕新事物
虽然与“非我发明”非常相似，但这更多的是个人特质而不是群体特质。 知道您每天的任务是什么可能对某些人来说感到压抑，但对许多人来说可能非常舒适，这就是为什么他们可能不想转向一个看起来更“自由”和非结构化的世界。 并非每个人都能成为那种在理解 DevOps 周期所有不同部分都茁壮成长的通才。
好消息是，您仍然需要那些准备好专注于特定任务并以特定方式完成它们的人。 事实上，尽管最初可能对转向不同的工作方式感到担忧，但解释说团队成员将在很大程度上控制他们如何执行特定任务，这在试图帮助这类人时可能是一个积极的信息。 希望您会将培训（无论是正式的还是非正式的）作为您向 DevOps 转型的组成部分，并且学习新技能的机会（从而提高个人的流动性和职业前景）也可能成为一种激励。
人员管理者：害怕失去权力
在许多组织中，尤其是在那些等级制度森严的组织中，管理者对如何部署员工、他们的任务是什么以及如何管理他们的职业发展具有很大的控制权。 所有这些都可能与更开放的 DevOps 方法直接冲突。 对于那些建立了自己的小王国，像棋盘上的卒子一样控制他们的下属和下属的管理者来说，转向 DevOps将具有挑战性。 对于那些热衷于将团队成员培养成更专业的员工，以有多少其他团队要求将他们的下属借调到他们的团队来衡量他们的成功，并且喜欢看到新技能和职业发展发生的管理者来说，DevOps 应该是一个令人兴奋的机会。
解决抵制的人员管理者问题的部分方法可能是让高层管理人员提供胡萝卜加大棒。 胡萝卜可以包括将人员管理者的奖励方式转变为一种包含这些新行为的机制，而大棒可能包括从那些阻挠者那里撤走团队成员或改变这些管理者的角色定义。
工会：害怕缺乏确定性
在某些行业和地区，存在强大的工会。 工会的核心使命是保护工人免受管理层的剥削，管理层可能会试图对工人施加不利于他们的变革。 工会默认（并且可以理解地）对管理层引入的变革持怀疑态度，因此任何已获得管理层“祝福”的 DevOps 转型都可能引起工会和工会成员的担忧和抵制。 在某些情况下，员工可能已经非常仔细地描述了工作角色，这使得难以引入期望他们承担更通才角色并学习新技能的工作方式——这两者都是 DevOps 的特征。
好消息是，DevOps 可以为团队成员提供更多的控制权，以多种不同的方式，在某种程度上减少管理职能的控制。 解释这一点并确保采取适当的检查措施来保障工作岗位，将是说服工会及其成员相信这对他们来说是一个良好变革的关键任务。 当然，另一件应该发生的事情是，管理层应该尽早让他们参与到流程中，以确保从一开始就获得支持，而不是在最后一刻“突然”向他们宣布决定。
一些最后的想法
当我们走向光明的未来时，值得记住的是，对所有人的普遍利益并不总是转化为对每个个体的积极改变。 很难说污水处理系统的建设不是普遍的利益，但它打击了那些唯一的工作一直是收集街道垃圾的人。 希望您不会将您转向 DevOps 的举动视为为您的组织建设一套新的污水系统，但要注意那些对他们来说改变可能很困难且具有破坏性的人。 即使是最善意的开发也可能存在人力成本。
对我来说，最重要的一点是要记住，当人们变得 defensive——偶尔会变得 aggressive——通常是因为他们感到受到威胁，在我们审查的所有这些案例中，改变都可能具有威胁性。 这些人是您的同事，他们也是人，他们应该作为人受到尊重和考虑，而不仅仅是需要克服的角色或障碍。 在某些情况下，在您组织的特定部门保持现状可能是最安全的方法——至少目前是这样。
评论已关闭。