IPD技术开发体系的研发团队会议制度设计

说到IPD，也就是集成产品开发，可能很多朋友第一反应是"这是大厂玩的东西"。其实不完全是这么回事。我第一次接触IPD体系的时候，也觉得这套东西太重了，什么阶段门、评审点、跨职能团队，听起来就让人头大。但后来在薄云工作的这段时间里，慢慢发现这套东西的内核其实很简单——就是让一群人能够更好地协同工作，把事情做成。

今天想聊聊IPD体系下的研发团队会议制度设计。这个话题之所以重要，是因为我发现很多团队引入了IPD流程，但会议却变成了走过场的形式。会上大家面面相觑，会后该怎样还怎样。这显然不是引入IPD的初衷。会议是IPD体系的血管，血液不流动，身体再好也使不上劲。

先搞明白：IPD体系里为什么要设计这么多会议

在展开讲会议制度之前，我觉得有必要先回答一个更本质的问题：IPD体系为什么需要会议？

想象一下，一个产品从想法到落地，要经过多少道手。产品经理提需求，架构师做设计，开发人员写代码，测试人员找bug，上线后还要运营支持。如果这些角色各自为战，那结果一定是灾难性的——做出来的东西不是用户想要的，技术方案无法落地，测试发现问题时已经无法修改。

IPD的核心思想之一就是"并行"和"协同"。但并行不是说各自干各自的，然后最后拼在一起。真正的并行是大家在同一个节奏上，有问题早点暴露，有分歧尽早对齐。而会议，就是实现这种协同最重要的手段。

薄云的研发团队在实践中体会到，会议的本质是"信息同步"和"决策聚焦"。没有信息同步，大家就在盲人摸象；没有决策聚焦，讨论就会无边蔓延。这两个目的，贯穿了IPD会议设计的始终。

IPD体系中几类核心会议的设计逻辑

IPD体系里的会议类型很多，如果每一场都详细说，可能写本书都不够。我把最核心的几类会议列出来，讲讲设计时的思考逻辑。

1. 概念阶段会议：把"做什么"定下来

任何产品开发的起点，都是搞清楚"我们要做一个什么东西"。这个阶段在IPD里叫概念阶段，对应的核心会议是"概念决策会议"，有时候也叫"项目立项会"。

这个会议的关键不在于"通过"，而在于"对齐"。立项会上，团队要把产品的商业目标、核心价值主张、目标用户群体、初步的技术可行性这些要素都过一遍。薄云的实践是，这个会议一定要让市场和技术的代表同时在场，而且要留出充足的讨论时间。

我见过一些团队的立项会，半小时就结束了，大家签字画押，然后各回各家。这种会开不开有什么区别？概念阶段的会议，应该是一次深度的碰撞。市场说用户需要这个功能，技术说实现起来太复杂，财务说预算不够——这些分歧早点暴露出来，比最后做完了再推翻强一百倍。

2. 计划阶段会议：把"怎么做"规划清楚

概念确定之后，接下来要回答"怎么做"的问题。这个阶段在IPD里叫计划阶段，对应的核心会议是"项目计划会议"或者"迭代规划会"。

这个会议的参与者通常比较广泛，包括产品经理、技术负责人、各模块负责人、项目经理等。薄云的做法是把整个会议分成两大部分：先做整体规划，再做详细拆解。

整体规划这部分，讨论的是这个版本或这个项目要交付哪些特性，优先级怎么排，大致的时间节点是什么。这里有个很重要的原则：不要试图在一次会议上把所有细节都定下来。计划会议的目的是形成共识，而不是产出完美的文档。

详细拆解这部分，通常会分成多个子会议来进行。比如后端组一起拆后端的任务，前端组一起拆前端的任务。每个小组把自己的工作拆分成可控的工作项，评估工作量，安排人员。

3. 日常运作会议：保持节奏和透明度

计划做得再好，执行过程中也会出问题。日常运作会议就是用来解决这个问题的。

最常见的是每日站会。这个会议源自敏捷方法，但在IPD体系里同样适用。站会的目的是让每个人说说"昨天做了什么"、"今天要做什么"、"有什么阻碍"。注意，站会不是汇报会，而是同步会。每个人说的时候，别人要听，要思考对自己有没有影响。

薄云的研发团队在实践中对站会做了一些改良。我们发现，单纯的"做了什么"和"做什么"信息量是不够的。所以我们加了一个环节：谁遇到了阻塞，需要什么人帮忙。这个改变让站会的效率提升了很多——以前是各说各的，现在是大家互相帮忙解决问题。

除了站会，周会或周同步会也是日常运作的重要组成部分。周会主要看整体进度有没有偏离计划，风险有没有升级，需要不需要调整优先级。周会的频率不宜太高，一周一次足够了。每次周会应该有一个明确的议程，不要开成漫谈会。

4. 评审会议：及时发现问题

评审会议是IPD体系里非常有特色的一类会议。常见的评审包括需求评审、设计评审、代码评审、测试评审等。评审的核心思想是"尽早发现问题"。

很多团队把评审当成"找茬"的会议，这是不对的。评审的目的是帮助团队把产品做好，而不是证明谁做得不好。薄云在推行评审制度的时候，特别强调这个文化：评审会上只讨论事情，不讨论人。没有人身攻击，没有事后算账，大家都是为了把问题找出来。

设计评审是我特别想展开讲的一种。技术方案确定之前，一定要做设计评审。这个评审的参与者应该包括架构师、技术负责人、相关的开发人员，甚至可以邀请测试人员参与。测试人员能从用户角度发现很多技术同学考虑不周的地方。

