Git 团队协作（二）：如何组织一个富有成效的会议？

编者按：本文节选自童仲毅译《Git 团队协作》一书中的部分章节。

我的整个职业生涯几乎都是在分布式团队中度过的，我和同事不在同一个办公室。我们在同一个时区都是少有的事。这些经历让我形成了不少良好的沟通习惯，我常常将这些习惯当作是理所当然的。如果你在工作中使用的是约定好的方法，那么你的团队或许已经有一套推进项目的会议模式。

你的项目以及其中的每个子模块，都应该有开头、主体和结尾三个部分。Dave Gray、 Sunni Brown 和 James Macanufo 合著的 Gamestorming（http://shop.oreilly.com/product/9780596804183.do）一书详细阐述了“开头—主体—结尾”这一流程。这个流程还被教师应用于课堂教学：教师首先告诉你学什么，让你参与学习，然后总结你学到的知识。

回到会议安排上来，你应该在脑中熟记这个规律：开场、参与、总结。这个规律最适用于会议。我经常看到一些会议，准备了讨论话题的大纲，但最后的结果却差强人意。例如，项目刚开始时，团队正在参与构思会议，创造性思维者的参与最为积极且成效显著，如下所示。

时间表：构思阶段总时间为 45 分钟

• 辨别问题本质（10 分钟）

• 头脑风暴，寻找解决方案（25 分钟）

• 整理想法（5 分钟）

• 挑选至多三个想法进行验证（5 分钟）

提前制定会议目标非常容易，这样就可以用一些自由时间来讨论问题。

项目启动)

项目启动会是一个混乱的时期，尤其当你召集的是一个新团队，而团队的成员在工作上没有交集时。如果有可能，请召集一个全员参与的启动会议。对分布式团队来说，时间和金钱的代价会是异常昂贵的。

面对面的会议更佳

理想情况下，启动会议是面对面进行的。如果难以实现，试着将人们聚集到尽量少的几个地点，然后使用视频电话召开会议。

当所有人共处一地时，你可以充分利用他们共度的时光。你可以借助白板、活页挂图和便利贴，用动作来表达你的想法。看到大家共同作出的决策是非常令人高兴的，它有助于激励团队一起参与到项目中来。

追踪进展

项目开始后，你会希望定期与团队开个会。当你在分布式团队中工作时，逃避问题是非常容易的事。跟不上进度是一件很令人难堪的事，而且通常是一个复杂的问题。保持沟通是一个处理此类问题的好习惯，但这并不意味着要将所有时间浪费在开会上。成功的团队总是有着明确的目标。我喜欢一周一次的、非常短小的冲刺周期。在这么短的时间内很难隐藏什么问题。不过，它和微观管理没有关系。它的目的在于保证项目持续推进。以下每个会议都有一个与项目相关的具体目标。

• 冲刺计划会议

• 作为项目经理，我发现有两种类型的员工：其中一种员工随时准备接手新的工作并对做完的工作负责，而另一种员工倾向于别人为他们安排好工作。那些希望别人为他们安排工作的成员经常寻求帮助，来弄清楚他们能胜任哪些任务，以及从项目整体来说哪些任务有最高的商业价值。冲刺计划会议可以邀请全员参与，而如果你不希望在冲刺计划会议上耗费过多时间，也可以仅让跟客户打交道的成员和高级开发者参与。

• 承诺会议

• 这类会议应该挑选每周几天中的同一时间召开。会议的成果是团队成员针对他们工作中作出的“承诺”进行汇报。他们不应该只汇报“今天在做什么”，还应该汇报“下次开会前计划完成哪些工作”。会议应该是采用“不责备，不让人羞愧”的轮流发言方式，每个人汇报进展的时间不应该超过三分钟。更大的具体问题可以留到后续的会议中去讨论。在 Scrum 的用语中，这类承诺会议称为“站立会议”，参会者一般站着参加会议。我发现“站立”对于那些没有接受过 Scrum 训练的团队来说并不准确。使用适合你的团队的术语，但要确保你能从会议中获得有价值的信息。

• 深入研讨会议

• 任何承诺会议之后还需要深入讨论的问题都应该安排一个后续的深入研讨会议。在理想情况下，你的团队将使用一个日程系统，比如“谷歌日历”（http://google.com/calendar），成员可以在上面查看同事的日程，并很容易找出一段空闲时间来安排后续的讨论。一般来说，我每周会保留一两个 45 分钟的时间段用于深入研讨会议，紧接在两个 15 分钟的承诺会议后。只有相关的人员需要参加深入研讨会议，虽然我们欢迎任何人加入。

• 冲刺演示会议

