https://mp.weixin.qq.com/s/Mn0If87z8NO1QM7pHTuiaQ

https://mp.weixin.qq.com/s/pgYc-lRCdpHdjhG-9gkHTw

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

在阿里天猫新零售的天地会项目中,因为我参与的团队是成立不到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. 如果需要,别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。

 

阿里毕玄:技术人应如何选择职业发展路线?

成功的会议:有成果,高效率,这样的会下次还想开 1.会前准备 做好整体情况整理(项目组大的话,不是所有情况都被所有人了解),统一对基础信息的完整认知。 引发参与积极性:大咖要做好一对一动员,传统激励和本次会议的特别激励(需要脑洞,也有套路) 2.会中执行 类似文章中写的流程方法 此外要点:大咖引领,骨干积极 3.会后执行 关键在于归纳在归纳 不能经常出现的事情,早晚被遗忘。 项目中遇到的经验或教训则作为抽象方法原则的案例解释,加深新人的感性认识。

1.会前:会议目标/重点 2.会中:会议产出(可以是文档、达成的共识) 3.会后:或到下次开会时要确认或追踪上次达成的共识有没有落实

阿里妹导读:Hi,好久不见!过年期间有木有一不小心想起可爱善良的阿里妹?

想起假期的美(lai)好(chuang),可能很多小伙伴和阿里妹一样,还有些许不舍和眷恋。可是想想,我们从最有归属感的老家,来到了最有奔头的天地,为了所爱的人、为更好的自己而奋斗,是否也是一种守护?

既然选择了远方,便只顾风雨兼程。

言归正传。俗话说,一年之计在于春、一日之计在于晨。年后开工的第一天,我们来解锁晨会的新姿势:“站会”。站会到底有没有必要开?如何才能高效地开好站会?下面我们结合阿里部分技术团队的实践经验,一起来看看。

作者介绍:舍卫(花名),现就职于阿里巴巴研发效能事业部阿拉丁团队。

站会的目标

说到站会,人们最熟悉的是Scrum站会,典型的形式是团队围成一圈,依次回答三个问题:昨天做了什么?今天准备什么?有什么阻碍或问题?

通过站会,Scrum团队成员了解其他成员的工作,从而更好地协作,达成迭代目标。

看板方法应用得当、可视化价值流实践执行到位,以上三个问题完全可以清晰地展示在看板上,所以没有必要再回答这些问题了。那站会的目标是什么呢?

回到精益看板方法本身的目标——顺畅和高质量地持续交付有用的价值,相应的,看板站会要聚焦于价值的流动,而非个人工作。站会的目标是:促进团队有效协作和聚焦,促进价值顺畅流动和交付,同时通过站会同步需求进展和暴露问题及风险,把可视化价值流实践落地到位。

站会的前提

在建立了如下图的精益看板系统的可视化价值流、明确流转规则和限制在制品数量的三个实践之后,还需要管理价值流动和建立效能反馈闭环并持续改进。

管理价值的流动具体包含管理价值流动过程、价值的输入和价值的输出,关于管理价值流动过程的一个很重要的实践就是每日看板站会。

以云效看板为例

站会的组织形式

1、频次:每天(每个工作日),时长不超过15分钟,一般在早上,具体时间团队可根据实际情况调整,一般建议9:45或10点开始;

2、三个相同:同一个团队在同一时间、同一地点在看板前进行日站会,形成固定的节奏后,会变成团队的习惯;

3、协调人:团队成员站在围在看板前,由一位协调人来带领团队从右往左(⬅️)逐列走读看板;协调人可以固定,也可以轮流进行;

4、电脑:为了让站会更加聚焦和高效,负责投屏和记录的同学可以带电脑,其他人不需要带电脑;

站会前:需求和任务的状态已更新

1、团队已按照统一优先级的规范更新需求的优先级,辅助优先级,状态、期望日期等。

2、开发同学按照实际情况更新需求和任务的状态(做到任务向需求对齐)。

  • 需求负责人负责协调把开发中的需求拆分成任务(如下图),并协调需求从开发完成,测试,直到发布完成为止;

  • 已拆分好的任务需指派到个人,任务的颗粒度在1-2天的工作量,确保每天都有看得见的进展 ,及时暴露风险和问题;

  • 任务责任人已更新好任务的状态和截止日期;

  • 如有外包或则接口人合作:外包同学也需要在站会前更新状态,接口人按流转规则进行状态流转。

站会重点关注的信息

