开会=浪费时间？阿里技术团队这样开项目复盘会

阿里妹导读：复盘是项目结束后必不可少的阶段，好的复盘会议能够有效地促进团队成长。今天，阿里项目管理专家鹿迦以自身的经验，为大家分享如何做好一个项目的复盘。这篇文章分成两个部分，第一部分简单阐述对这种回顾会议的理解，认识会议的真正价值；第二部分是分享个人操作的团队回顾会议流程。

在阿里天猫新零售的天地会项目中，因为我参与的团队是成立不到2个月的feature team，再加上团队成员来自于多个不同的BU（有钉钉的、天猫新零售的、手淘的），团队处在一个快速磨合成长期，在合适的节点上开展一个有效的团队回顾会议（也可以叫做复盘会议）可以对团队成长和进化起到一个非常明显的加速作用。

抱着这样的信念，我们上周组织了一个团队回顾会议，基于团队成员的反馈这个会议算是取得了令人满意的结果，大家不仅加深了相互的了解、公开暴露了一些团队中隐藏的问题，更帮助大家对这些问题做了比较深入的探讨和分析，并产出了可落地的行动。

一、我理解的团队回顾会议

回顾会议（retrospective meeting）是来自敏捷方法scrum，这个会议是Scrum检视与调整的一个重要的环节，在这个会议上，我们鼓励团队对自己的开发过程进行改进，并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作。

就像我们频繁的迭代和交付是为了快速地获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是想更快地得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力的不断提升。

但是开好回顾会议并不简单，甚至我认为回顾会议是团队中最难开好的一个会议，但开好了也是价值最大的一个会议。我们整理了一下，认为这个会议可能达到的五个层次：

• 单向宣讲式的回顾会议：团队管理者事先完成了整个回顾分析，会上只是面向团队成员做一个回顾结论的宣讲和说明。很明显，这种层次的回顾会议不仅很有可能不能发现团队最重要的问题，更不利的是很难让结论取得团队成员发自内心的认同。

• 各自表达式的回顾会议：团队成员没有真的想敞开内心参与回顾会议，往往只是迫于会上的点名而击鼓传花式地各自讲自己的内容和观点，对其他人的观点没有回应，也没有质疑。这是明显的团队成员害怕冲突的表现，团队成员之间没有真正的融合，背后真正的问题可能是没有建立团队成员之间的信任。

• 争论推责式的回顾会议：大家抢着发言，但是气氛紧张，经常有不礼貌地打断他人讲话的情况出现，大家都极力避免责任被认定到自己的头上，往往需要老板在最终的时候决策。定责式的回顾会议是我们需要极力避免的，这个不是我们回顾会议的目标，定责的行动往往会导致大家关闭沟通的门，导致真正的问题被掩盖。

• 发散讨论式的回顾会议：回顾中抛出的问题很多，讨论的的过程中往往还会从一个问题跳跃到其他问题上，导致会议中涉及的论点不断发散，最终往往由于问题过多，没有时间也没办法形成能落地的结论。没有结论的会议，也就没有办法拿到最终的会议价值。

• 聚焦共创式的回顾会议：明确回顾的目标是通过团队共创的方式发现团队持续进化的机会，鼓励大家用坦诚、合作、成长的心态挖掘团队改进的机会，并通过区分优先级以在最有价值的机会点上切实落地改进的行动。这个层次才是我们理想的情况，是我们追求的目标。

二、可参考的回顾会议流程

我们操作的回顾会议基本流程是参考了《Agile Retrospectives》这本书中所划分的会议5个阶段：

1. 准备

2. 收集数据

3. 产生见解

4. 确定改进项

5. 结束会议

那我就按这几个阶段来讲讲怎么做。

2.1 准备

准备阶段其实是非常重要的，一些初次主持回顾会议的同学往往会忽视这个阶段，一上来就让大家写小卡片，这样不仅效果不好，次数多了更给人枯燥重复、走形式的感觉。

准备阶段我往往会选择做下面几件事：

• 设定一个安全的环境

回顾会议不仅仅希望大家能参与进来，更重要的是能敞开心扉，大家没有顾虑地把问题暴露出来，找到改进的办法。但事实是肯定有人担心回顾会议会成为一个批判会议，在认为这个会议的目的是找到这个迭代中犯错的那个人，并把他拎出来痛批一顿，看以后还有谁敢再犯。如果这样大家肯定会有所保留，担心说错话，会议上就找不到真正的问题。

一般我们会直接声明这个会议的目的，绝对没有想追究任何人的责任的意思。不仅如此，我们还需要在会议过程中避免讨论任何个人责任的问题。

• 了解与会人的心态

这是个很有意思的事情。会议本来就令人沮丧，更何状是回顾会议这种看似是锦上添花的会议。与会者都是带着什么心态来参加的呢？这里有一种非常有意思的收集与会者心态的小活动，叫做“ESVP”：

• Explorer （探索者）

• Shopper （推销者）

• Vacationer （度假者）

• Prisoner （囚犯）

