|
|
# 15 | 如何组织有效的会议？
|
|
|
|
|
|
产品需求讨论会对产品经理来说是家常便饭。
|
|
|
|
|
|
当产品经理对我们应该解决什么痛点、有哪些功能有了一个计划，接下来就需要组织产品需求讨论会了。我会和工程师、设计师等团队成员坐在一起讨论对这个功能的看法，跟他们讲讲这些功能一步一步的体验是什么样的：设计师是不是觉得这个设计是以人为本的；工程师会不会说我们的底层结构不支持，这个根本做不了。
|
|
|
|
|
|
**简单地说， 产品需求讨论会目的是要明确我们的功能、量化成功的标准和时间表，团队成员达成一致意见后就开始撸起袖子努力干了。**
|
|
|
|
|
|
首先，我跟你分享一个失败的产品需求讨论会，通过这个例子让你明白会议低效的几个常见原因，以及组织会议的几个误区。然后，针对这个案例的具体情况，我会告诉你怎么才能提高产品需求会的效率。最后，我会结合以前自己踩过的坑（说多了都是泪啊），跟你分享几个组织高效会议的独门秘诀。
|
|
|
|
|
|
## 案例：一个失败的产品需求讨论会
|
|
|
|
|
|
前段时间，隔壁组的产品经理组织了一个产品需求讨论会，讨论一个由他们主导的新功能，因为这个功能需要和我们合作才能实现，所以我们组也被邀请去开会。这个产品经理写了一本厚重的产品需求文档，组织大家每天一个小时讨论这个文档。
|
|
|
|
|
|
这个会议共有21人参加，包括：我们组的产品经理、工程经理、工程负责人和运营经理，他们组的产品经理、高级工程经理、工程经理、工程负责人、5个工程师、2个律师、设计师、设计师经理、数据科学家、用户体验调研师、运营经理、运营专员。
|
|
|
|
|
|
如此多的人员每天聚在一起一个小时，逐项地讨论这个需求文档，进展非常慢。在第五天的时候，他们的高级工程经理忍无可忍，当场问责：“每天在这里浪费时间，结果什么都没有讨论出来，这个模式根本不行”。这个产品经理瞬间不知道该怎么办了。
|
|
|
|
|
|
这次的产品需求讨论会，可以说是我在Facebook三年多以来开过的最杂乱无章的会。那么，我来给你分析一下这个产品需求讨论会失败的原因，其实这些原因都源于对产品需求会认知的误区。
|
|
|
|
|
|
1. **以为开会要让全组的人都有参与感，所以邀请了所有人，导致参会者众多。** 这个新功能是针对众多媒体公司的，有点类似企业软件。它是一个复杂的工作流，涉及非常多的情况，每种情况对应的逻辑都不同，而且要符合对应的法律、政策等要求。
|
|
|
其实真正懂这个功能的也只有三四个人，但是团队其他成员都想参与进来，可以对产品功能做一些决定，而这个产品经理也希望可以讨好团队的每个成员。所以，会议的大部分时间都花在给这些不懂产品的人解答最基本的问题上，因此效率非常低。
|
|
|
|
|
|
2. **以为多开几次会，多聊聊，效率会很高，但是大家都有很多会议要参加，因此每次开会都有不一样的人缺勤，导致会议效率低下。** 每次开会都要跟上次缺席的人同步进度，往往会议开始的前十分钟甚至更长的时间，都浪费在这里了，这就导致了会议效率特别低下。
|
|
|
|
|
|
3. **以为开会的目的是要从头开始逐项讨论，并得到大家一致的认同，所以细节讨论占据了会议大部分时间，反而来不及做重要的决定。** 会议的模式决定了，如果一个成员有疑问，大家就都要停下来解决这个问题，一个小时很快就过去，于是未来得及做的重要决定又要第二天的会议来讨论。
|
|
|
|
|
|
|
|
|
那针对这样的情况，通过怎样的方式才可以避免呢？
|
|
|
|
|
|
1. **一鼓作气 ，并设定一个需要作出决定的时间。**
|
|
|
比如，这个复杂功能的需求讨论会可以把大家集中在一起5个小时，将100%的精力投入到整个会议中，一次搞定而不要分散成多次进行。如果这5个小时讨论不出结果，可以设定一个截止日期（比如周五之前），如果讨论不出来就加班继续讨论。
|
|
|
人类其实是一个很有意思的物种，没有截止日期的话，大家就会觉得有的是时间，拖来拖去；如果设置了截止日期，大家就会觉得工作压力大，最终争分夺秒赶在截止日期的时候完成。
|
|
|
所以，即使不知道这个会议需要多久才能开完，也一定要设置一个截止日期，哪怕到时候没能完成，往后推两天也比没有截止日期的效果来得好。
|
|
|
|
|
|
2. **分工明确，减少参会人数。**
|
|
|
可以先开一个项目启动会议。你可以邀请团队所有成员参加这个启动会，告诉他们这个产品开发的背景知识、调研结果、核心原则等战略和原则性的内容。比如，对于网红新的赚钱方式的讨论，你可以告诉大家一定不能允许网红自行植入软广，这样才能保证我们可以控制营销内容和普通内容的比例。
|
|
|
按照工作内容划分小组，并确定每个小组的成功标准、具体负责人，然后每个小组分别开会。这个小组划分的工作可以在项目启动会上完成。在这个案例里，你可以成立一个小组专门负责法律问题，小组成员包括律师、运营人员；再设置一个小组负责帮助网红适应和开启新的功能，小组成员包括用户体验分析师、负责增长的工程师、数据科学家等。
|
|
|
每周召集所有成员开一次会，有每个小组的负责人汇报工作进度，并解决他们遇到的问题。这样既可以满足其他成员了解整个项目进展的需求，增加他们的归属感，又可以减少每个决定需要的人员数量，提高会议效率。
|
|
|
|
|
|
|
|
|
## 组织成功产品需求会的秘诀
|
|
|
|
|
|
根据我自己的工作经验，以及所见所闻，我给你总结几个产品经理组织高效产品需求会议的秘诀。
|
|
|
|
|
|
1. **精准管理开会的时间。**在会议开始前，做好会议时间规划文档，精准到分钟，你可以采用上周数据更新（3分钟，张娜）、产品测试结果（5分钟，小王）这样的方式。
|
|
|
比如，第一部分由某工程师介绍功能开发计划，你给他规划的时间是 5 分钟。如果大家讨论无足轻重的细节问题或者快要到5分钟的时候，你可以礼貌地提醒大家注意时间。虽然这种方式打断了大家的讨论，但会议非常有效率，会后也没有人因为被打断觉得不被尊重。
|
|
|
以前我没有做会议时间规划时，不好意思打断别人，结果每次开会都有二十分钟甚至更长的时间在讨论无关紧要的问题，而且往往只有两个人针对这种问题争论不休，其他人都无所事事。但是，自从有了精确管理开会时间的文档，我可以非常礼貌地打断这种无关紧要的争论，并且他们会非常自觉地把这个问题留到会后单独讨论解决。
|
|
|
|
|
|
2. **如果无法做出统一的决定，那就统一大家做决定的思考方式。这是一个可以让团队意见统一的迂回战术。**
|
|
|
比如，开会的时候大家一直在争论到底是做A决定还是B决定，这样的情况我们可以先不讨论到底是选A还是B。我们可以约定用更多的数据或者用户反馈来做决定，并统一做下一步决定的思考方式：如果数据达到X%我们就选择A， 否则就选B。
|
|
|
通过约定统一的思考方式，可以让僵持不下的两方取得统一意见，这种公允的决策方式可以取得两方人的信服。
|
|
|
我以前就遇到过这个问题，设计师、工程师虎视眈眈，公说公有理，婆说婆有理，谁都不肯让步，即使我更认同工程师的想法，也不能在这个时候直接怼设计师，否则这场争论不但不会停止，反而会扩大。但是，我采用“统一他们思考问题的方式”的迂回战术，那双方很快就点点头表示认可，问题随之解决了。
|
|
|
原因是什么呢？两个人的看法可以说都是对的，因为他们看重的情况不一样。但是，看完数据后，我和设计师说：“你的假设很有道理，但是通过数据我们发现，这种情况并不多见，所以综合考虑，我们决定做XXX”。这时，设计师会点点头，表示认可。最终，和平就这么来了。
|
|
|
|
|
|
3. **会议开始时先说明会议要达到的目的。**
|
|
|
比如，在会议开始时，告诉大家未来的30分钟我们需要一起做出什么决定。那么当会议开始后，大家一般都会直奔主题，可以非常有效率的得到你想要的结果，会议成员也会觉得这三十分钟没有白白浪费掉。
|
|
|
我刚开始做产品经理时，就犯了一个错误。我组织了一个确定成功指标的会，但是没有和参会者说明会议目的，最终三十分钟的会议什么问题都没有解决。会后就有人跟我的老板反映，白白浪费了三十分钟，什么问题都没解决。被老板大骂一通后，我认识到了问题出在哪里，所以吃一堑长一智，在每次会议开始时先说明要达到的目的，这种问题就再也没有出现过了。
|
|
|
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
接下来，我给你提炼一下本篇文章的要点。
|
|
|
|
|
|
我从一个失败的产品需求讨论会为切入点，跟你分析了造成会议低效的原因往往是：每次都邀请所有人参会，并让细节的讨论占据了太多的时间。因此，针对比较复杂的产品需求讨论会，你可以这样做：1. 一鼓作气，尽量通过一次会议解决，如果解决不了，就设置一个截止日期；2. 按照产品内容分成小组，然后各小组讨论，最后汇总。
|
|
|
|
|
|
我还跟你分享了我踩坑之后获得的独门秘诀：1.精准管理开会事项，管理时间到分钟；2.如果无法做出统一的决定，那就统一大家做决定的思考方式，尤其适用于两方僵持不下，各自都非常往心里去的紧张情况；3.会议开始时先说明会议要到的目的，比如设定出产品路线图，或者确定产品成功指标，一定要明确这个目的。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
回想一下，上一次你组织的或者参加的失败的产品需求会议，你认为会议效率低下的原因是什么？如果可以重新来一次，你会在哪些方面进行改进？欢迎你给我留言。
|
|
|
|