项目管理实战20讲
雷蓓蓓
网易杭研项目管理部总监,《网易一千零一夜》核心作者
立即订阅
3862 人已学习
课程目录
已更新 21 讲 / 共 20 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 为什么说项目管理是每个人的底层能力?
免费
常识篇 (3讲)
01 | 角色转换:程序员做项目管理的三大误区
02 | 十大领域五大过程组(上):程序员必须要了解的项目管理常识
03 | 十大领域五大过程组(下):程序员必须要了解的项目管理常识
硬技能篇 (12讲)
04 | 启动:识别项目中的四类干系人
05 | 规划:排除计划中的“延期地雷”
06 | 执行:打造品质,要从头开始“闭环”
07 | 监控:进展“巧”汇报,学会用数据说话
08 | 收尾:项目复盘,小团队也要持续改进
09 | 需求变更:化解程序员的“头号噩梦”
10 | 风险管理:如何系统化应对风险?
11 | 质量管理:一次把事情做对!
12 | 高效会议:项目中要开好哪些会?
13 | 故事案例(上):新手上路,如何引入变化?
14 | 故事案例(下):小步快跑,小而美的敏捷
15 | 工具方法串讲:手把手教你高效管理
免费
软实力篇 (4讲)
16 | 向上沟通:你必须要注意的三个误区
17 | 跨部门沟通:怎么让不归你管的人积极配合你?
18 | 向下沟通(上):无权无势,他们不听你的怎么办?
19 | 向下沟通(下):无权无势,他们不听你的怎么办?
特别放送 (1讲)
特别加餐 :“学习”到“实战”的距离,到底有多远?
项目管理实战20讲
登录|注册

08 | 收尾:项目复盘,小团队也要持续改进

雷蓓蓓 2019-11-14
你好,我是雷蓓蓓。今天我们来聊一聊复盘。
复盘原本是围棋术语,是指每次博弈结束之后,双方棋手把刚才的对局复演一遍,分析对局当中得失的关键,是提升自己棋力的好方法。其实,复盘是对思维的训练。通过复盘,当类似的局面再次出现在你面前的时候,你就能够快速地预测接下来的动态和走向,并且更好地应对。
而项目复盘会,可以说是项目团队有意识地向过去的行为经验学习的过程。在项目或里程碑完结之后,项目经理会组织召集项目成员,一起回顾一下,在项目的整个历程中,团队做对了哪些事,做错了哪些事,再来一次,如何做得更好,借此把项目行进过程中产生的集体智慧沉淀下来。
但是,现实情况经常是,项目一个接一个地做,忙上线、忙变更、忙返工,哪有时间坐下来复盘?又有多少复盘会,是为了复盘而复盘,逐渐地流于形式,成为了可有可无的摆设?除此之外,还有很多复盘会,成为了追责者的工具,除了锻炼出花样百出的各种甩锅技能之外,留下的只有“一地鸡毛”。
由此可见,要想做好项目复盘,并不是一件容易的事情。今天,我就带你来看一看,如何做好项目复盘,以及如何通过复盘去培养团队的持续改进能力。

复盘会的基调设定

