在站立会议中脱颖而出的 8 种方法

2023-07-11 08:00:00 · 飞浪 · Amber Israelsen

无论您称之为站立会议、站会还是晨间会议，以下都有一些秘诀可以让您脱颖而出并帮助每个人充分利用它们。

您的日常站立会议是否比调试会话还要拖沓？您是否发现自己在幻想下一次史诗般的冒险，而您的队友却喋喋不休地更新着无关紧要的更新？您是否经常想，“那是我永远无法挽回的时间”？

我们所有人都经历过这种事！无论你称此活动为每日站会、每日站立会议还是晨会，这些每日活动对于所有参与者来说都可能是极富成效的，也可能是完全浪费时间的。在这篇博客中，我们将揭开成为站立会议超级明星的秘密，帮助你和团队的其他成员从这次每日会议中获得最大收获。

1. 与整个团队保持联系

想象一下：你正在单口相声表演，而你的队友却喋喋不休地谈论他们最喜欢的猫咪表情包，你可别这样！

每日站立会议应该与所有与会者相关。他们是开发人员吗？ Scrum 主管在吗？产品负责人呢？有测试人员吗？显然，并非所有更新都适用于所有参与者，但请向所有与会者表达一点爱意。

例如，可能是这样的：

我完成了用户注册和登录的后端 API 端点（针对开发人员）
我仍然需要获得第三方电子邮件验证服务合规部门的批准（针对 Scrum Master）
我已经分享了测试计划以供审查（供测试人员使用）
总体登录流程应该在明天准备好供用户审查和反馈（针对产品所有者）

当您想出要包含在报告中的内容时，请确保您考虑了团队中的所有不同角色。

2. 紧扣主题（把故事留到以后再讲）

您的更新应该像精心制作的软件更新一样：清晰、简洁，只包含重要的细节。稍后有充足的时间讲述故事和进行更深入的对话，但实际的站立会议应该高度集中。

每日站立会议议程是让团队成员报告三件事（承认这可能会有所不同）：

自上次会议以来你做了什么？
下次会议之前您要做什么？
有什么阻碍吗？

就是这样。三件事。直奔主题。

请记住，人们支持站立会议的初衷是为了鼓励简洁。但即使您的日常会议不涉及（或不能）站立，简洁在这种环境下仍然是一种美德。

3. 准备分享并请求领导

与上述几点相关，花几分钟思考如何回答站立式提问。这不需要花费大量时间，但要记下轮到你时要讲的内容的要点，同时注意你如何为团队增加价值。如果需要，还可以收集数据。这将使你在会议期间更有效率，也有助于在自己的脑海中确定事情的优先顺序。（说实话，有时昨天感觉就像是很久以前的事情，当你被当场问到时，试图记住你做了什么可能会很困难。）

此外，无论您的角色是什么，偶尔都要自愿主持会议。这是提高您在团队中的知名度、展示领导能力和协调能力的好方法，并且会迫使您更加关注团队中发生的事情。

4. 仅当需要 30 秒或更短时间时才提供即时解决方案

站立会议的一个重要目标是促进整个团队更好的协作，并深入了解每个人的工作内容。不可避免地，一个团队成员会遇到另一个团队成员可以解决的问题。从本质上讲，我们是解决问题的人，在站立会议或会议期间，我们很容易直接投入并解决问题。但是，如果您的解决方案需要超过 30 秒的时间来讨论，那么“将其离线”（正如他们所说），这样就不会破坏会议的其余部分。

5. 用心倾听团队的意见

不言而喻，在任何类型的会议中，倾听都很重要。否则，为什么要开会呢？但是，一些传统的表示你在倾听的方式——比如问后续问题、复述你所听到的内容等等——在站立式电话会议或会议上并不总是合适的，因为这会破坏上述关于保持专注和简短的规则。那么你如何才能仍然显得投入呢？

以下是一些想法：

点头并微笑。这是表达参与的可靠方法。
展现一些虚拟的爱。如果您的单口相声是通过 Zoom 或 Teams 等工具进行的，请使用相关的表情符号、反应、竖起大拇指或 GIF 来表明您正在关注。
保持目光接触，即使是虚拟的。查看更多有关更好的虚拟沟通的想法。
轮到您发言时，请引用队友之前说过的话。或者在会议结束后进行讨论，回顾他们说过的话。

6. 准时出席单口会议

如何成为出色的站立会议主持人？首先，出席！这应该是显而易见的，但我们可能都遇到过经常缺席站立会议的人。虽然偶尔会出现时间安排冲突，但这应该是日历上的一个受保护的时间，每天同一时间，并且只是日常习惯。缺席太多次可能会导致与团队缺乏协调，错失合作机会，而且你还可能会耽误其他依赖你的人。

另外，一定要准时出席！因为会议时间短，时间紧迫，所以每一分钟都很重要。如果你迟到 4-5 分钟，整个会议就会延误，然后对当天的剩余时间产生滚雪球效应。

7. 不要害怕提出阻碍和担忧

这会让初级技术人员和内向的人心生恐惧！报告一切进展顺利，这太诱人了。你掌控一切，所有代码运行完美，你做得太棒了。嗯……对！

有时确实如此，但通常存在一个潜伏的问题，甚至摆在你面前的问题，而你却感到尴尬或害怕提出来。我们所有人都会遇到这种情况；不要紧张。你昨天花了一整天调试几行代码，现在却落后于计划了？利益相关者向你提出范围蔓延？你在代码库中发现了一些质量问题？有未审核的 PR、长期运行的 PR 或需要关注的高活动 PR？

尽管这很困难，但你应该立即报告此类事情。仅仅希望它们会消失很少能解决问题。越早公开，就能越早修复。