站会上不需要检视每一张卡片,本着“促进价值顺畅流动和交付” 的目的,我们要重点关注影响价值流动的问题和阻碍项,如下图所示,绝大部分问题会标记橙色或红色,可以很清晰地体现在云效电子看板上。

  • 瓶颈和队列:某个环节不顺畅时,需求积压形成队列,这就是瓶颈所在,瓶颈是站会第一重点关注点,因为系统的流量往往是由瓶颈决定,只有解决了瓶颈问题,价值才能顺畅地流动。看板上的表现就是某一列的需求卡片数量特别多。

  • 关键的缺陷:缺陷会阻碍需求的流动,而且缺陷多容易出现需求积压,从而阻碍其他需求的流动。阻塞需求流动的缺陷需要及时解决,期待做到缺陷日清(缺陷发现后24小时内解决,甚至当天就解决),在Fixed状态(指缺陷已修复,待提出者验证)的缺陷需要及时验证和关闭。保持缺陷及时发现即时解决和关闭,保持存量缺陷保持低水位。站会时需要抽1-2分钟过一下整体缺陷的状况。

  • 重点关注的需求:指涉及重点商业利益或风险的重点需求,看板上会用红色的标签来凸显。

  • 阻碍和问题:指因外部(如依赖)或内部(如设计缺陷)原因无法正常流动的需求。团队需关注被阻碍的需求,跟踪和推动问题解决,及时恢复它们的流动。看板上会红色的阻碍项来标记。

  • 到期或即将到期的需求:部分需求有明确的完成时间要求,例如存在对外承诺的需求。如果它们即将到期或已经到期,就需要特别关注,以确保承诺的达成。看板上快到期的需求会用橙色凸显时间,已到期的需求会用红色凸显时间。

  • 中断:指某个步骤供给不足,价值流出现中断,如上图中,就绪(待开发)这列没有需求,此时上游队列需要尽快供给到该列。

  • 未反应在看板上的问题:走读完看板,还需要添加一个问题:“是否有为反映在看板上的问题需求沟通”。团队当然需要关注没有反映到看板上的问题,同时,团队和站会的协调人需要有意识地思考,这类问题是否可以和应该反映在看板上,以提高可视化和执行的效果。

站会中:促进价值顺畅流动

  • 站会上,团队按照"站会重点关注信息6+1"从右向左检视各列,促进价值顺畅流动,同时要避免在一个问题上花费过长时间,耗时长的讨论要放在会后小范围进行。

  • 15人以内的团队,站会要能在15分钟内完成,在现实中,效果不好的站会,往往耗时会比较长。

  • 站会中讨论带来的变化,需即时更新到看板上,如有问题,也需要及时记录。

  • 下图给出了站会中应该做到和应避免的问题:

还需要明确的是,站会只是团队沟通的一个场景,更多的沟通要在平时和更小范围内发生,而不是过度依赖于站会。

站会后:信息透明,风险和问题跟进

站会需要达成的成果:

  • 看板已处于最新的状态,反映站会讨论的结果。

  • 识别阻碍需求流动的问题,并现场解决或则安排会后跟踪的Action。

  • 团队成员了解项目的整体进展和状态。

  • 团队成员清楚工作的优先级。

  • 会后小范围讨论需求较长时间才能解决的问题。

总结:

  • 站会的目标是:促进团队有效协作和聚焦,促进价值顺畅流动和交付。

  • 站会要以价值交付为线索,从右向左检视需求的状态,聚焦于发现和处理价值流动中的问题。

  • 不应该依赖站会检查每个人的工作,价值交付的状态和问题应该已清晰的体现在看板上,良好设计和应用的看板是高效站会的基础。

  • 更多的协作应该即时发生,不应该完全依赖站会来进行团队协作。

  • 一个好的站会,帮助团队了解整体的价值流动状况,促进有效的协作,并即使处理价值流动的问题,保障价值顺畅流动。

附1:站会Checklist:

1.   需求和任务的状态在站会前已更新;

2.  提醒带电脑同学合上电脑,只有投屏和做记录的同学使用电脑;

3.  从右往左检视各列,按照6+1类关注点进行;

4.  开发中的需求数量是否已超过卡片数量的限制;

5.  开发中任务是否向需求对齐;

6.  需求是否按照既定的流转规则进行流转;

7.  单独快速过一下缺陷的总体状况,保持缺陷库存低水位;

8.  记录要跟踪的问题和依赖项;

9.  会后小范围讨论遗留要解决的问题;

附2:站会中会碰到的问题:

Q:开发同学站会上讲了很多,可产品经理同学却听不懂,同时对需求的进展也不太清晰。

A:按照Scrum的方式,回答三个问题,开发同学往往说的是技术实现和细节,产品经理自然会听不懂。需求作为价值是产品经理的输入,看板关注的是价值流动,不是任务的完成情况,需求的状态和问题可以很清晰地在看板上体现出来,同时在开发中的需求也会拆分成各端或各模块的任务,拉通技术各角色之间的协同。采用云效电子看板既可以看到价值的流动,也可以看到任务的进展和对齐,产品和开发同学都可以一目了然知道目前的进展与问题。

Q:团队处于两地,甚至多地,站会如何开?

A:电子看板的好处就是便于异地开发,各地成员都打开看板页面,同时用电话会议的方式接入,进行异地站会。目前云效看板已可以做到需求卡片移动后实时同步。

Q:为啥看板要从右到左检视各列,而不是从左到右检视呢?

A:从右往左,一方面体现价值拉动的方向,另一方面是为了更好地贯彻“暂缓开始,聚焦完成”的原则,让接近完成的需求尽快的完成,而不是开始更多的需求开发。譬如测试中发现的Bug,从右到左更方便优先解决Bug。

Q:站会时间到了,但还有个别同学没有到,是等他还是不等?

A:团队需要共识此类事情发生的机制,避免这样的事情发生。当确实有个别成员迟到了,一般建议站会还要在固定的时间和地点进行,当然团队对于迟到可以有团队处理的办法,譬如邀请迟到的同学给大家买水果吃等等。

Q:两个需求都进行了近一半却都不能提测?如下图。

A:图中用红框圈起来的两个需求,一个是前端任务已完成,后端任务在处理中,另一个是前端任务在处理中,后端任务已完成,这种情况需要避免,团队需要聚焦其中一个需求,让其快速完成,而不是启动两个,让两个都只是完成一半或90%。

最后,关于站会,你有哪些想法?欢迎在留言区分享,我们期待与更多同学一起交流、讨论。


评论关闭
IT干货网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

学习网站视频集锦