有效的会议
之所以有这篇文章，是因为有段时间开了一堆拖沓无用的会议：目标不明确，讨论无意义，未得出有效结论，占用了大量时间。对这种会议方式深恶痛绝，正好看到这篇文章，于是思考了一下如何改进现有的会议进程。从流程上避免冗余，拖沓，推诿的会议。
罗伯特议事规则
对于每个会议场景，有不同的实施方案，但是《罗伯特议事规则》列出了一些必须遵守的规则，这些规则在很大程度上能够保持会议的高效进行。
《罗伯特议事规则》
- 同时只能有一个议提：一旦一个提议被提出来以后，它就是当前唯一可以讨论的议题，必须先把它解决了，或者经表决同意把它先搁置了，然后才能提下一个提议。
- 意见相左的双方应轮流得到发言权：辩论的时候有人请求发言，主持人应该先问他持的是哪一方的观点，如果其观点与上一位发言人相反，那么他有优先权（比如有若干人同时要求发言）。
- 主持人必须请反方表决：必须进行正、反两方分别的表决，缺一不可。不可以正方表决后，发现已经达到表决额度的要求，就认为没有必要再请反对方表决。
- 反对人身攻击：必须制止脱离议题本身的人身攻击。禁止辱骂或讥讽的语言。
- 辩论必须围绕当前待决议题：如果发言人的言论显得与议题无关，而且其他与会成员已表现出了对此的反感（如嘘声），发言人的发言应该得到制止。
- 拆分议题：如果一个待决议题可以被分成若干小的议题，而且与会成员倾向于就其中小的问题分别讨论，可以提议将议题拆分。
- 避免多次讨论：在一届会议期间，一旦会议对某一议题做出了决定，同一个议题，或者本质上的同一个议题，不能再次讨论，除非发生了特殊情况。
- 谨慎对待新议题：如果对某个议题做了暂时性的处理，并没有形成最终决定，那么不可以引入任何一旦通过就会干扰到会议对原议题讨论时的立场的提议，无论新提议对原提议有正面还是负面的影响。
会议准备
在如上议事规则的基础上，那么模拟一个会议拟定的场景：
|
|
已有场景的会议流程
在会议准备阶段，我们可以看到是否真的需要召开这场会议。我们来对一些互联网公司常见的会议场景进行拆分。
工作进度汇报
工作进度汇报可用一些项目管理工具来替代，如Worktile，Tower，Teambition等，不过在一些重要节点还是需要进行会议确认，需要整个项目组成员参与。节点会议的意义在于多方确认进度，会议过程中可能发现本部门或者其他部门存在但一直没有发觉的问题，及时调整实施方案。如遇突发情况需要多方沟通得出解决方案，可准备好问题及可能出现的情况、与各情况下的实施预案，并及时组织一场会议，项目中遇到突发情况最忌拖延瞒报。
|
|
需求评审会议
需求评审会议作为项目的起始点，对项目的顺利进行及产品质量的保证有重要意义，需要PM产品部门全程的沟通协调。如果多方对需求中一些点异议较多，提出修改意见，产品部门再次完善之后可再进行
|
|
在各部门进行研发时长评估的时候可形成类似如下的甘特图：
|
|
从甘特图可以清晰看到整个项目的排期及每个阶段的进度信息，以进行全局掌控。
code review会议
code review会议一般在项目即将收尾的时候进行，开发团队内部对代码进行验收，team leader或者项目负责人负责整个会议流程。参会的小组成员可能并不是项目所属人员，因此需要先对需求进行讲解，以便参与人员对整个流程有所了解，使得更加容易理解编码逻辑。code review是对代码质量的保证，也是团队成员学习他人编码风格与新技术的机会，因此团队内部需要重视该会议。
代码review check项：
- 资金损失风险；
- 漏洞，导致舆论压力；
- 对系统可用性影响：业务前后逻辑异常、编码错误 等
- 对系统性能影响：慢sql、缓存、死循环、不合适的日志 等
- 高并发问题；
- 数据问题：不能丢失、错乱；
- 是否增加了必要的监控；
|
|