在工作日的清晨，在10-15分钟内，每个人都聚集成一个圈来回答诸如& quot你昨天做了什么？& quot你今天打算做什么？和& quot你在工作中遇到了什么障碍& quot。这是很多人都经历过的典型站立场景。

由于其形式灵活、时间短，站立会议近年来在企业产品开发团队中迅速流行起来。

有效的站会无疑是提高团队沟通和工作效率的法宝。但其实并不适用于所有场景。如果只是每天机械地执行站会，而不针对关键问题，会议的效果可能会大打折扣，很多人觉得时间浪费了。

常务会不仅仅是常务会。适用于什么样的情况？真正优秀的产品团队会议是如何进行的？围绕决策层，如何组织大家发起一场& quot攻击& quot在关键问题上？这篇文章会给你带来有益的参考。

如何组织一次优秀的产品团队会议？大部分的站会都是每天开，有的团队把频率降低到一周2-3次。会议很短，但经常会发生大家在会上聊天，说一些与工作无关的事情，比如分享周末做了什么。这些行为并不能帮助你快速开发出高质量的产品，但人们还是非常热衷于站立，一些常用工具甚至内置了站立功能。

其实站会只有在产品即将发布的时候才能真正发挥作用。就像你的军队准备进攻的时候：我们准备好运行A/B测试了吗？市场部准备好发布推文和宣传资料了吗？产品推出后，客户服务部是否准备好回应客户问题？

只有当你的军队准备好了诺曼底登陆& quot举办一个站来准备发布产品会有效吗？

车站会议没有留出做决定的时间。在典型的电厂会议上，与会者被要求分享以下内容：

我昨天完成了什么？

我今天要做什么？

我遇到了什么阻碍？

这种形式有几个大问题：

第一，很多时候你并不关心别人每天在做什么，除非另一个团队成员昨天做的事情是你工作的基础或者会阻碍你的工作。大家分享的东西，如果不能明确减少你的障碍，就很容易被你屏蔽。

例如，产品经理可能会分享类似于& quot昨天面试，定了一些规矩，见了一个客户。今天我要去面试另一个设计师候选人，更新产品手册里的一些用户故事。还没遇到什么阻碍。"这是一个典型的在会议中分享工作进展的例子。显然对快速构建高质量的产品没有帮助。

第二，为什么大家都要关心你今天在做什么？同样，只有当一个人今天所做的事情能够减少团队中另一个人的障碍时，这种分享才有用。但如果真的是很大的障碍，是不是应该等到日常常务会再告诉大家？为什么不给那些制造障碍的人发一封电子邮件，或者走到他们的办公桌前，告诉他们一旦问题出现就立即解决？

最后，分析第三点，就是分享一下现在是什么阻碍了你。例如，后端工程部门必须等待更清晰的前端规范，才能确定他们必须实施的工程设计文档。其他人受阻是因为还没有做出决定。而不是说& quot我被一个问题阻止了& quot，为什么我们不一起对一个问题做出决定，这样我们才能继续前进？

会议没有留出做决定的时间。该站将被设计成使& quot障碍& quot已知，不解决& quot障碍& quot。然而，解决问题比意识到有问题更重要。

围绕决策召开会议只有围绕关键决策召开会议，才能进一步提高会议效率，加快开发周期。对于任何产品团队和大多数会议来说，这里有一个简单的替代方法。

在会议中，回答以下两个问题：

1.谁需要在什么日期之前处理什么关键行动项目？

2.需要做出什么决定？

根据要决策的数量，每周召开1-3次会议。产品开发前期，团队需要做很多决策，开会频率高；随着开发进度，要做的决策数量会减少，花在构建产品上的时间会增加，开会的频率也会降低；同样，随着开发的进行，决策的难度也会降低。

如果团队能够快速有效地做出关键决策，就可以减少产品开发周期中数周或数月的不必要延迟。如何保证这一点？

收集开放式问题

在会议的准备阶段，与产品团队的每个职能领导(设计，研发；d和市场营销等。)并问他们需要做什么决定，比如：& quot我们应该从高层管理人员那里寻求更多的资源吗？和& quot谁将是这个队的队长& quot，并收集他们的开放式问题，并将其列入议程。记录要在决策会议上提出的一系列行动项目，以明确每个团队成员接下来的任务。

作为会议主持人，您应该快速浏览行动项目，以确保每个人都能继续执行分配给他们的关键任务，并确保这些任务能够按时完成。讨论中出现的任何新任务都将实时添加到列表中。以上讨论通常不到10分钟就能完成。

会议的其余时间用来做决定。在许多情况下，团队中的一些相关成员已经进行了非正式的谈话(例如，设计师和研发人员；d人员谈论设计的一个具体方面)，他们可以向整个团队介绍一个开放性问题的背景和他们想要得到的答案。决策通常在几秒或几分钟内做出。

在少数情况下，需要对决策进行更充分的讨论。在这种情况下，建议请团队中最有能力的人和2-3名与决策最相关的成员在当天晚些时候成立一个快速工作组来讨论该项目。

决策日志

另一个不错的方法是引入“决策日志”作为会议的一部分。可以用一个单独的文档来保存所有会议议程的完整记录以及之前做出的决策。在产品发布后进行事后评估时，这些记录就派上用场了。它可以让你很容易地对项目进行反思，并能够找到出现问题的根本原因。