随着 DevOps 的采用不断加速，许多领导者都希望建立他们的 DevOps 卓越中心 (CoE)。 CoE 的作用是确保更广泛的公司看到 DevOps 的宝贵优势：创新、效率和降低风险。

随着混合和远程工作的持续趋势，同事之间的知识共享不太可能有机地发生，开发人员将默认使用他们喜欢的流程。组装 CoE 可以帮助应对这些挑战并促进 DevOps 的采用，但您应该避免这五个常见的陷阱。

1. 任务没有明确定义

必须在一开始就定义 CoE 的使命。如果没有对其目的的共同理解，CoE 将难以确定目标并发现自己需要证明其工作的合理性。

定义范围和结构很重要。在范围方面，请考虑以下问题：CoE 是简单地建立有效的方法，还是考虑对整个企业的 DevOps 工具进行彻底改革？ CoE 是否有具体目标，还是会更广泛地推动创新？

至于结构，一些企业专门设立了一个全职 CoE 团队，而另一些企业则聚集了来自不同团队的专家，他们合作改进 DevOps 流程。根据 DORA 关于 DevOps 状况的报告，后一种方法类似于实践社区 (CoP)，与传统 CoE 设置相比，它与 DevOps 成功的相关性更强。因此，我建议您的 CoE 尽可能多地借鉴 CoP 模型。

2. CoE 分离

打破 DevOps 团队之间的孤岛是 CoE 的一个关键目标。具有讽刺意味的是，一些 CoE 变成了一个额外的孤岛，并有可能与公司的其他部分分离。虽然构建 CoE 可以保证拥有一个致力于持续改进 DevOps 流程的团队，但找到一种方法来保持 CoE 与并行团队的集成可能很困难。

您的 CoE 可能会成为创新的瓶颈，通过提倡难以实施的理想化流程来拖慢其他团队的速度。通过让 CoE 继续处理现实世界的项目来避免这种情况，这样他们就可以适应整个公司团队使用的实际 DevOps 流程的细微差别。

3.无双向通信

卓越中心模型是关于点对点知识共享的。 CoE 可以为该模型提供结构和决定性，但需要开放的沟通渠道可供其他团队使用，以便将他们的见解和反馈传递给 CoE。

CoE 应创建正式结构以主动获取洞察力。在我公司提供咨询的一些企业中，CoE 会定期审核整个企业的其他团队。审计确定以下内容：

• 团队正在使用哪些工具和流程
• 每个团队维护的环境的利益相关者是谁
• 团队在 DevOps KPI 方面的表现如何（例如发布节奏和提前期）

此数据可帮助 CoE 确定整个组织的最佳实践，而不仅仅是来自 CoE 本身。通过结合每个团队流程的最佳部分，并形成一致的方法，CoE 得出了一个可以在整个企业中共享的流程，并通过数据驱动的分析来证明其合理性。

4. 不准备管理内部政治

没有团队喜欢改变它使用的工具和流程。那些负责设立 CoE 的人应该准备应对内部政治和变革阻力。

鉴于 CoE 的目的是建立和支持最佳实践，不应允许单个团队的偏好影响决策过程。如果发现他们的工具和流程比其他团队更成功，也不应将其视为一个团队的胜利。

在组建 CoE 时，从整个公司的团队中抽取人员是一个好主意。反映组织构成的 CoE 能够更好地处理转型可能引发的潜在争议。

5. 未能衡量影响并证明投资回报率

与任何其他团队一样，CoE 需要展示 ROI，以帮助关键决策者了解它对业务的贡献。否则，管理层可能会削减 CoE 的预算。

为了支持成熟 DevOps 流程的价值，CoE 应该很好地理解需要跟踪以证明成功的关键指标。例如，CoE 应该能够表明发布正在加速并阐明提高敏捷性的业务价值。他们应该能够强调代码质量正在提高，并计算重构或维护不良代码所避免的成本。 CoE 必须表明其工作的投资回报率如何保证进一步投资。

促进协同创新

高性能 CoE 所需的专业知识通常存在于分散在不同团队中的大型企业中。如果您避免了导致 CoE 表现不佳的陷阱，那么将这些专业知识汇集在一起​​，并让团队负责寻找创新的 DevOps 解决方案，这将是很有价值的。

