有效的团队会议

我是一个由8位程序员组成的团队的团队负责人，该团队由大约20名技术人员组成。他们正在从事一系列项目，这些项目还涉及我无法控制的其他团队的人员。我的组织没有进行适当的敏捷开发，他们对变更有些抵触，但是我一直在团队内部举行每日站立会议，我们都发现它们很有用，并且每个人都参与其中，并且在10-15分钟。我还会每周与每个团队成员进行个别交流，我们在其中更详细地讨论各种常规主题（技术性和非技术性），以及各种临时主题会议。

但是，我一直在努力的是每周的团队会议。它正在失去动力，我无法使人们保持兴趣。

我仍然想召开一个更长的会议，即使必须每两周一次或每月一次。目的是讨论站立会议期间无法完成的各种主题，因为它们需要更多时间。我的最新消息包括他们正在进行的每个当前项目的摘要（是否如期进行，各种延误等），方向，未来项目的任何变更，开发过程的变更等。但是，最终我的一次讲座，显然至少有两个人被划出了区域，其余的人至多有兴趣。

我试图通过让人们谈论他们的一周来使人们更加参与，但是与8个人一起花费的时间很长（部分是因为他们的很多工作并没有那么多），其余的团队大多数不在乎他们的同事正在做些什么（他们在站立时会获得较高的概述）。

因此，在这些会议上，至少有些人很无聊，而让我继续举办这些会议几乎让我感到尴尬。与我们精力充沛的上午站立会议形成鲜明对比。

关于我可以做些什么来使人们更加参与和更感兴趣，有什么建议吗？我如何让他们介绍他们的事情或开始涉及所有人的讨论，而不是我的独白？

您说会议感觉就像在讲课。如果您觉得这样，而团队似乎对您要说的内容不感兴趣，那么为什么还要开会呢？如果您只是向他们扔信息，而又没有引起他们的注意，为什么不只是在每周的电子邮件中总结所有内容呢？

如果您想利用整个团队的时间，可以考虑进行回顾。您可以坦率地介绍回顾会议：告诉他们您不觉得以前的会议富有成效，并且想尝试一些不同的方法来帮助每个人从在一起的时光中受益。

