网站建设公司 倒闭,网站建设公司测评,刚建设的网站如何推广,山东公司网站建设2019独角兽企业重金招聘Python工程师标准 阿里妹导读#xff1a;复盘是项目结束后必不可少的阶段#xff0c;好的复盘会议能够有效地促进团队成长。今天#xff0c;阿里项目管理专家鹿迦以自身的经验#xff0c;为大家分享如何做好一个项目的复盘。这篇文章分… 2019独角兽企业重金招聘Python工程师标准 阿里妹导读复盘是项目结束后必不可少的阶段好的复盘会议能够有效地促进团队成长。今天阿里项目管理专家鹿迦以自身的经验为大家分享如何做好一个项目的复盘。这篇文章分成两个部分第一部分简单阐述对这种回顾会议的理解认识会议的真正价值第二部分是分享个人操作的团队回顾会议流程。 在阿里天猫新零售的天地会项目中因为我参与的团队是成立不到2个月的feature team再加上团队成员来自于多个不同的BU有钉钉的、天猫新零售的、手淘的团队处在一个快速磨合成长期在合适的节点上开展一个有效的团队回顾会议也可以叫做复盘会议可以对团队成长和进化起到一个非常明显的加速作用。 抱着这样的信念我们上周组织了一个团队回顾会议基于团队成员的反馈这个会议算是取得了令人满意的结果大家不仅加深了相互的了解、公开暴露了一些团队中隐藏的问题更帮助大家对这些问题做了比较深入的探讨和分析并产出了可落地的行动。 一、我理解的团队回顾会议 回顾会议retrospective meeting是来自敏捷方法scrum这个会议是Scrum检视与调整的一个重要的环节在这个会议上我们鼓励团队对自己的开发过程进行改进并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作。 就像我们频繁的迭代和交付是为了快速地获得外部用户的反馈进而帮助我们做产品需求的调整一样每个迭代的回顾会议就是想更快地得到大家对团队工作问题和改进点的反馈帮助团队内部的工作效能和能力的不断提升。 但是开好回顾会议并不简单甚至我认为回顾会议是团队中最难开好的一个会议但开好了也是价值最大的一个会议。我们整理了一下认为这个会议可能达到的五个层次 单向宣讲式的回顾会议团队管理者事先完成了整个回顾分析会上只是面向团队成员做一个回顾结论的宣讲和说明。很明显这种层次的回顾会议不仅很有可能不能发现团队最重要的问题更不利的是很难让结论取得团队成员发自内心的认同。 各自表达式的回顾会议团队成员没有真的想敞开内心参与回顾会议往往只是迫于会上的点名而击鼓传花式地各自讲自己的内容和观点对其他人的观点没有回应也没有质疑。这是明显的团队成员害怕冲突的表现团队成员之间没有真正的融合背后真正的问题可能是没有建立团队成员之间的信任。 争论推责式的回顾会议大家抢着发言但是气氛紧张经常有不礼貌地打断他人讲话的情况出现大家都极力避免责任被认定到自己的头上往往需要老板在最终的时候决策。定责式的回顾会议是我们需要极力避免的这个不是我们回顾会议的目标定责的行动往往会导致大家关闭沟通的门导致真正的问题被掩盖。 发散讨论式的回顾会议回顾中抛出的问题很多讨论的的过程中往往还会从一个问题跳跃到其他问题上导致会议中涉及的论点不断发散最终往往由于问题过多没有时间也没办法形成能落地的结论。没有结论的会议也就没有办法拿到最终的会议价值。 聚焦共创式的回顾会议明确回顾的目标是通过团队共创的方式发现团队持续进化的机会鼓励大家用坦诚、合作、成长的心态挖掘团队改进的机会并通过区分优先级以在最有价值的机会点上切实落地改进的行动。这个层次才是我们理想的情况是我们追求的目标。 二、可参考的回顾会议流程 我们操作的回顾会议基本流程是参考了《Agile Retrospectives》这本书中所划分的会议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 结束会议 结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议可以帮助我们提高下次回顾会议的组织能力。 但我最喜欢的结束会议的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人并附上理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法。写好纸片之后我会请大家当众宣读一下卡片内容并亲手交给自己感谢的人纸片格式如下 三、提供几个需要注意的地 一般情况不建议团队的经理参加回顾会议。这有悖于准备环节中提到的设立一个安全的环境大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场那就是团队已经积累了很多非常严重的问题但是经理可能都不大了解情况大家都期盼的经理在场能听到并推动解决这些问题。 会议产生的改进计划怎么有效地跟踪一般我们建议把这些action之间放到团队下个迭代的工作列表中和普通开发工作一样对待跟踪只有这样才能有效地使得改进落地。 前后回顾会议产出相同或类似的改进计划。这说明老问题一直没有解决有的时候会发现每次改进计划都完成了但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况这些不像团队自己的流程那样能立竿见影面对这样的问题团队最好能计划一些长期的周期跨迭代的改进计划下次回顾会议可以监控进展而不是提重复的问题。 如果需要别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。 原文链接 转载于:https://my.oschina.net/u/1464083/blog/2980754