原文：https://www.informationweek.com/devops/pitfalls-to-avoid-when-setting-u…

本文：https://jiagoushi.pro/node/1679

我领导公司的产品团队，并且在我职业生涯的大部分时间里一直担任与产品相关的角色。我也认为自己很幸运，过去的一些角色涉及与开发人员合作并向其销售产品。这有很多原因，但主要的原因之一是它让我在 DevOps 原则和实践方面获得了丰富的经验。现在，作为产品负责人，我开始相信愿意从 DevOps 中借鉴许多想法并将其应用于整个组织的团队会带来巨大的好处。

对于不熟悉的人来说，DevOps 是敏捷方法的延续。敏捷打破了产品和工程之间的壁垒，将软件开发转变为迭代过程，并使跨职能产品开发团队能够快速适应不断变化的市场和客户需求。 DevOps 通过将软件的开发和运营责任分配给相同的团队来扩展此模型。理论是，如果开发人员负责构建和操作软件（而不是将这些职责分配给单独的团队），他们将在功能（构建新功能）和可操作性（稳定性和性能）之间做出正确的权衡。结果是更好的产品质量、更高的速度和更快乐的客户。

虽然并非每个 DevOps 实践都适用于每个功能，但我确定了三个我认为值得更广泛采用的实践，尤其是在产品团队中。这三个 DevOps 原则体现了无可指责的文化、对衡量的坚定信念和主人翁精神。

无罪文化

无可指责的文化不应被误认为是一种随意的、“随遇而安”的精神。相反，在 DevOps 的背景下，它承认操作软件是复杂的，尤其是在快速增长的企业中，您正在突破规模和速度的界限。在这种环境下，错误（事件）就会发生。但是，当他们这样做时，重要的是不要将它们视为失败，而是将其视为学习和改进的机会。只有当相关人员知道他们不会因犯错而受到惩罚时，这种改进才会发生，因此才会对发生的事情持开放态度。于是就有了“无罪”的原则。

这如何应用于产品管理？嗯，大多数数字产品所有者都致力于建立新的用户体验。无论您是在优步并彻底改变当地旅行，还是您是一家通过建立在线订购平台来应对大流行的餐厅，您都不太可能从第一天起就建立完美的体验。使您的体验更好的唯一方法是尝试和学习。它是快速制定假设、测试它们、测量和重复。这一切的关键是创造一种庆祝实验的文化，无论结果是成功还是失败。

为什么庆祝失败的实验很重要？嗯，正如任何参与过实验工作文化的人都知道的那样，失败的实验通常比成功的实验提供更多（或更多）的价值。我仍然对某些结果的反直觉感到震惊。例如，当多个客户经常在他们通过网站“旅程”的某个时间点停滞不前时，以当时出现的链接或弹出框的形式显示有用的信息似乎是合乎逻辑的。事实上，情况往往并非如此。事实证明，工作流程中的（任何类型的）干扰通常会降低转化率。发现这一点——在关键点显示有用的信息可以降低转化率——是实验和数据收集过程的成功。事实上，在无可指责的文化中，每个人都明白成功是因为过去的失败，而不是尽管过去的失败。

那么，实验反模式，即指责文化，是什么样的？在这种情况下，人们不会冒险，因为他们担心负面后果。任由责备文化生根发芽是扼杀创新的最简单方法之一。

指标和测量

成功的 DevOps 流程需要对团队正在运行的系统立即提供反馈。这意味着有关服务正常运行时间、应用程序响应时间、操作负载等的指标。为确保客户获得良好体验，需要测量每次用户交互并立即报告异常情况。

这种对测量的关注对于数字产品所有者来说同样重要。每个新功能或 UI 调整都应该从我们期望它移动的指标的假设开始。数据应该推动我们的路线图决策。并且每次更改都需要具备追踪其影响的能力。在对上述实验的讨论之后，人们可能会说，实验中的一个真正错误是无法衡量实验所产生的影响。如果同时运行多个实验，则团队必须能够区分每个更改的影响。

您在非数据驱动的组织中看到的一种常见反模式是，路线图决策或实验想法主要由 HiPPO（最高薪酬人员意见）决定。此外，在非数据驱动的组织中，开发工作的成功通常是通过在时间轴上启动多少来衡量的，而不是新功能所带来的实际影响。

你建造它，你拥有它

