为什么你的研发团队越开会越混乱？为什么项目推进总是“卡在沟通”？这篇文章用8类会议场景，帮你重构团队协作逻辑，告别无效会议，让每一次开会都能带来实质进展。
“又开会？我板子还没画完呢！”
“这个需求可不能乱改啊！怎么没开会评审一下呢？”
“天呐，开了一上午会，啥结论都没有…”
这些话是不是很熟悉？硬件改一版要两周，结构稍微改一点，其他模块都得跟着调整。等到软件和硬件联调的时候，更是各种 bug 冒头。会要是开得不靠谱，轻则延期，重则量产翻车。可要是会开太多，大家光在会议室扯皮、互相甩锅，根本没时间干正经活。
很多公司研发节奏不好，其实就是因为不会开会。
我经常和学生探讨，到底该怎么解决开会的问题。最后我总结出8个必开的会+5个技巧+3个准备事项，从概念到量产，按这个来开会，不浪费时间，还能少走很多弯路，研发风险也能降下来。
决策评审会是项目推进路上的重要关卡，它的主要作用就是在关键节点上，团队成员一起把关，避免方向跑偏。一般都得跨部门的核心成员凑到一起，最后能得出个明确结论才行。
这是项目的“第一枪”，必须在团队具体投入之前开。很多初创企业都没有开这个会的意识，老板习惯了和技术交代一句就完事了，搞得项目里很多其他相关人员都很懵，甚至不知道什么时候开始的。
这场会议老板、产品经理、硬件、软件、结构、生产、采购的核心负责人都得到场。会上必须讲清楚三件事：为啥做这个产品（市场机会、目标用户）、要做到什么样（核心功能、长啥样）、怎么才能做成（大致时间、关键资源、谁负啥责）。最后必须让所有人带着统一的目标和清晰的职责散会。
需求评审就是把产品到底怎么做、技术上能不能实现这些事聊清楚。一般产品经理、硬件、软件、结构负责人，甚至供应链的同事都要参加，最好在产品有个初步想法之后就开。会上主要就是过一遍产品需求文档，琢磨琢磨技术该怎么落地，最后得整出一份详细的需求清单，再给技术可行性下个定论。
这个会就是专门研究技术方案具体该怎么做。硬件、软件、结构工程师都要到场，在设计刚开始的时候开。大家一起看看系统架构、接口定义和设计方案，保证各个环节的设计都能对上，最后得有评审记录和问题清单。
试产总结会在量产前特别关键！不管是 EVT、DVT 还是 PVT 阶段，试产一结束，项目经理就得赶紧把生产、质量、研发这些部门的人召集起来。一起复盘试产过程中发现的问题，评估产品质量和工艺情况，最后决定能不能进入下一阶段。注：这些会议并不是每次都需要拉这么多人一起，比如有些产品要评审纯应用层的软件需求，可以只拉软件的技术，硬件研发和供应链不需要参加。
定期同步会就是为了让信息及时共享，提前发现风险，根据内容和范围，其实可以分成好几个不同的会议。
每日站会是各个职能团队分开开的，硬件、软件、结构团队各开各的，时间最好别超过15 分钟。每个人简单说说昨天工作总结、遇到的问题，今天计划。主要就是对进度、快速找出卡在哪，不展开深入讨论。但凡出现需要深入探讨的话题，都约定会后再点对点沟通。
项目周会一般由项目经理牵头，各个团队的负责人都得来。会上同步一下项目整体进度、风险和问题。最重要的是得把下一步干什么、谁来负责都敲定，这样跨部门合作才不会乱，项目节奏也能及时调整。
技术对齐会就是针对具体技术难题，拉上技术骨干一起“头脑风暴”，深入研究解决方案。
技术专题会专门攻克例如信号完整性、散热设计这类具体的技术难题。一般由技术负责人组织，相关工程师都得参加，什么时候有问题就什么时候开。大家一起论证技术方案、排查问题，最后得出解决方案或者验证计划。
接口对齐会就是为了保证各个部门能配合顺利。在系统设计阶段，硬件、软件、结构工程师必须得坐下来，把接口协议、规范都确认好，把交互细节也抠清楚，最后输出接口文档或者会议纪要。
1.没议程不开会：提前一天把会议议程和要讨论的材料发出来，每个议题计划讨论多久都写清楚，省得开会的时候手忙脚乱。
2.主持人要 “硬气”：每个会议都要有专人控场，没有指定人选时，会议发起者就得承担这个责任，有人跑题，马上把话题拉回来。遇到有争议的议题，限定讨论时间，最后投票做决定。
3.结论要 “钉死”：每个议题讨论完，必须白纸黑字明确三件事：定了什么决策？谁负责去做？何时能做完？
4.纪要不过夜：会议结束 24 小时内，必须把会议纪要发出来，重点把需要落实的任务标清楚，同步给所有参会的人和相关同事。
5.能站着不坐着：像站会、紧急同步会这种，15 分钟能解决的，最好站着开，别坐着慢慢磨洋工。
智能硬件研发，“开会” 不是目的，“对齐信息、解决问题”才是。好的会议能提前规避硬件选型、结构干涉、生产工艺等深坑；坏的会议只会消耗团队精力。
下次组织会议前，先问自己 3 个问题：
如果答不上来，不如先把时间省下来画板子、写代码、调结构 ——毕竟，我们的目标是 “做出好产品”，而不是 “开完所有会”。
本文由 @硬核PM 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。