阿里妹导读：复盘是项目结束后必不可少的阶段，好的复盘会议能够有效地促进团队成长。今天，阿里项目管理专家鹿迦以自身的经验，为大家分享如何做好一个项目的复盘。这篇文章分成两个部分，第一部分简单阐述对这种回顾会议的理解，认识会议的真正价值；第二部分是分享个人操作的团队回顾会议流程。
在阿里天猫新零售的天地会项目中，因为我参与的团队是成立不到2个月的feature team，再加上团队成员来自于多个不同的BU（有钉钉的、天猫新零售的、手淘的），团队处在一个快速磨合成长期，在合适的节点上开展一个有效的团队回顾会议（也可以叫做复盘会议）可以对团队成长和进化起到一个非常明显的加速作用。
抱着这样的信念，我们上周组织了一个团队回顾会议，基于团队成员的反馈这个会议算是取得了令人满意的结果，大家不仅加深了相互的了解、公开暴露了一些团队中隐藏的问题，更帮助大家对这些问题做了比较深入的探讨和分析，并产出了可落地的行动。
一、我理解的团队回顾会议
回顾会议（retrospective meeting）是来自敏捷方法scrum，这个会议是Scrum检视与调整的一个重要的环节，在这个会议上，我们鼓励团队对自己的开发过程进行改进，并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作。
就像我们频繁的迭代和交付是为了快速地获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是想更快地得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力的不断提升。
但是开好回顾会议并不简单，甚至我认为回顾会议是团队中最难开好的一个会议，但开好了也是价值最大的一个会议。我们整理了一下，认为这个会议可能达到的五个层次：
单向宣讲式的回顾会议：团队管理者事先完成了整个回顾分析，会上只是面向团队成员做一个回顾结论的宣讲和说明。很明显，这种层次的回顾会议不仅很有可能不能发现团队最重要的问题，更不利的是很难让结论取得团队成员发自内心的认同。
各自表达式的回顾会议：团队成员没有真的想敞开内心参与回顾会议，往往只是迫于会上的点名而击鼓传花式地各自讲自己的内容和观点，对其他人的观点没有回应，也没有质疑。这是明显的团队成员害怕冲突的表现，团队成员之间没有真正的融合，背后真正的问题可能是没有建立团队成员之间的信任。
争论推责式的回顾会议：大家抢着发言，但是气氛紧张，经常有不礼貌地打断他人讲话的情况出现，大家都极力避免责任被认定到自己的头上，往往需要老板在最终的时候决策。定责式的回顾会议是我们需要极力避免的，这个不是我们回顾会议的目标，定责的行动往往会导致大家关闭沟通的门，导致真正的问题被掩盖。
发散讨论式的回顾会议：回顾中抛出的问题很多，讨论的的过程中往往还会从一个问题跳跃到其他问题上，导致会议中涉及的论点不断发散，最终往往由于问题过多，没有时间也没办法形成能落地的结论。没有结论的会议，也就没有办法拿到最终的会议价值。
聚焦共创式的回顾会议：明确回顾的目标是通过团队共创的方式发现团队持续进化的机会，鼓励大家用坦诚、合作、成长的心态挖掘团队改进的机会，并通过区分优先级以在最有价值的机会点上切实落地改进的行动。这个层次才是我们理想的情况，是我们追求的目标。
二、可参考的回顾会议流程
我们操作的回顾会议基本流程是参考了《Agile Retrospectives》这本书中所划分的会议5个阶段：
准备
收集数据
产生见解
确定改进项
结束会议
那我就按这几个阶段来讲讲怎么做。
2.1 准备
准备阶段其实是非常重要的，一些初次主持回顾会议的同学往往会忽视这个阶段，一上来就让大家写小卡片，这样不仅效果不好，次数多了更给人枯燥重复、走形式的感觉。
准备阶段我往往会选择做下面几件事：
设定一个安全的环境
回顾会议不仅仅希望大家能参与进来，更重要的是能敞开心扉，大家没有顾虑地把问题暴露出来，找到改进的办法。但事实是肯定有人担心回顾会议会成为一个批判会议，在认为这个会议的目的是找到这个迭代中犯错的那个人，并把他拎出来痛批一顿，看以后还有谁敢再犯。如果这样大家肯定会有所保留，担心说错话，会议上就找不到真正的问题。
一般我