另一个重要的 DevOps 原则是强烈的所有权文化。简单地说，构建功能或服务的团队就是操作代码的团队。如果生产中出现问题，他们会收到通知，并且会修复它。

同样的原则也适用于数字产品所有权。伟大的数字产品所有者将他们的产品或所有权领域视为一项业务——他们负责移动 KPI。他们和他们的扩展团队有权确定路线图的优先级，以产生企业正在寻找的结果。

在数字产品所有者的世界中，“你构建它，你拥有它”的反模式过分强调了新事物。这在绝大多数投资用于新功能（下一个新的闪亮对象）的团队中很明显，并且团队没有时间迭代和改进现有功能。从长远来看，这是一种失败的商业策略。首先，它常常导致产品变得过于复杂。其次，这意味着团队没有从他们发布的功能中获得全部价值，因为他们没有在发布后优化这些功能。这是非常短视的，因为可以通过对现有功能进行小规模迭代来实现最大的影响——例如，即使稍微提高可发现性也可以显着提高采用率。

结论

DevOps 策略的出现是为了优化现代软件的交付和优化，但它们的经验教训是广泛适用的，即使对于可能永远不会编写一行代码的团队也是如此。这些原则通常看起来有悖常理，但庆祝失败的实验、使用数据而不是直觉并投资优化现有产品将确保您为客户提供最佳体验并为您的业务提供最佳结果。

原文：https://www.informationweek.com/devops/what-product-teams-can-learn-fro…

本文：

每个工程师都应该有一条清晰的成长道路，这样他们才能理解、规划和执行有意义的职业发展。为这种增长提供一个框架（我们称之为能力矩阵，也称为职业阶梯或职业发展阶梯）是一项重要的工作，也是任何想要培养和发展员工的组织的责任。早在2018年初，我们有32名开发人员，并计划全年翻番，我们已经有了一个能力矩阵，但它已经过时了。它关注的是我们的初级水平，达到了一些开发人员已经达到的水平。它也与我们组织所重视的技能不一致，这意味着在实践中，我们经常忽视它。是时候重新设计了。

建立一个新的能力矩阵是一个学习过程，也是一个漫长的过程，大约需要八个月才能完成。一路上，我们发现了我们重视的东西，以及建立职业阶梯的关键步骤是什么（哪些步骤是浪费的）。虽然每个矩阵都是不同的，并且会反映出编写矩阵的组织的价值观，但制定简洁的职业阶梯来指导团队的过程是一致的。

当我们在12月发布新的工程能力矩阵时，我们收到了许多团队的电子邮件，称他们正在使用类似的系统。由于这些反馈，我想分享我们所经历的步骤，以及我们学到的经验教训，以帮助团队以比从头开始解决问题更少的浪费和更短的时间达成富有成效的结论。

如果你想为你的员工和报告提供一条清晰、一致、明确的公司发展道路，那么这篇博文就是为你准备的。

第一步：把这个人放在第一位

回顾过去，这是我们漫长的重新设计过程中最大的因素。最初，我把这个项目作为我的许多辅助项目之一。我唯一要奉献给黑客帝国的时间是清晨、深夜和周末。这对我来说是一个充满激情的项目，我喜欢在上面工作，但我无法给予它所需要的照顾。

当我们的新工程总监莉娜·莱因哈德加入时，她将此作为她的第一个大项目。此后，我们密切合作，但她现在“拥有”了它，这一事实立即让我明白，我有限的可用性在多大程度上阻碍了这个项目。如果我在空闲时间继续驾驶它，我不知道我们是否会看到它在2018年完工。

如果你要承担这个项目，把它作为他们的第一份工作，给予它应有的关注。

第二步：就你正在建设的东西达成一致

在所有利益相关者对你的目标达成一致之前，每一次实施的尝试都会停滞。

能力矩阵是设定文化基调和方向的强大工具，因此在设计矩阵时，你会有很多有影响力的选择。每一个都有后果，只有团队团结一致，你才能度过难关。我们反复遇到的一个问题是：这是对现状的编纂，还是对未来的憧憬？（我们花了大约一半的时间才明确同意这是两者的结合。）