我们都知道复盘很重要,但实际上,在复盘会之前,想清楚我们复盘的目的,设定好复盘的基调,其实更为重要
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《项目管理实战20讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • maks
    蓓格格,你好。感谢你的回复,对我很有帮助。人很多时候就是一叶障目。
    至此对应五大过程组的最佳实践已经介绍完毕,我也整理成我自己的思维导图,感谢你的分享。
    虽然因为我的能力有限很多细节都没能理解透彻,但是依然不妨碍我“好听课,不求甚解”的心思,所以每一遍我都会在上班途中,下班途中。繁复多遍的聆听,每一次都会有所收获.
    在IT中有一句话,没有绝对的“银弹”,但是你的最佳实践给我们很多启发。
    而且我发现你每次在发布栏目的时候总是在深夜凌晨,我想每一讲的内容与讲述都是来之不易的。
    现在我已经把你的专栏推荐给我的同事,她们刚好想要考PMP,走项目管理一道。
    所以每次在听完你的最佳实践后,一起讨论一下其中细节也是一件怡然自得的事情。
    最后,再次感谢你的最佳实践,感谢你的分享。

    作者回复: 谢谢,希望你也可以把笔记分享给更多人,授人玫瑰,手有余香!

    分享是件快乐的事,我乐此不彼,哈哈

    2019-11-16
    1
  • 桃子-夏勇杰
    改进分两种,一种是软件研发团队类似的,一种是对于每个团队特有的,对于各个团队类似的这个部分,蓓蓓老师可以分享一下么?有哪些优先级和回报比较高的改进?团队自己通过复盘找不到问题的要害或者解决方案怎么办?

    作者回复: 桃子你好,看到熟人,哈哈。你所说的这类特别有效的通用型改进,我肯定都会放在内容里,把实战中各个过程好的做法呈现给你的。

    关于团队中复盘找不到问题的要害,复盘会是集体智慧的总结,产出肯定是跟参与的群体直接有关,解法是你需要有不同层面的复盘会,去解决不同层面的问题,比如执行团队复盘之后,反馈了规划层面的问题,那这个就应该是负责人层面去解决的了。

    2019-11-14
    1
    1
  • panqing
    我所在的研发小组也是scrum, retrospective 两周一次。开始总是scrum Master 和lead Dev说这不好,那不好,说领导不好,阻拦信息,说后端不好沟通,说产品经理拿不了主意,说了一堆,每次都一样。这些问题组内没办法,讨论了也没人去解决。

    作者回复: 这样的情况,要考虑团队和外界的接口是否畅通,不知道你的具体角色,但复盘会不是单纯的吐槽会,复盘要解决问题,复盘会参与的人员,要跟想要解决的问题相匹配,哪个层面的问题,需要引入相关人到这个层面的复盘,而不是一直吐槽不在场的人员。

    2019-11-29
  • Nine
    我目前所负责的一个项目,是负责开发我们公司内部内部的研发管理系统、订单和客户管理系统以及工厂生产及品质管理系统。我每个月初会开一次当月的重点研发计划会,梳理一下上个月任务的完成情况、没有完成的原因、哪些需求变更了、以及总结一下开发过程中的技术难点并指派人抽时间组织技术分享;然后粗略过一下过当月的研发重点,安排后面2周的开发任务,然后是大家提意见及讨论。

    一般到月中的时候,会发布一个小版本,发布完成之后,会对当前阶段做一个小的总结,安排后面两周的任务。因为项目组的研发人员同时兼顾着其他项目,有时公司项目优先级有变动,一般研发方向、资源和重点有改变,也会在这个计划会上提出来。

    我每周一向项目发起人,也就是我们的CEO汇报一次上周完成了哪些内容,本周预计会完成哪些内容,同时也会和他讨论一些需求和方向相关的事宜。

    我定期还会组织一些公司内部的关于管理系统使用相关的培训。

    听了老师的课,我觉得我一直没有做过比较好的复盘。我们的功能一直是慢慢推进的,所以感知不明显。但其实现在想想,这一年也做了很多东西,是时候做一个复盘了。

    作者回复: 嗯,改变不需要很大,从小做起。

    2019-11-16
  • 程序员人生
    我要有您这样的领导就好了

    作者回复: 谢谢!我也有很多不足,带团队会放大自己的局限,我也在不断突破。

    2019-11-14
  • 小金库so
    之前的项目也做过多次的复盘,在一个合作默契的团队里,大家对项目复盘的问题基本也是了熟于心,对于各种问题也基本能够避免大部分。

    后来,大家分开到其他团队,发现每次复盘,大家热情也很高涨,也基本总结了大部分问题,但是到下一个项目里依旧会出现这些问题,多几次以后发现,每个人关注的问题优先度不一致,而团队也未规定必须处理那些问题,这就导致了,每次每个问题出现在不同的身上,这也基本符合了老师说复盘要有重点,而且不宜过多。

    朝着同一个方向努力改进,效果要远远超过同时改进所有问题。

    再说复盘,每次复盘的效果永远会在下一个项目或者迭代时提现出来,复盘带给我们的不仅仅是问题的解决,还有经验的沉淀,思路的碰撞。

    多谢老师的文章,看到复盘更多的实施方式和方法,也看到复盘的重要性与重点。

    作者回复: 对的!

    2019-11-14
  • 穷查理
    第一次在音频中听到蓓蓓老师的笑声,很开心~

    我印象最深的一次“复盘”,是我做项目管理之后负责的第二个项目。项目第一次提测结束后,测试部门反馈了很多的问题,当时看到问题之后也有点不知所措。

    但是又不想像以前那样“问题来了,各自拿回去修改,改完后,继续提交测试,一次、两次、三次...”

    记得当时突发奇想,把项目组所有成员全部召集起来,针对这次测试结果做一次分析、总结:
    1、把报告中的问题一个一个的讨论,确定哪些问题要修改,哪些问题不用修改;
    2、要修改的问题,统一修改方案和最终要达成的效果;
    3、问题修改完成后,项目组成员交叉验证修改结果是否达标;

    之所以印象最深,是因为项目第二次测试居然通过了,要知道在之前,没有三四次,根本不可能的事。

    也是从那时起,我开始思考、尝试、总结工作中的方法(我们项目组小伙伴好可怜啊,都成了小白鼠)。
    现在,我常常把自己当初趟出来的“捷径”,用来“忽悠”我的几个项目负责人。但是自己趟的毕竟是“野路子”,用来培养项目负责人感觉很心虚啊,当然也促使自己学习。

    作者回复: 忽悠也是一项技能呢

    2019-11-14
    3
  • 海罗沃德
    我們公司的retrospective就是文中說的流於形式的甩鍋會,每兩週一次,全組絞盡腦汁編good/bad point,項目經理為了不被director罵就儘量掩蓋問題,做得好的基本都是大同小異的內容,整個會議形成的文檔空洞無物,什麼作用都沒有,還讓大家浪費半小時時間憋在會議室裡

    作者回复: 其实,再好的形式,也全在于如何运用。重要的是,要回到复盘的初心。

    不知道你在项目中的角色,你可以试着,每次改变那么一点点,只要有正向变化,团队就会感知到的

    2019-11-14
  • zw_learn_2
    老师你好,我们研发团队采用的是敏捷Scrum研发,主要环节包括每日站会、计划会议、评审会议以及回顾会议。我们的回顾会议跟老师讲的复盘会议流程很相似。我们是每两周举行一次,每次大约为1小时,研发团队人数为9人。
    我的现状是每次举行这种复盘会议的时候,大家情绪不高、参与度低、经常提一些不痛不痒的问题,最后形成的改进项基本上都是3条,真正能落实改进的项就寥寥无几了,大家都是为了复盘而复盘,更谈不上团队和个人能力的持续提升了。
    请问老师,针对以上现状,该如何破?谢谢

    作者回复: 你好,文中都有讲,例行公事的复盘会,改进措施又落不下去,大家当然没热情。与其这样流于形式,不如减少次数,把复盘会真正开出效果。

    流程不是最重要的,复盘会前基调的设定和充足准备,会后改进措施的落地,才是最重要的!

    2019-11-14
  • Cy23
    复盘是为了发现问题,解决问题,而不是推卸责任,解决问题不要一次贪多,挑出最主要的一个确实解决掉,不再发生,复盘的目的就达到了,不知道我理解对了吗?

    作者回复: 正解!

    2019-11-14
  • AllenGFLiu
    原来项目管理还有这么多小魔术,如此有趣,在原本平淡无奇的项目开发中还能带来一点乐趣。

    作者回复: 请叫我魔法师🧙‍♀️,哈哈

    2019-11-14
收起评论
11
返回
顶部