mcpField
R
running-meetings

running-meetings

github.com/refoundai生产力1.4k359 次安装15 周前更新
代码仓库

关于 running-meetings

面向产品经理和团队的会议管理技能,内容源自 Lenny's Podcast 和 Newsletter 的见解。它涵盖会议审查、议程设计、促进共识,以及在会中落实行动项。

主要功能

  1. 01审查定期会议
  2. 02设计议程与会前材料
  3. 03促进共识与参与
  4. 04在会中落实行动项
  5. 05运用决策模板

适用场景

  1. 01判断定期会议是否必要
  2. 02准备聚焦的团队会议议程
  3. 03发现阻碍并平衡参与
  4. 04散会前明确负责人和期限

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/refoundai/lenny-skills --skill running-meetings

安装后在 Claude Code 中输入/running-meetings确认已加载。

附带文件references/artifacts.mdreferences/guest-insights.md

详细介绍

召开高效会议

让日程安排摆脱令人心力交瘁的时间黑洞,变成高效的协同机器。

借鉴 Lenny's Podcast 和 Newsletter 中 12 位嘉宾及文章的见解,帮助用户召开高效会议。

如何提供帮助

  1. 审查现有会议 - 分析现有定期会议的目的和频率,确保它们解决的是无法通过异步方式处理的具体问题。
  2. 设计议程 - 通过明确的目标、静默阅读环节和营造心理安全感的惯例来安排会议,让更多人参与其中。
  3. 促进实时协同 - 运用积极倾听和归纳技巧,确保相关人员感到自己被倾听,并让阻碍浮出水面。
  4. 精简会后工作 - 建立惯例,在会议期间完成行动项和文档,而不是留到会后。

核心原则

将探索与决策分开

Annie Duke:“人们通常认为会议的目的有三项:探索、讨论、决策。会议中真正应该发生的,只有讨论。”

在会议开始前异步完成信息收集阶段,这样同步时间就能用于高价值辩论和最终决策。

优先营造心理安全感

摘自《理想的冲刺周期、设计师与 PM 的职责、如何召开 PM 团队会议、如何进行复盘、优秀的产品/高管教练,以及更多内容》:“我们的 PM 团队专门留出一个环节,讨论‘哪些事情让人觉得很难[比理应的程度更难]?’这个环节旨在讨论各个层面的难点:如何解决与 Team X 的沟通问题;拆解一份引发意外疑问并陷入停滞的 PRD;尝试不同版本的愿景/战略。”

专门留出一个坦诚交流的空间,让团队成员能放心地提出难题,并向同伴寻求帮助。

解决行政工作积压

摘自《产品经理这个角色并不公平,所以工作方式也要不公平》:“不要把会议中的行动项添加到待办事项列表中,而要在会议中现场完成行动项。让所有人都看着,同时共享屏幕。”

在会议期间完成小任务和协同惯例,避免后续工作不断累积,并确保立即取得进展。

达成共识前先确认对方的想法

摘自《PM 的影响力指南》:“人们常常要等到觉得你真正听懂了他们,才会听你说话。如果人们认为你并未深入理解他们的观点,他们往往会执着于更强硬地重复自己的观点,而不是倾听你的想法。”

运用积极倾听和复述技巧,确保相关人员感到自己被倾听,从而避免产生阻碍共识的防御性反应。

有目的地审查会议

摘自《如何主持 PM 团队会议 - 第 19 期》:“不要为了开会而开会。务必确保增加或继续召开这场会议,始终值得每个人投入时间。你想解决什么问题?”

只保留能够解决具体问题的定期会议;这些问题无法通过其他渠道更高效地处理。

模板与框架

  • 产品经理团队会议议程模板(理想的冲刺周期、设计师与产品经理的职责、主持产品经理团队会议、主持复盘、最佳产品与高管教练,以及更多内容)——一份结构化的每周产品经理团队会议议程,旨在提升透明度、心理安全感和产品经理的产出
  • Dory 和 Pulse(我最喜欢的决策框架)——一个由两部分组成的元框架,通过平衡各方发言权、消除群体思维,强化会议中的实时决策,并记录了 14 种变体。
  • 便签投票决策技巧(介绍 Foundation Sprint:来自 Design Sprint 的创作者)——一种快速的群体决策方法,要求每个人先独立静思,再进行小组讨论,以防止群体思维
  • 会议中即时处理行动项清单(产品经理的角色并不公平。所以就不公平地工作。)——一份产品经理可以在会议中共享屏幕、当场完成的行动项清单,而不是把它们加入会后的待办事项列表。
  • WWW(Who/What/When)行动清晰度测试(介绍用于反馈的 GAIN 框架:一种基于证据的方法,让你给出的反馈能获得他人喜爱、认可并采取行动)——一个简单的三词测试,确保任何会议或对话中的行动项都切实可执行
  • 产品经理会议效果检查清单(初创公司产品经理与大公司产品经理)——一份分步检查清单,帮助产品经理高效主持会议
  • 产品经理团队会议频率指南(主持产品经理团队会议——第 19 期)——根据团队规模选择合适的产品经理团队会议频率的指南
  • 精妙的高管团队会议形式(Matt Mochary)——一种会议结构,通过异步预读材料,将 3 小时的会议缩短至 45 分钟。

完整列表及详情请参阅 references/artifacts.md。

可向用户提出的问题

  • “这次会议要解决的具体问题是什么?”
  • “能否通过简短视频或异步文档更有效地传达这些信息?”
  • “做出决定所需的最小人员范围是什么?”
  • “会议开始前,参与者必须审阅哪些材料或数据?”
  • “你将如何确保每位参与者都能安心分享真实想法?”
  • “大家离开会议室前,你会用什么流程来敲定行动项?”

需要指出的常见错误

  • 变成状态汇报——把同步会议时间用于单向信息传达,而这些内容本可以放在仪表板或邮件中。
  • 责任归属不清——会议结束时,讨论过的每项行动都没有明确负责人和截止日期。
  • 忽视人的因素——只关注具体议程,却忽视团队联结和心理安全感。
  • 被动引导——任由声音最大的人主导讨论,而不采用结构化流程来呈现所有人的观点。

深入了解

如需查看来自 12 位嘉宾的全部 19 条见解,请参阅 references/guest-insights.md

相关技能

  • 产品评审
  • 高管沟通
  • 向上管理
  • 书面沟通

评论

支持 Markdown