咖啡店 DevOps:清晰地定义和沟通团队目标

4 位读者喜欢这篇文章。
Coffee shop photo

Florida Memory。由 Opensource.com 修改。 CC BY-SA 4.0

上个月我采访了 Cockpit 团队关于团队实践。我们从许多不同的角度进行了有趣的对话,但最值得注意的是我们不断返回的主题:理解目标、反馈循环的重要性以及致力于开放和透明的沟通。我发现我可以很容易地将这些主题与我过去合作过的其他团队联系起来。当您检查团队的行为和内部运作时,这些主题似乎对团队冲突至关重要。

就 Cockpit 团队而言,理解目标是我首先产生共鸣的项目之一。本月,我将专注于理解您的组织试图沟通的目标,以及您如何逐步消除沟通失败。

1. 目标正在被沟通,但沟通方式不易被所有人理解或注意到。

让我们检查一下我在小组对话中与一位同事的交流。我们当时正在讨论构建团队内部所需的报告的高级需求。在对话结束之前,工程师问我:“我们可以使用开源解决方案吗?” 我以为他是在谈论寻找预先存在的开源解决方案,所以我说:“是的,绝对可以使用开源工具。” 我开始向他指出我见过的一些工具,这时对话中的第三个人解释说:“不,他的意思是他的代码可以存储在 GitHub 上吗?”

文字很重要。不管你喜不喜欢,误解彼此都非常容易,即使我们像那天早上那样面对面交谈。发生的误解是关于一个简单的句子。当沟通的信息更加复杂时会发生什么? 你认为沟通不畅会增加吗? 我认为是这样。

2. 目标没有被沟通,员工只是被要求按指示做事。

我可以花时间谈论上面这句话对任何组织代表的负面影响;但是,如果我们将它分解成几个部分,哪一部分最让人感到难受?

  • 目标没有被沟通。
  • 员工被要求按指示做事。

我内心那个发脾气的两岁小孩想说是第二句,但我认为第一句隐藏着更大的危害。让我解释一下:如果普通员工不了解总体目标是什么,甚至不了解在需要做出决定的那一刻应该做出什么样的决定,他们很快就会发现自己处于等待模式,等待有人告诉他们下一步该做什么。一个团队成员如果不能被授权去指导选择下一步应该采取的步骤,就会有效地导致主动性下降——官方的“推卸责任”,也称为缺乏责任感,以及随之而来的整体士气下降。

我将此视为“推送”工作模式——有人给你分配错误或工单。您等待下一个任务,而不是理解总体目标、如何朝着该目标努力以及哪些纠正措施(小的或大的)将引导团队到达那里。有时这种工作模式对于一个组织来说可能很好,但我的经验告诉我,它不适用于较大的组织。

我们通常认为这种模式会产生最大的成果,尤其是在不信任为我们和与我们一起工作的人的情况下。分配工作在某种程度上意味着它会被完成,因为它被分配了。当它没有完成时,你就知道有人没有做好他们的工作。这是可以量化的。这对您的组织来说听起来熟悉吗?

我们如何打破这些枷锁并摆脱这些问题?

尽管有些问题发生在组织层面,个人无法解决,但我们作为个人,确实承担着纠正的责任。

  • 个人理解目标:您是否发现自己处于不理解为您的团队设定的目标的情况?我直截了当的建议是继续提问,直到您理解目标为止。不要满足于模糊的解释。现在,您可能无法获得您需要的每一个细节,但您确实需要从高层次上理解您试图解决的问题集或目标。如果稍后进行后续研究或对话以揭示其余部分,那也没关系。
  • 注意:如果有人在谈论需要解决的问题,请注意这个人。 实际上,全神贯注地倾听他们。 在多任务处理成为常态的今天,这可能是一个挑战,但我希望我不需要解释这样做的危险。 您是否可能认为当您倾听组织中的某些人谈论目标时,这……可能有点无聊? 可能是因为当他们谈论需要协同下一个财政季度的增值影响以在云中增加收入来源时,您听不懂他们说的一个字? 是的,我也是。 这是一个线索:告诉他们您不明白。 要求他们用不带流行语的方式解释他们的目标。 注意力也假设了一件关键的事情——您关心您所从事的职业以及与您互动的人。 如果您已经过了那个状态,那将是一条艰难的道路。
  • 帮助您的团队进行沟通: 准备好并愿意向他人解释您理解的内容以及您正在做某事的原因。 仅仅因为您理解它并不意味着其他人也理解。 仅仅因为您认为您理解它并不意味着您真的理解——始终对别人的观点感到好奇。 这包括团队内和团队外的人员。

此外,不要假设沟通很容易,仅仅发送电子邮件就意味着您完成了。 几年前,我有一个公告需要发送给广泛的受众。 我担心信息被阅读的可能性有多大,更不用说被保留了。 在这种特殊情况下,公告被阅读非常重要。 在没有游戏计划的情况下,我向一位内部沟通专家寻求建议。 她的建议至今仍让我记忆犹新:让人们接触至少三种不同的沟通方式。 这将帮助他们记住并可能理解您试图沟通的内容。 方法包括电子邮件、视频、面对面、其他技术(集中式仪表板监视器、应用程序、您公司或项目的 wiki 页面)和口头。 不要犯只坚持一种方法的错误。

在更可能及时接收重要信息的日子里沟通您的重要信息。 星期五和星期一是出了名的糟糕的日子。 星期二和星期四通常是理想的日子。

停止假设每个问题都需要像另一场火灾一样对待,需要在升级之前解决。 并且在您甚至不了解问题之前就停止尝试解决问题。

当您放慢速度、清晰地沟通并花时间充分掌握问题并确保每个人都保持一致时,所有这些理解目标的问题都可以避免。

标签
User profile image.
Jen Krieger 是 Red Hat 的首席敏捷架构师。 她 20 多年的职业生涯大部分时间都在软件开发领域,在瀑布和敏捷生命周期中担任过许多角色。 在 Red Hat,她领导了一场部门范围的 DevOps 运动,重点关注 CI/CD 最佳实践。 最近,她与 Project Atomic 和 OpenShift 团队合作。

评论已关闭。

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.