本文主要从「会议背景：项目困境与压力」、「会议冲突：产品与测试分工」、「领导决断：坚守还是妥协」、「归纳总结：一场会议的启示」这4个部分展开。

记得几年前，参加一场关键在线会议，会议开到一半，出现了分歧，有人提议拉产品大领导参会。前2次大领导都拒绝了，直到第3次才拉上来。让我有机会目睹产品大领导的开会风采，短短几分钟的发言，至今仍让我印象深刻，深受启发。

一、会议背景：项目困境与压力

当时，公司的一个重要大项目需要上线，涉及上下游数十个系统，复杂程度可想而知。所以，项目推进并不顺利，进度严重滞后，后来负责该项目的产品经理又离职了，可谓雪上加霜。

而接手这个项目的产品经理，入职时间不久，对业务场景和产品方案都不熟悉，主要承担项目经理的角色，重点负责进度管控，会议组织和主持工作，无法深入参与产品方案的讨论。

项目磕磕绊绊推进到测试联调阶段时，问题仍然不少。因为跟上下游关联的系统很多，测试涵盖了二三百个用例场景，每个场景都有几十个测试节点。而此时距离项目上线已经不到一个月了，时间非常紧张。

尽管此前业务、产品和测试三方对测试用例做了优先级排序，也将非核心的用例推迟到了二期，但剩下的高优先级测试场景，工作量依然很大，要覆盖这些测试场景，按时上线几乎不可能，延期风险非常大。

然而，业务大领导明确要求必须按时上线，不容有失。

并且就在不久前，公司开始压缩人员，产品和测试的岗位编制比较紧张。大家都是超负荷的工作，身心疲惫，压力不小。

二、会议冲突：产品与测试分工

在那场关键会议中，产品和测试相关人员齐聚一堂，气氛紧张，压力不小。测试负责人首先发言，他说时间紧、任务重，业务要求的上线时间又不能推迟，于是提议，部分测试验证工作交给对应系统的产品负责，否则上线时间守不住。

此时，有产品表示不同意，说公司之前有规定，产品负责输出需求文档（PRD），不能兼顾测试工作，以避免因产品思维惯性，导致系统上线后出现未覆盖的测试问题。

测试负责人略带犹豫地说，产品参与测试验证一事，已跟产品大领导通过气，大领导是知情的。

于是，会议主持人提议在线邀请产品大领导参会，以明确责任划分。但是，前两次邀请，产品大领导都拒绝了，没有加入会议。

没过多久，会上有人说，看到产品大领导回办公室了，提议再拉他上会。此时，会议主持人犹豫了一下，说领导是不是在忙，我看前2次都拒接了。但有人说看到领导回来了，主持人架不住劝，还是第三次邀请了大领导。

三、领导决断：坚守还是妥协

事不过三，第三次大领导没有拒绝，选择了上会。这时主持人说稍等一下，需要再拉个领导。

不知是不是因为拒接2次还被拉到会上，此时产品大领导显然有点不高兴，他控制着情绪，但声音中仍藏不住生气：“什么问题，快点，我还有事”。

看领导口气不对，主持人连忙让测试负责人说一说，想将部分测试验证工作转给产品的提议。

测试负责人介绍了背景后，说为了保证项目不延期，是否能将测试验证工作交给产品，测试只负责提供基础数据。

测试负责人话还没说完，就被产品大领导直接打断了。语气坚定，并且不容置疑地说：“这个提议不符合公司测试规范和流程。如果让产品团队替测试团队做测试验证工作，项目上线后出了问题，责任算谁的？系统的质量又如何保证？”

他接着强调说：“测试工作任务重、时间紧，这点我能理解，但是产品团队同样压力很大。要是测试工作转嫁给产品，那产品的工作又转给谁呢？而且，产品负责出方案，测试负责测试，这是公司高层制定的流程，如果要调整，必须经过高层决策。”

产品大领导的这番话，让产品经理松了一口气，给所有参会的产品人员吃了一颗定心丸，这也是产品团队所有人员的心声。

