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

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

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

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

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

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

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

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

•  

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

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

• 争论推责式的回顾会议：你们抢着发言，可是气氛紧张，常常有不礼貌地打断他人讲话的状况出现，你们都极力避免责任被认定到本身的头上，每每须要老板在最终的时候决策。定责式的回顾会议是咱们须要极力避免的，这个不是咱们回顾会议的目标，定责的行动每每会致使你们关闭沟通的门，致使真正的问题被掩盖。

• 发散讨论式的回顾会议：回顾中抛出的问题不少，讨论的的过程当中每每还会从一个问题跳跃到其余问题上，致使会议中涉及的论点不断发散，最终每每因为问题过多，没有时间也没办法造成能落地的结论。没有结论的会议，也就没有办法拿到最终的会议价值。

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

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

咱们操做的回顾会议基本流程是参考了《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 结束会议

结束会议若是有必要的话咱们能够简单对本次会议的组织作个总结建议，能够帮助咱们提升下次回顾会议的组织能力。

但我最喜欢的结束会议的方式是让你们每一个人经过一张纸片的形式感谢团队里的一我的，并附上理由。我以为这是一个很好的激励团队更多合做和相互帮助的好办法。写好纸片以后，我会请你们当众宣读一下卡片内容，并亲手交给本身感谢的人，纸片格式以下：

3、提供几个须要注意的地

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

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

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

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

原文连接