• 团队应该每周找一个时间一起展示工作。在演示会议中，每个取得成果的成员应该列出完成的工单号，并展示工作成果。每周安排一次演示会议形成工作“永远即将完成”的文化，在这种文化中，工作被分成易于执行的小块。这类会议提供了一个绝佳的机会，让你发现新想法，分辨可能需要文档记录或后续修复的 bug，或者是讨论下一个冲刺中必要的流程改进。由于团队的凝聚力及沟通水平不同，你或许会觉得这些会议是不必要的。但如果你发现越来越多未完成的功能通过了代码审查，或是优秀的工作没有得到重视，或是发现你的团队没有经常相互求助，那么，是时候引进每周的演示会议了。 Google Hangouts（http://www.google.com/+/learnmore/hangouts）和 GoToMeeting（http://gotomeeting.com/）非常适合这种会议。

• 冲刺回顾会议

• 在每个冲刺结束的时候，你应该召集团队一起讨论工作流程。找出运转良好的部分以及需要改进的部分。我有一个行之有效的方法，即让每个成员用下面这些提示语作答：我希望；我想要；我担心。这个会议应该只邀请核心成员参加。会议时间可长可短，但对小团队而言大致需要一个小时。

在一个分布式团队中，你可能还需要安排一些定期的社交电话会议。Lullabot（http://lullabot.com/）是一个完全分布式的公司，拥有大约 50 名员工。它将下面几个与项目无关的电话会议加到了日程中。以下会议的目的是培养成员之间的同理心。

• 全公司的站立会议

• 每周举行一次电话会议，通过抽签选出发言者，每人用不超过两分钟的时间聊一聊他们的工作和业余生活。当公司的规模还小时，每个人都要在这个会议上发言。随着公司规模增长，这个抽签的系统便应运而生，一对一的电话会议也加进了日程。

• 一对一会议

• 通过抽签选出两三名员工，找个方便的地方交流各自的生活、兴趣等任何事。

最重要的是，这些电话会议只有语音，成员可以在打电话的时候做别的事情（往洗碗机上装盘子，如果手机信号够好，甚至可以在室外活动）。

培养同理心

当你在分布式团队中工作时，将代码团队中的成员视为“资源”而不是个体会容易得多。培养团队间的信任关系需要有意识的努力。彼此信任而不是畏惧的团队将会诞生更多灵感，也将更愿意在困境中寻找合适、创新的解决方案。

提升团队的同理心的第一步是恰如其分地关心你的同事。你不需要成为每个人的心理治疗师，但花点时间和他们聊聊私下的生活会是非常值得的。如果你被认为很有爱心，大家会更加喜欢你，从而增进你们之间的信任。作为技术型的项目经理，经常有人邀请我倾听他们讨论问题。在他们为我介绍问题背景之后，我对问题粗浅的理解可以迫使关注点回到问题的本质，也就是解决方案的来源。但这种对话在新团队中鲜有发生，因为我必须先取得团队中每个人的信任（在他们不知道正确答案时，我不会妄加评判；我会帮助他们专注于解决问题，而不是在他们讨论时只顾自己打字）。

以下是一些帮助你表现出“恰如其分”的关心的方法。

• 搜集故事

• 询问人们的日常生活；关于他们正在解决的有意思的挑战；关于你们共事的项目中他们喜欢（或不喜欢）的地方。这不是一个闲聊的机会！这是一个将谈话对象和他们的生活联系起来的好机会。

• 带有目的地倾听

• 当你和人们交谈时，专注地倾听。不要同时做几件事情。完整地倾听他们所说的内容。不要打断他们，除非你感到困惑，希望得到解释。一些人是天生的演讲家，总是能滔滔不绝地讲下去。对于这些人，你或许希望预先计划一个结束的时间点。

• 旧事重提

• 如果有人和你谈起过他们的生活，时不时问问他们之前的故事有什么变化。他们的女儿还在长牙吗？感冒怎么样了？今天好一些了吗？

我考虑将这个清单视为“同理心的培养”（http://gitforteams.com/resources/cultivating-empathy.html）。每个人能够做到并且也应该和同事保持一定的联系。

回顾

上述会议是总结经验、取长补短的最佳时机。这些会议还应该整理未来可以重用的模板。一段工作的结束会议应该是不责备、不让人羞愧的，人们可以畅谈做得不好的地方。作为项目经理，我很少为我的决定感到后悔。我依靠团队提供的信息来帮助我作出最好的决策。所以在回顾中，我总是很容易避免一些“本来应该、可以这么做”的诱惑。不过，我确实在留意一些面向未来的模式。换言之，明确我们在会议中提出的哪些问题本可以得到解决，以获得另一些有用的信息（这些信息或许会让我们在未来遇到同类项目时能够作出更好的决策）。

从版本控制的角度来说，项目的终点也是一个巨大的机遇，你可以挑出你最喜欢的工单，记录它们与众不同的原因。或许它提出了一种组织信息的新方式，而你想要重用这一点。看一看 Git 仓库，寻找一些特别好的提交信息，供以后的项目参考。

图书简介：http://www.ituring.com.cn/book/1779

相关阅读：

Git团队协作（一）：如何组建充满斗志和凝聚力的团队？