达成一致的另一个关键点是：谁会受到影响？在我们的案例中，这个问题取决于我们的新矩阵是否会影响我们的现场可靠性工程师（我们决定会）。也许你正在为整个公司建立一个矩阵，或者你正在为你的前端开发团队建立一个矩阵。受影响角色的广度将极大地改变你选择编纂的能力，以及你需要使用的抽象级别。所以问这些问题，并得到明确的同意。

最后，我们需要就矩阵的目标达成一致。我们决定主要目标是与CircleCI的个别工程师一起进行绩效评估和增长规划。第二，我们想用它来影响我们的招聘流程，并与外部沟通作为一名不同级别的工程师意味着什么。了解潜在用途以及这些用途的优先级，可以指导某些决策。

第三步：以你的价值观为指导

对我来说，这是整个过程中最有趣的部分。这是你坐下来讨论“什么对我们重要？”我们从优秀的人力资源总监戴维·曼那里得到了一些帮助，他带来了记录卡，详细列出了约100种作为专业人士有价值的行为特征。这些都不是特定于工程的，从沟通到政治意识不等。我们还利用其他公开的能力矩阵，对未来可能出现的情况进行了设想。

作为一个团队，我们也喜欢提出自己的价值观。在我脑海中最突出的是经济思维，管理团队一直在讨论经济思维是区分优秀开发人员和优秀开发人员的关键技能之一。我们没有从任何人力资源悬崖笔记或其他我们参考的矩阵中借用这种能力，但从一开始，我们就知道这是一个关键的能力，我们会在最后的削减。

远大的起点，远大的梦想！最好在前面撒一张大网，然后合并并剪掉。

一旦你有了一个列表，做几次传球来合并类似的能力是一个好主意，因为这将节省你以后的时间。例如，我们融合了实用主义和经济思维，因为我们意识到这些能力的表现导致了相同的行为。

第4步：定义你的等级

在你开始实际填写内容之前，最好先定义矩阵的x轴：标题和责任方面的增长。在CircleCI，我们已经有了想要使用的现有头衔（E1/助理软件工程师到E6/首席软件工程师）。然后，我们明确同意每个标题的一般责任。

我们将其分为两类，都专注于个人贡献者：E1、E2和E3专注于掌握软件工程技能并成为高效集成电路。E4、E5和E6专注于利用这些技能在越来越多的人群中扩大影响力和创造影响力。一旦我们有了这个高层次的指导，我们就将其进一步分解，为每个执行级别分配范围。在开始创建内容之前，我们有以下指导原则：

• E1-E3：工程执行
• E1：任务内
• E2：项目内
• E3：团队内部
• E4-E6：利用技能扩大规模并产生杠杆效应
• E4：给团队
• E5：到一组相关团队
• E6：致工程部

当然，这些是指导方针，而不是规则。例如，我们期望E4、E5和E6以不同的频率为组织实践和流程做出贡献。与所有人类追求一样，职业发展在实践中比理论上更混乱。然而，通过预先设定明确的指导方针，你可以使低阻力路径变得容易，并将时间集中在那些更难、更混乱的地方。

第5步：创建内容

这一步肯定是最费力的。然而，如果您已经遵循了步骤1-4，这将使您的这一步比我们的容易得多。在整个过程中，我多次尝试处理这一步骤，但如果没有正确的框架来塑造我的方法，我常常感到漫无目的和分散。一旦框架就位，填写内容就变得简单多了。

考虑到这一步的内容，我将把它进一步分解为几个子步骤。按照这个顺序应该尽量减少任何浪费的工作。

• 为所有能力定义一个级别
• 寻找合并能力的机会
• 填写其余的等级
• 字匠

步骤5.1：为所有能力定义单一级别

我强烈建议的第一步是为所有能力定义一个级别，比如高级软件工程师。与其试图对E2和E3之间的细微差异进行措辞，不如通过定义单个级别来具体化每个能力的含义，这是一个非常有启发性和一致性的过程。

我们的做法略有不同，我们定义了两个板块：E3（顶级个人贡献者）和E4（规模和杠杆的第一位）。考虑到我们在执行和扩展方面的分岔方法，这让我们更好地了解了在CircleCI开发人员职业生涯中的关键一步是什么样的增长。

5.2.寻找合并能力的机会

当你为每一项能力定义一个层次时，一件令人惊讶的事情就会发生：你会意识到一些价值观指向相同的行为。这是一个合并的机会！