如果领导揽下这个活，估计很多产品经理都会有意见，就算不敢公开反对，内心也是不满的。

这时测试负责人也没再说话和反驳。领导交代了几句后，就说还有其他事情，匆匆离开了会议。

最终项目测试工作还是以测试为主，产品为辅。并且按时完成了上线。因为大家都知道，项目必须按时上线，否则就会有人离职。

只是系统上线后出了很多问题，而且有些问题很难在上线后马上暴露出来，会陆陆续续出现，直到上线后二三个月，问题才基本解决。好在没有出现导致业务停摆的严重问题。

四、归纳总结：一场会议的启示

这个项目的那场关键会议，产品大领导参会虽然时间短暂，但给我留下了深刻的印象，深受启发。

当然，除了大领导，这场会议中的每个角色，都有值得学习的地方。以下是我的收获和理解。

1、项目的产品经理

作为新接手项目的产品经理，一开始大家并不看好他，认为项目上线风险非常大。

但是新产品经理接手项目后，最大的改变就是提高沟通的频率，每天除了日会，还有专项会议，多的时候一天有两三个会议。最晚的一次，开到了晚上11点多，很多方案的细节都需要拉通、对齐。

虽然新上任的产品经理，无法了解每一个需求细节，甚至很多需求他都不懂，但是推动工作的这份动力和热情，起到了至关重要的作用，为项目如期上线提供了保障。也为他个人在团队中的口碑、信誉打下了坚实的基础。

2、项目测试负责人

作为测试负责人，在项目面临上线风险的时候，前期敢于将问题暴露出来，推动将很多非核心需求放在了二期。同时也在努力将项目延期风险降到最低。这些都值得学习。

这次会议上，虽然产品大领导没有答应产品承接测试的工作，但后来还是向产品团队传达了，要求大家全力配合这个项目，相关问题要第一时间响应和解决。

当然，作为测试负责人，也有做的不对的地方。比如在公开会议上说，希望将测试验证工作转给产品，显然是不合时宜的。就算产品领导私下答应可以协商，也不应在会上公开讨论。

3、产品大领导

（1）抓住问题的核心

产品大领导一上会，很快就明白拉他上会是要做决策的，而且这个决策涉及到产品和测试的责任分工。在短短的几秒钟时间，立刻作出了合适的决策——产品不能承接测试的工作。

就算产品领导私下跟测试负责人有过沟通，答应产品可以适当让步，承接部分测试工作，也不宜在会议上公开讨论。

当然，后来领导也提供了一些建议，他说如果觉得哪些内容可以跳过或放在二期，需要他这个层面做决策的，可以单独沟通，但在这个会上不做展开。

作为产品经理，面对需要我们决策的事项，要能快速抓住问题的核心，找到问题的根源并提出切实可行的解决方案。

（2）自身的气场

在这次会议中，产品大领导短短的几分钟发言，展现了他的气场和决策力，这让我意识到，如果我们想要在管理道路上走得更远，就需要培养这种气场和心力。

所谓心力，就是你的决策，或你布置的任务明知不合理，或者几乎不可能完成，仍然选择这么做。

如果没有这种心力，做领导带团队，会觉得很难受、很痛苦。

作为产品经理，无论是走管理路线还是专家路线，多多少少都需要具备这种气场和心力。要敢于做决策，敢于承担后果，敢于亮剑。

（3）自信和高效

领导参加的这场会议，匆匆入场，匆匆离场，时间很短，效率很高。

作为产品经理，需要这份自信、从容和高效。

因为产品经理一天的会议非常多，尤其是大公司，有时一整天都在开会，而且很多会议一开就是一两个小时，自己发言也就几分钟，大部分内容都跟我们无关。

所以，一般来讲，最好的方式是开小会，不开大会。如果参加大会，也只在需要发言时上会，发言结束后，其他内容若与自己无关，就可以选择退出会议。

有个词叫以小见大，形容这场会议再适合不过了。短短的一场会议，看似很小，背后大有学问，也让我深受启发。