什么是 DevOps？ DevOps 与工具无关。它与文化有关，使跨职能团队能够在持续的事务中快速交付价值。很难定义 DevOps，但是 blah blah alignment blah success blah blah joy。三段之后，没有外卖。您读过多少篇遵循这种格式的关于 DevOps 的文章？将这种模糊的点击诱饵作为指导来推广只会对我们自己造成伤害。我们拍着自己的背太用力了，以至于摔倒了。
我们怎么会在这里？我认为这是因为我们仍然没有在业务部门之间进行真正的对话。我们现在发现自己在 DevOps 社区中有两个阵营：技术和非技术。任何一方都将谈话转移到他们感觉最舒服的地方：他们工作和理解的领域。技术人员谈论工具。非技术人员谈论文化。这里的鸿沟是人为的，但这是我们通过我们的期望和价值观维持的鸿沟。
技术和非技术技能是排他性的想法是我们应该使用 DevOps 运动来解决的最大问题之一。这不仅仅是一个企业问题——小型组织同样容易受到这种谬误的影响。在初创公司尝试修复可能更容易，但这需要时间进行反省。在一种重视航运高于一切的文化中，提高我们自己被取消了优先考虑。
让我们看一下其中一些破灭的期望和价值观。
工程师擅长与计算机而非人交谈
工程师是技术奇才，交付软件是他们对我们公司的价值。他们缺乏与其他业务部门或客户沟通的社交能力。
这个想法由技术人员和非技术人员延续。我是一名工程师——我知道很多工程师（说他们）对这种安排没有意见。这很容易。我们可以专注于建设，而不必担心政治。 las，此设置很快就会崩溃。工程师最终会做出错误的事情，因为我们充其量只能对客户真正面临的问题有二手的洞察力。当企业启动我们不理解的新举措时，我们会变得脾气暴躁。非技术人员开始像对待孩子一样对待工程师，限制我们可以造成的损害以及我们的潜力。 “我们对他们”的心态在演变。
我们可以做什么？
- 激励跨职能协作。确保工程师也参与项目的早期和后期阶段。
- 务必与 整个 团队分享笔记。客户电话、工程会议、商业提案。为每次会议指派一名抄写员。
- 让工程师接听客户电话。如果您愿意，他们一开始可以是沉默的参与者。每个月（每个工程师）打几个电话可以减少他们从其他任务中分心的情况。
- 使用共享工具进行跨业务部门的沟通（例如，每个人都使用 Hipchat 或 Google Drive）。不要把人拒之门外。
- 不要把工程师放在高台上。对一个群体放宽规则会导致敌意并抑制跨职能的努力。
- 指导工程师了解非技术流程的工作原理。解释销售和营销的工作原理。阐明“合格潜在客户”或“净推荐值”等术语的含义。
- 停止寻找 10x 工程师/忍者/摇滚明星。相反，寻找可以交付软件 并 与非工程师交流的好奇工程师。
非技术是可以的
销售擅长完成交易。营销擅长宣传我们的品牌。这就是他们的价值。他们所有的时间都应该花在通过渠道吸引客户上。
如果您销售的产品涉及软件，那么这是一个棘手且特别具有破坏性的谬论。向开发团队展示幻灯片的销售电话、完全错误的技术细节的营销博客文章。这些都是这种谬论的结果，可能导致销售损失和负面声誉。这里的解决方案不是设置变更控制流程。正如 Jez Humble 所说，“变更控制的目标是确保没有任何变化”。
我们可以做什么？
- 激励整个组织的技术素养。留出时间和预算让人们互相交谈并参加聚会和会议。
- 将“我不是技术人员”视为需要解决的问题，而不是对事情现状的肯定。
- 建立符合公司计划的知识转移模式。例如，如果您打算在 7 月谈论 Jenkins，请安排时间与工程师和营销人员/销售人员进行一对一的交流，以确保您的谈话顺利进行。
- 共享销售和营销材料的草稿，以便工程师可以阅读和评论它们。留出足够的时间进行深思熟虑的反馈。
- 为整个组织开放演示。给工程师足够的时间来准备引人注目的演示。
我在 Conjur 和以前的工作中实施了上述建议并取得了很大的成功。项目符号列表使这看起来很容易，但事实并非如此。你真的必须与你的信息保持一致，努力建立同事的信任，并向很多人反复解释你的目标。让你自己的团队保持一致是更容易的战斗。让我们开始谈论接下来会发生什么。 @dustinmm80 在推特上。