设计评审不应该是一次性的。复杂系统的设计可能需要多轮评审：先评审整体架构，再评审详细设计，再评审接口定义。每一轮评审的侧重点不同，参与的人员也可以动态调整。

5. 回顾会议：持续改进的引擎

最后一类我想讲的是回顾会议。回顾会议通常在一个迭代或一个项目结束后进行，目的是总结经验教训，为下一次做得更好做准备。

回顾会议的形式可以很灵活。薄云用过"星光闪耀法"（做得好的、写下来贴星星）、用过"海龟汤法"（追问为什么）、也用过简单的"三件事总结法"（本期做对了什么、做错了什么、下期要改进什么）。形式不重要，重要的是真的在反思，真的有行动。

我见过很多团队的回顾会议流于形式。大家坐在一起，说说场面话，然后各自散去。这种回顾开了不如不开。真正的回顾会议应该产生可执行的行动项，而且这些行动项要在下一次回顾时检查落实情况。

会议制度设计中的一些实践经验

上面讲的是几类核心会议的设计思路。但在实际落地过程中，还需要考虑很多细节问题。这里我想分享几点薄云在实践中积累的经验。

关于会议频率和时长的思考

会议太多是很多团队的通病。我见过一个研发团队，每周光正式的研发会议就有七八场，再加上各种临时的评审会、讨论会，真正用于写代码的时间可能只剩下一半。这样肯定是不对的。

薄云的做法是给会议时间设上限。我们有一个不成文的规定：每人每天的会议时间不超过工作时间的30%。这个比例不是科学的计算结果，而是一个经验值。为什么要设这个上限？因为会议多了，人会疲劳，效率会下降，最后变成"身在会场，心在别处"。

单次会议的时长也很重要。我个人的经验是，讨论性质的会议不宜超过90分钟。如果一个议题90分钟还讨论不出结果，那说明要么是这个议题太复杂需要分开讨论，要么是缺少关键信息需要会后再调研。强行把会议拉长到两三个小时，参会的人早就魂飞魄散了。

关于会议主持人和会议纪要

一场会议要想开得有效，主持人非常关键。主持人的职责不是把大家聚在一起，而是控制节奏、引导讨论、确保产出。

好的主持人会在会议开始时明确说明这次会议要解决什么问题、预计多长时间、最后的产出是什么。会议过程中，主持人要适时打断跑题的讨论，把大家拉回到主题上来。会议结束时，主持人要总结一下讨论的结果，明确后续的行动项。

会议纪要也是很多人忽视的环节。我见过很多会议开得很热烈，但会后没有人记得结论是什么。所以会议纪要应该在会后24小时内发出，而且要明确到人、明确到时间。一条好的会议纪要应该包括：会议的基本信息（时间、地点、参会人）、讨论的主要议题、达成的共识、需要跟进的任务。

关于会议中的"冲突"处理

前面提到，IPD体系里的会议不可避免会有冲突。不同角色有不同的立场，不同人有不同的判断。这些冲突是好的，但处理不好就会变成人身攻击，变成团队内耗。

薄云在处理会议冲突时有一个原则：对事不对人。具体来说，讨论的时候只说"这个方案有什么问题"，不说"这个人的方案有问题"。技术方案的争论应该聚焦在"为什么这个方案更好"或者"这个方案有什么风险"，而不是"谁更懂技术"。

还有一个原则是：没有结论的冲突，不要在会议上无限放大。如果双方各执己见，无法达成共识，那么应该把问题升级给更高级别的决策者，或者约定会后再调研一些信息，下次会议再议。会议上吵翻天没有任何意义，只会伤害团队氛围。

把会议制度变成团队的"肌肉记忆"

说了这么多会议设计的细节，最后我想讲讲怎么让这些制度真正落地。

任何制度在推行初期都会遇到阻力。会议制度尤其如此。因为开会要花时间，而程序员通常不喜欢开会——他们更愿意安安静静写代码。

薄云在推行IPD会议制度时，没有一上来就要求大家严格遵守所有规定。我们先选了几个核心会议来做试点，比如站会和迭代规划会。这两个会议频率高、效果好，容易让大家看到价值。等大家习惯了这两个会议之后，再逐步引入其他的会议类型。

还有一个关键是"因地制宜"。IPD是一个框架，不是一套死规定。薄云的会议制度在落地过程中做了很多调整。比如我们发现，对于小型项目，概念阶段可以简化；对于维护性项目，计划阶段可以缩短。制度是为人服务的，如果制度阻碍了效率，那就要调整制度。

现在薄云的研发团队已经形成了一些"肌肉记忆"。到了迭代规划的时间点，大家会自动准备好需求清单；到了站会的时间点，大家会自觉出现在会议室里。这种状态不是一天两天形成的，是通过持续的实践、反馈、调整慢慢培养出来的。

写在最后

回顾薄云在IPD会议制度建设上的这段历程，我觉得最重要的收获不是那些条条框框的制度，而是团队协作理念的转变。以前我们觉得会议是"浪费时间"，现在我们认识到会议是"投资时间"。一次高质量的会议，能避免后面无数次的返工和争吵。

当然，会议制度不是万能的。它只是IPD体系中的一个环节。如果产品方向错了，再高效的会议也救不回来；如果技术能力不行，再怎么评审也写不出好代码。但在一个正常运转的团队里，良好的会议制度能让大家好钢用在刀刃上，把有限的精力投入到真正重要的事情上去。

如果你所在的团队正在引入IPD体系，或者正在为研发协同效率发愁，不妨从会议制度入手。先从小处着手，让团队感受到价值，再逐步完善。这条路不一定好走，但走通之后会发现，原来让一群人高效地一起工作，也可以是一件不那么费力的事情。