在我工作的地方retros，我们将在白板上三列，通常把一个笑脸，MEH和悲伤的脸在上面，如:)，:|和:(。然后，团队成员可以将他们想与整个团队讨论的任何事情放在董事会上。

在快乐栏中，您可以庆祝成功（例如祝贺Alice和Bob一起发布的项目），并且可以通过您尝试的新流程来宣告胜利（例如新的Bug跟踪器比旧的）。

在meh栏中，您输入了本周并非完全快乐或悲伤的事物。也许您购买了新版IDE的许可证，而某人却没有看到新版IDE的任何优势-他们可以将其放在黑板上，以确定其他人是否觉得升级毫无价值，或者其他人是否有找到了实际上优于先前版本的方法。

在可悲的专栏中，您将本周表现不佳的事情放了进去。在我看来，确定一周的痛点可能是回顾展的最大好处。整个团队将讨论一个实际问题的解决方案。例如，在全部都在单个代码库上工作的团队中，有人可能会说FooBar类是不可维护的，并且是调试时间长的原因。突然间，您发现团队中的其他人本周也都在FooBar上损失了多个小时，但没有人花费任何时间进行清理。在这种情况下，团队可能会集体决定下周花时间重构该代码是有意义的。

每个人都在黑板上写下他们提出的主题之后，我想简单地回顾一下每个主题，并让其作者对该主题进行10-30秒的解释。会议的这一部分很容易出问题，因此您必须谨慎地让人们关注主题-例如，有人会说X是一个问题，而其他人开始谈论该问题的解决方案；解决方案只有在投票后才能讨论。在介绍主题时，您可能会找到将多个紧密相关的主题组合在一起的方法。

介绍后，每个人都会获得三票，他们可以根据自己的喜好分配主题。最后，对票数进行了计算，团队讨论的是投票数最多的主题。对于每个主题，确定是否需要采取行动。庆祝成功通常没有任何动作，但是可以将重构特定代码分配给一个人。这些动作项通常应该由一个人完成，但是有时它们是“整个团队”的动作项，例如，要注意具有良好的提交消息。

大多数回溯倾向于将重点放在悲伤的专栏中，并且几乎没有回溯讨论董事会所写的所有内容。时间一到，会议就会结束。会议结束后，立即将操作项分配给特定人员；以对您的组织有意义的任何方式执行此操作。

回顾展取得了巨大的成功。它们是在团队中建立凝聚力的好方法，也是反思前一周并完善您的过程的好方法。我认为，如果您与团队一起尝试这些方法，那么他们会更积极地参与您的会议。

欢迎来到中层管理世界！

您会发现很多情况下都会出现这种类型的问题！

您有3种选择：

大手杖这样 做或您被解雇-永远行不通。不要这样

所有权 让他们方便会议。退后一步，提名其他人。将其作为每次其他人主持的旋转位置。

用 您所说的话说话，每个人都很无聊-那么为什么不问他们呢？你很无聊吗？/这是浪费时间吗？为什么我们会听到？这有什么价值？

您的问题尚不清楚为什么要这样做。如果您是唯一认为这些有价值的人，您愿意改变吗？问他们想要什么。他们是软件人，他们的工作是整天解决问题-解决这一问题！

尝试在会议中为开发人员带来更多价值。一些示例可能是：

• 简短的演示，展示了最近sprint中开发的新功能。（由所有人提出）
• 一次有经验的讨论，他们有机会改变团队的工作方式并改善自身（讨论在团队中占了上风，您可以在那里证明自己的管理决策。类似于一对一的宣讲会但更大）
• 关于新的开源项目的讲座，该项目可能是相关的，也可能是不同的编码语言，例如功能性Lang或Golang或python中的绿色线程。（也许由年轻的开发人员之一介绍，或者以在线视频的形式呈现）
• 由销售工程师主持的讨论，描述了他的客户试图解决的极为困难的工程问题。（与支持/服务经理达成相同的协议，试图通过提高产品可用性来降低支持成本）
• 一位经理揭示了公司可能采取的各种战略选择，以及在竞争激烈的形势下它将如何影响工程技术。
• 外部顾问，就您已经使用的技术提供咨询会议，但没有充分利用（通常是nosql，cep，RDBMS，网络，安全性，监视...）
• 通过代码遍历，每个人都可以学习新的编码或调试或测试生产率提示（该生产率是10倍的开发人员）。
• 不允许使用鼠标的编码会话。了解IDE快捷方式。
• 一位会计师谈论与货币101有关的问题养老金，投资
• 谈论社交编程和职业（堆栈交换，Twitter，github，个人博客，LinkedIn，您所在地区的聚会）

可以减少会议召开的频率吗？用常规电子邮件撰写您的讲座，并将其发送给所有人。

仅当会议中的人们确实有理由参加会议时才开会。否则，您确实在浪费人们的时间。

不要举行长时间的会议，不要利用项目管理软件。如果要让人们保持兴趣，则可以压缩并突出显示重要内容，然后将其余内容保存为项目日志和报告。专注于里程碑，交付，重点和目标，如果仅适用于1/3的人员，则将其放在项目讨论线程中。

• 保持会议简短
• 利用项目管理软件
• 保持个性化，目标明确并与情感和目标联系在一起
• 在焦点小组而不是论坛中解决问题
• 获得同行的反馈

此外，除非别人设定了要解决的问题，否则不要让他们跳入对话继续他们的工作。如果您需要反馈，请做好准备，或在网上有意见的地方放置一个评论主题，以便人们有时间加以解决。这是会议上最烦人的问题之一；出于尊重的目的给同事发言的时间。在解决了需要传达的所有问题之后，请将这些内容保留在最后。

对您的项目管理方法采取指导，并通过举例来鼓励良好的开发实践。