这四个角色代表了四种与会的心态，可以通过与会者不记名的投票（匿名的在贴纸上写上代表自己真实心态的角色首字母），统计完现场公开结果，就能知道会议室里大家的实际心态情况。统计的结果不一定总让人欢欣鼓舞，但这个小小的活动往往能有效的唤起大家内心的思考，帮忙确定会议的基调，很有价值。

• 激活大家的发言欲望

事实证明，一个会议上，如果一开始大家就可以不需要发言，只是听，那么很大机会大家在整个会议上都将保持沉默，没有什么想说的，尽管会议中后期你希望更多人参与发言。办法是一开始就破冰。简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难，不过没关系，这个时候大家就会开始脑子飞快的转起来了，到底哪个词比较合适。这样不仅把大家带到了回顾的思路里，更重要的是大家一开始就有机会开口表达自己的想法了。

• 把大家带到这个迭代历史的回忆中来

在开始收集数据之前，让大家先回忆这个迭代到底发生了什么，这个至关重要，不然暴露的问题很可能变成天马星空的抱怨。上面用一个词描述这个迭代的感受是一个很好的方法，但除此之外还有心情曲线法也是很有意思的方式。方法很简单，就是让大家画一条基于时间轴（标注团队的关键时刻或里程碑）的心情曲线。如图是一个团队真实的曲线结果，每个人都不一样，分享这个曲线的过程甚至能加强团队成员的相互了解，加强信任感。

2.2 收集数据

收集数据一般包含收集做得好的部分，做得不好的部分，有时还会创新想法部分。这个环节是回顾会议最具代表性的，发贴纸，然后大家各自写，一个问题一张贴纸……如下图就是一个真实的例子：

上面这个方式用得非常广泛，就不多讲了。除此之外还有一些变形的方式：

• 通过视觉化的、隐喻性的方法做引导，比如帆船回顾法。

• 模拟论坛接力留言的方式，一个问题一张A4纸，大家按顺序传递加上自己的简介，通过书写来收集数据。

2.3 产生见解

收集到了数据只是第一步，如果顺利，到此为止我们就能收集到大量的、反应真实情况的好的和需要改进的点。接下来我们需要整理了。

先分类，因为大家是各自独立写的，所以肯定会有重复的，所以把同类的放到一起我们才能让满墙的纸片不那么凌乱。分类需要花一点时间，但这个过程也是刚好让大家都了解其他人写了什么的好机会，所以我往往会邀请组员上来和我一起来做分类，一个人做卡片宣读，允许大家讨论，一个人把相同意思的卡片贴到一起。

对做得好的部分，我们需要提出来鼓励大家，希望我们能坚持下来，甚至做得更好。这个部分在实际操作中往往比较忽视，大家更愿意快点调到待改进部分。无论如何，如果发现团队士气低落，需要鼓励的话，这时就是很好的机会，每个做得好的地方你都能有感而发。

对待改进的部分，这个是本次会议的核心内容，不过很不幸，往往团队总结出来的待改进方面会比较多（>5个就算多吧），可会议时间有限，对这个部分，我们首先要做的就是确定优先级最高的核心问题（不超过3个）。确定的办法最常用的就是投票，比如每人两票。

2.4 确定改进项

当我们确定了待改进的重点之后，我们就需要讨论得出针对这些问题的改进方案。

不过别急，不要这么快就跳到了改进方案上来，针对问题我们要先分析问题的根源，找到问题最根本的原因，我们再针对原因采取改进行动，这样才能对问题做到根本的解决。

• 鱼骨图或5W的方法寻找问题根源

最常见的方法有鱼骨图法，如下图，使用方法就不解释了，大家自己google。

还有一个理论就是5个WHY，也是一个很好用的方法。

• 分组讨论

讨论寻找问题根源的的过程往往非常费时，这里常用的一个方式是把组员分组，每个小组专门讨论一个问题，我们可以限时让他们讨论出问题的根源和推荐出改进计划，这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度。

• SMART的改进计划

一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了。这点说得容易，但做起来往往困难很大，大家非常容易产出一些类似建议一样的东西，完全没办法执行。这里给大家一个小窍门，在每产出一个action的时候就问一下大家“这个action可以执行吗？能判断是否完成吗？”，这样往往就能帮忙准确判断是否SMART。

• 避免产出过多改进计划

当然还有一个陷阱就是改进计划过多，到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免，不然也没法落实。

2.5 结束会议

结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议，可以帮助我们提高下次回顾会议的组织能力。

但我最喜欢的结束会议的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人，并附上理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法。写好纸片之后，我会请大家当众宣读一下卡片内容，并亲手交给自己感谢的人，纸片格式如下：

三、提供几个需要注意的地方

1. 一般情况不建议团队的经理参加回顾会议。这有悖于准备环节中提到的设立一个安全的环境，大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重的问题，但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题。

2. 会议产生的改进计划怎么有效地跟踪？一般我们建议把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效地使得改进落地。

3. 前后回顾会议产出相同或类似的改进计划。这说明老问题一直没有解决，有的时候会发现每次改进计划都完成了，但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影，面对这样的问题，团队最好能计划一些长期的（周期跨迭代的）改进计划，下次回顾会议可以监控进展，而不是提重复的问题。

4. 如果需要，别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。

本文作者：鹿迦

阅读原文

本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。