如何组织一场有效的产品团队会议？

文章来自公众号：红杉汇（ID：Sequoiacap），作者： Andy Johns，原标题为：《“站会”，为何有时是无效的？》，题图来自：东方IC。

在工作日的清晨，用10-15分钟，大家围成一圈，回答类似“昨天做了什么”、“今天准备做什么”以及“工作遇到了哪些阻碍”这样的问题。这是许多人经历过的一个典型站会场景。

站会（Stand-Up Meeting）因为形式灵活、时间简短，近些年迅速在企业产品开发团队中流行开来。

行之有效的站会无疑是增进团队沟通、提高工作效率的法宝。但事实上，它并不适用于所有场景，如果只是每天机械地执行站会，而不着眼于关键问题，有可能会议的效果大打折扣，而使许多人感觉时间遭到浪费。

站会可不只是站着开会，它适用于怎样的情况？一场真正优秀的产品团队会议是如何开展的？围绕决策层面，该如何组织大家针对关键问题发起“进攻”？这篇文章将给你带来有益的参考。

大多数的站会每天都会举行，有些团队把频率降到了一周2-3次。会议很简短，但时常出现的情况是，人们在会上闲谈，说一些和工作无关的事情，比如分享自己周末做了什么。这些行为不能帮助你快速开发出高质量的产品，但人们仍十分热衷于站会，一些常用工具甚至内置了一个站会功能。

事实上，站会只有在产品即将发布时才能真正发挥作用。就如同你的军队已经准备好了，就要发起进攻的时候：我们准备好运行A/B测试了吗？营销部门准备好发布推文和宣传文稿了吗？客服部门准备好在产品推出后如何回复客户问题了吗？

——只有在你的军队做好准备，即将“诺曼底登陆”的时候，开一个站会为发布产品做好准备，这才是有效的。

站会没有为做决策留出时间

在一个典型的站会上，与会人员被要求分享以下内容：

● 昨天我完成了什么？

● 今天我要去做什么？

● 我遇到了什么阻碍？

这种形式存在几个大问题：

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

例如，产品经理可能会分享这样的内容，“昨天，我进行了一次面试，制定了一些规章，还见了一位客户。今天，我要再面试一个设计师候选人，在产品说明书中更新一些用户故事。目前我还没有遇到任何阻碍。”这是一次典型的在会议中分享自己工作进展的例子，显然，这样做对快速构建高质量产品并无帮助。

第二，为什么每个人都要关心你今天在做什么？同样，只有在一个人今天做的事能减少团队中的另一个人的阻碍时，这种分享才是有用的。但如果真的是一个很大的阻碍项，应该等到每天的站会才告诉大家吗？为什么不给造成阻碍的人发邮件或者走到他们的办公桌前告诉他们，在问题出现的时候就及时补救呢？

最后来分析第三个要点，那就是分享你现在受到的阻碍是什么。举个例子，后端工程部门在确定他们必须实现的工程设计文档之前，必须等待更加清晰的前端规范。还有人受到阻碍的原因是某个决策还没有做出来。与其说“我被某个问题挡住了”，不如说“嘿，我们为什么不一起对某问题做出决策，这样我们才能继续前进”呢？

站会没有为做决策留出时间。站会被设计成只是让“阻碍”为人所知，而不是去解决“阻碍”。然而，解决问题比意识到有问题更重要。

围绕决策进行会议

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

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

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

2.需要做出哪些决策？

根据要做出的决策的数量，每周召开1-3次会议。在产品开发的早期，团队需要做出许多决策，会议的频率较高；随着开发的进展，需要做出的决策数量会减少，用于构建产品的时间增加，会议频率也降低；同样，做决策的困难程度会随着开发的进展而变小。

随着产品开发生命周期阶段的不同，需要召开会议的频率也不一样。

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

● 收集开放性问题

在会议筹备阶段，与产品团队的每个功能负责人（设计、研发和市场等）沟通，询问他们需要做出什么决策，如：“是否应该向高层寻求更多资源的支持”、“谁来担任小组的带头人”等，收集他们提出的开放性问题并列入议程。记录在决策会议上要提出的一系列行动项目，以明确接下来每个团队成员的任务。

作为会议主持者，你应该快速浏览一遍行动项目，以确保大家可以继续执行自己分配到的关键任务，并保证能够按时完成。在讨论中出现的任何新任务都会被实时添加到列表中。通常可以用不到10分钟的时间完成上述讨论。

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

在少数情况下，做出某个决策才需要更充分的讨论，在这种情况下，不妨要求团队中最有能力的人和与该决策最相关的2-3名成员在当天晚些时候成立一个快速工作组，讨论该项目并提出建设性的建议，然后通过电子邮件或在下一次产品团队会议上与其他成员分享他们的建议。

利用团队会议和小组讨论来快速排除未解决的问题。

●决策日志

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

小结

现在流行的站会虽然形式灵活，但在驱动团队进行有效产品开发层面仍存在一定的局限性。较长开发周期的根本原因是没能快速和频繁地做出决策。通过用更少的决策会议代替日常会议，产品团队可以节省大量的时间，必能更快地构建产品。

文章来自公众号：红杉汇（ID：Sequoiacap），作者： Andy Johns。