开会的要义

前言：由两次集体项目开发有感，下文第一次项目代号S,第二次项目代号Q

本文仅讨论小团队中的开会和管理，约为10人左右，例如临时组建的小团队和沆瀣一气的家伙们组建的小团队，其他规模团队应当有其他的管理方式

关于团队开发，后来经朋友推荐，知道了人月神话,非常推荐阅读

在团队讨论中，经常会出现一些需要集体性进行决策的场景，比如决定项目的开发计划、项目的分工等，于是会有投票的决策方式。但是，这种看似公平公正的决策方式不一定是最优决策。有时在生死攸关的问题上，少数人会有更加聪明的独到的想法，但却由于多数人的无知和盲目而被动接受少数服从多数的结果。

我们应当充分尊重有不同见解，或者有坚定立场，或者有能力解决问题的成员，而不是一味地服从少数服从多数的原则。

我偏好在投票和讨论中设置弃权以为少数更加有用的想法不被埋没。

在项目发起阶段，我认为项目发起人应当充分的霸道和独裁，在项目的全局性决策上，就应当做好所有决策，以此为基础吸引其他合作者的参与。合作者在参与前，应当首先充分的了解项目的背景和目的，以及为实现该目的所准备使用的工具和资源。应当保证核心人员的全局性参与。

我偏好在决定上的霸道和独裁，但不排除需要群策群力的情况。

在开会或者讨论时，我们的讨论对象看似是整个群体，但群体终归还是由个人组成，特别是这样的小团队。在群体中的交流效果对于个人而言永远低于个人与个人的交流效果。

我偏好在发布集体性决策结果后，再针对每个人的特性，再发一条针对性的消息给相应个人。

我认为设置个性化的特定职位将有助于团队成员明确自己的工作职责。

我偏好在团队中默认一个偏将的存在，这将大大减轻项目总负责人的决策压力。

如果能有一个吉祥物就更好了。

项目发起人应当意识到其他人和自己的技术水平有所差别，在项目发起阶段，应当格外重视学习成本，而不是一直推项目进度。

在进行开会讨论前，也应保证与会者进行了相关学习，都能听懂会议内容。

在项目S中，我们采取了集体开发的方式。在这种方式下，团队成员间的沟通交流成本应当是最低的。但不免闲聊（但是还是聊的技术相关的，别的也很开心）

我并不认为集体开发中闲聊降低开发效率，反而是减少了沟通成本，也有固定的开发时间，可以更好的集中精力。

所以如果有条件进行集体开发，我推荐进行。

如果有开会，会议应当尽可能简短有力，没有人会喜欢花太多时间在开会上，仅是”开会”这一词便足以引起反感。

我认为开会应当尽量避免讨论太多细枝末节，而是聚焦于项目的全局性决策。议题应当明确，会议应当足够具有重要性。

没有会前准备的会议将是一团垃圾。会前应当充分准备，包括会议的主题、议题、时间、地点、参会人员、准备材料等。

项目发起人可在会前指定在会上谁该作如何的发言，以及准备什么材料。这可以避免冷场。

我偏好在会前安排好发言顺序，让发言人有充足准备时间和适当的紧迫感。

所有人都应当有记录会议内容的习惯。