人际交往的套路

不久之前，我在荷兰的一次技术活动中向大多数由系统管理员组成的观众讲话。 我的主题之一是系统管理员如何增加为其工作单位提供的价值。 我认为，实现价值的最重要因素之一是使每个人都知道整个组织的优先事项和目标，以及组织的开发团队的优先事项和目标。

这听起来似乎很明显，但是在许多组织中，筒仓几乎完全阻碍了理解彼此优先级所需的团队间沟通。 即使在大型组织中，他们因参加了完整的DevOps（或渴望参加完整的DevOps）而自立，对其他团队的优先事项和目标的了解也不是无处不在。 当我问听众中的数百个人，他们是否了解他们的开发团队以及推动这些团队发展的因素时，很少有人举手。

您可能会争辩说，如果您声称已经完成了完整的DevOps，但是您的员工不知道直接与其合作的团队的目标和优先级，那您做错了。 您可能会有一点。 但是暂时搁置一会儿。 即使是在传统组织中（一个刚刚开始其DevOps旅程，已经实施了DevOps哲学的某些部分，或者仅在组织的某些部分中实施了DevOps的组织（我都看过了）），我还是衷心建议您了解一下您的合作伙伴。 我特别建议您了解团队外部与（或基于）您构建和维护的平台一起工作的人员。

与其中一个在您的平台上开发应用程序的人员或与维护商业的，现成的软件的人员一起坐一个小时左右。 让他们向您解释您的平台和服务如何使他们的生活更轻松，以及他们如何使他们的生活更艰难。 您和您的团队可以做什么来改善这种情况？

彼此交谈，相互学习，辩论问题和解决方案（尤其是与最初目标可能与您最初的目标不同的人），有助于每个人共同前进，并建立有益于整个社区的东西。

我们一直在世界各地的开源社区中看到这种情况。 由（目标）目标可能不同甚至冲突的不同公司和不同人员建立的广泛社区在起作用。 成功的开源社区通常是多种多样的，成员进行交流以实现广泛的目标，寻求折衷并适应所有人。

广泛的开源社区与组织中的“相邻团队”之间存在明显的相似之处，以使您的平台更好地适合他们的兴趣和目标。 这只是第一步，并与他们开始对话。

在这一点上，您可能会问：“但这就是我要让我的架构师或服务所有者使用的，对吗？” 是的，当然，他们在其中发挥了作用。 和许多其他人一样。 你也是！

例如，假设您的组织为您的团队设定了一个目标，以便在最初请求的一周内提供服务。 如果在一周之内提供服务，则可以满足服务级别协议（SLA），一切都很好，对吗？ 实际上，这只是有时是正确的。

想象您的目标是在一天之内自动（根据自助服务请求）交付新的虚拟机（VM），且成功率至少为95％。 现在想象一个开发团队每天为CI / CD用途请求数十个临时VM，并且95％的VM已正确交付。 您的目标已经实现，您的SLA已实现，但是没人对这种情况感到满意，因为CI / CD管道由于VM配置错误而多次中断。

[更多阅读： ]

在此示例中，需要尽快重新评估目标和SLA。 但是，即使在一个非常孤立的组织中，与您的开发人员团队或应用程序维护人员进行定期对话，也可以使这种体验变得不那么普遍（如果发生的话，也更容易解决）。 会在早期发现小烦恼和小问题； 建议进行一些小的改进，并在进行大规模影子IT部署之前进行一些小的改进。

归根结底，人与人之间的交流无处不在。 没有什么比知道知道哪张脸配哪个名字更能克服障碍的了。 与人交谈最容易的就是知道他们想为您提供成功的支持！ 所以，去和附近的团队交谈。 和他们一起喝咖啡。 在您的组织中建立广泛的社区！

PS赔率是您的开发人员团队将与您讨论云以及持续集成和交付。 这些是本文将来可能进行后续跟进的主题。 敬请关注！

翻译自:

人际交往的套路