在定义了单一级别之后，我们注意到我们有两个非常相似的模块：自启动和交付责任。尽管这些能力看起来有所不同，但我们编纂的行为非常相似，我们将它们合并为一个整体：可靠性和交付责任。

早些时候，我们达成了明确的协议，即我们希望我们的矩阵是对CircleCI开发人员的增长情况的一个全面的定义，同时也尽可能简单。最终，我们获得了27项能力。然而，当我们开始5.1时，我们有将近50个。定义每个人的行为向我们展示了我们有机会巩固的地方。

第5.3步：填写其余的等级& wordsmith

现在你知道你的矩阵中有你想要的行为和能力，是时候填写其余的单元格了！这一步需要做很多工作，但这是一个重要的步骤，因为它是矩阵的核心。

在这一步中，最好是开始编造文字。当你在痛苦地定义将经济思维扩展到一个团队与多个团队意味着什么的本质细节时，最好是对你使用的语言是否正确传达了意图持批评态度。在此之前，我强烈建议不要使用文字处理，但这将是重新审视您在第一次使用中定义的瓷砖的好时机。

步骤5.4：抛光和一致性

毫无疑问，在你定义每个瓷砖的过程中，你会学到一些你想要应用到你已经定义的瓷砖上的东西。大约在过程的一半，莉娜和我发现我们用“经常”和“通常”来表示相同的事情，大约是50/50。由于一致性是我们的一大重点，我们决定“通常”，并把它放在一个众所周知的停车场，以便以后申请。

我建议采用类似的方法。当你找到机会进行润色时（比如用“通常”替换所有出现的“经常”），把它们写下来，并将其作为你的待办事项清单，最后通过。这样一来，如果你学到的知识相互矛盾，你就可以在应用之前解决这些冲突，最大限度地减少流失，确保更大的一致性。

第6步：让受影响的人参与进来

太好了，你有一个能力矩阵，你完成了！事实上，不完全是这样。对我们来说，莉娜和我坐下来，写下一系列的价值观和行为，让我们的工程副总裁签字，然后作为最终结果向全世界展示的想法是一个可笑的提议。这将影响我们的文化、我们的招聘，最重要的是，影响我们所共事的所有人以及我们所关心的那些人的职业发展。在设计矩阵的几个月里，我们一直在测试矩阵的不同版本和方面，但现在是时候真正对其进行测试了。完成第一关后，我们开始收集反馈。

Lena以焦点小组的形式组织了一次出色的反馈会议，由各个级别、经理和人力资源的个人贡献者组成，包括异步和同步部分。收集反馈的方法有很多，比如让不同部分的个人贡献者与他们的经理一起完成模拟自我评估。不管你怎么做，重要的是确保你能从受影响的人那里收集反馈。

我们收到的反馈非常有价值，原因有两个：它提出了一些好问题，这让我们调整了矩阵，从而传达了我们的意图。这一过程还确保了我们将组织的价值观编纂成法典，而不仅仅是少数管理者，并且价值进步代表了我们的工程师如何看待他们的职业发展。这一步对于建立信心非常重要，因为我们开发的产品代表了我们想要的，并且会受到欢迎。

第七步：发货！

这是最好的一步——发货！你有一个经过文字编辑、压力测试的成品，并且得到了组织中受尊敬的个人的认可。然而，即使你遵循了一个彻底的过程，它也永远不会完美。当人们开始使用和测试你创造的东西时，他们会发现轻微的不一致和改进的机会。现在就准备好接受反馈，并持续进行。

既然你有了矩阵，你应该建立两种机制：一种收集反馈的方法，一种解决反馈的商定时间表。不断重复你的能力矩阵将是一个坏主意，因为这意味着在你的组织中不断移动职业发展的目标岗位。然而，假装它是完美的，永远不会改变是鲁莽和不现实的。

我们已经开发了一种收集反馈的机制（剧透警报：这是一个谷歌文档），并将在六个月后重新访问矩阵，以解决我们所学到的问题。这提供了一个重要的稳定性水平，同时也允许随着时间的推移进行迭代和进化。我建议你提供一个机制来实现同样的目标。

恭喜你的新能力矩阵！希望这本指南能让这个过程比我们更快、更容易。

原文：https://circleci.com/blog/7-steps-to-building-an-engineering-competency…