- 2019-11-16蓓格格,你好。感谢你的回复，对我很有帮助。人很多时候就是一叶障目。
至此对应五大过程组的最佳实践已经介绍完毕，我也整理成我自己的思维导图，感谢你的分享。
虽然因为我的能力有限很多细节都没能理解透彻，但是依然不妨碍我“好听课，不求甚解”的心思，所以每一遍我都会在上班途中，下班途中。繁复多遍的聆听，每一次都会有所收获.
在IT中有一句话，没有绝对的“银弹”，但是你的最佳实践给我们很多启发。
而且我发现你每次在发布栏目的时候总是在深夜凌晨，我想每一讲的内容与讲述都是来之不易的。
现在我已经把你的专栏推荐给我的同事，她们刚好想要考PMP，走项目管理一道。
所以每次在听完你的最佳实践后，一起讨论一下其中细节也是一件怡然自得的事情。
最后，再次感谢你的最佳实践，感谢你的分享。展开作者回复: 谢谢，希望你也可以把笔记分享给更多人，授人玫瑰，手有余香！
分享是件快乐的事，我乐此不彼，哈哈 4 
2019-12-23复盘会最重要的是选中一个值得复盘的项目！
不是所有项目都适合复盘，也不是每个项目复盘都要产出什么。复盘不是目标产出导向的，我们不能假设复盘能够产出假想的问题和对策，那样就失去了复盘的意义。
在复盘师的引导下，让参与复盘过程的人慢慢进入一种心流状态，不论好与坏，只是说出来，关注在当下的感受，不加评判。
复盘是个好工具，也是很难使用好的工具，没有制度的保障，没有看到复盘的效果，让参与者参加三次以上就比较困难了。
Anyway，只有你自己用过了，才知道好不好使。 1
2019-12-20万一项目经理成了复盘会的吐槽对象，那是有多尴尬😅作者回复: 其实，觉得尴尬是因为我们放不下自己，真正开放的心态，要首先学会把那个自己放下，眼光放在整体怎么会更好。
开放的调研问卷，确实有时是会有这样的结果，大家对过程有很多意见，那么正好你给了这个渠道，以及时纠正自己的盲区。如果是大家愿意当着你的面吐槽你，实际上反而说明，这个信任度还是有的，更应该珍惜这些反馈。 1
2019-11-14改进分两种，一种是软件研发团队类似的，一种是对于每个团队特有的，对于各个团队类似的这个部分，蓓蓓老师可以分享一下么？有哪些优先级和回报比较高的改进？团队自己通过复盘找不到问题的要害或者解决方案怎么办？作者回复: 桃子你好，看到熟人，哈哈。你所说的这类特别有效的通用型改进，我肯定都会放在内容里，把实战中各个过程好的做法呈现给你的。
关于团队中复盘找不到问题的要害，复盘会是集体智慧的总结，产出肯定是跟参与的群体直接有关，解法是你需要有不同层面的复盘会，去解决不同层面的问题，比如执行团队复盘之后，反馈了规划层面的问题，那这个就应该是负责人层面去解决的了。 1 1
2020-01-02复盘会很重要的一点是定好改进的基调，达成复盘改进的共识，如果变成甩锅，团队人员之间的信任就被破坏了
2019-12-21我完成了一个项目，又做砸了一个项目。三个人的团队，我居然是项目经理。项目经理是跟项目算的。那种三个人的开发部，有两个项目经理的感觉很扯。可以负责也可以不负责。结果项目做砸了，我被迫离职。加了一个月的班。还是感触很多。正在反思和复盘呢。这是我第二次做项目经理。现在是学习课程最好的时候了。作者回复: 人生的每一段经历都有其价值，需要你自己去发现。你这情况，一定是有个大宝贝，等着你挖出来呢
- 2019-12-20复盘：奏章法，优点缺点3点法，还有其他方法不？我怕团队玩一次以后就觉得没兴趣了。
作者回复: 玩法不是最重要的，重要的是要你能带动大家玩的起来，大家觉得有动力持续做，就能想出适合的玩法。最好的玩法永远在民间，基于这些基本方法，你可以共创和微创新。
其实，各种领域的方法，都会被我们拿来用， 比如，U型理论中的3d雕塑，也是我们很常用的深度复盘方法，只是这个涉及教练技术，篇幅有限，不能一一介绍。感兴趣可以看我的博客：http://leibei1128.lofter.com/ 
2019-11-29我所在的研发小组也是scrum, retrospective 两周一次。开始总是scrum Master 和lead Dev说这不好，那不好，说领导不好，阻拦信息，说后端不好沟通，说产品经理拿不了主意，说了一堆，每次都一样。这些问题组内没办法，讨论了也没人去解决。作者回复: 这样的情况，要考虑团队和外界的接口是否畅通，不知道你的具体角色，但复盘会不是单纯的吐槽会，复盘要解决问题，复盘会参与的人员，要跟想要解决的问题相匹配，哪个层面的问题，需要引入相关人到这个层面的复盘，而不是一直吐槽不在场的人员。
2019-11-16我目前所负责的一个项目，是负责开发我们公司内部内部的研发管理系统、订单和客户管理系统以及工厂生产及品质管理系统。我每个月初会开一次当月的重点研发计划会，梳理一下上个月任务的完成情况、没有完成的原因、哪些需求变更了、以及总结一下开发过程中的技术难点并指派人抽时间组织技术分享；然后粗略过一下过当月的研发重点，安排后面2周的开发任务，然后是大家提意见及讨论。
一般到月中的时候，会发布一个小版本，发布完成之后，会对当前阶段做一个小的总结，安排后面两周的任务。因为项目组的研发人员同时兼顾着其他项目，有时公司项目优先级有变动，一般研发方向、资源和重点有改变，也会在这个计划会上提出来。
我每周一向项目发起人，也就是我们的CEO汇报一次上周完成了哪些内容，本周预计会完成哪些内容，同时也会和他讨论一些需求和方向相关的事宜。
我定期还会组织一些公司内部的关于管理系统使用相关的培训。
听了老师的课，我觉得我一直没有做过比较好的复盘。我们的功能一直是慢慢推进的，所以感知不明显。但其实现在想想，这一年也做了很多东西，是时候做一个复盘了。展开作者回复: 嗯，改变不需要很大，从小做起。
2019-11-14我要有您这样的领导就好了作者回复: 谢谢！我也有很多不足，带团队会放大自己的局限，我也在不断突破。
2019-11-14之前的项目也做过多次的复盘，在一个合作默契的团队里，大家对项目复盘的问题基本也是了熟于心，对于各种问题也基本能够避免大部分。
后来，大家分开到其他团队，发现每次复盘，大家热情也很高涨，也基本总结了大部分问题，但是到下一个项目里依旧会出现这些问题，多几次以后发现，每个人关注的问题优先度不一致，而团队也未规定必须处理那些问题，这就导致了，每次每个问题出现在不同的身上，这也基本符合了老师说复盘要有重点，而且不宜过多。
朝着同一个方向努力改进，效果要远远超过同时改进所有问题。
再说复盘，每次复盘的效果永远会在下一个项目或者迭代时提现出来，复盘带给我们的不仅仅是问题的解决，还有经验的沉淀，思路的碰撞。
多谢老师的文章，看到复盘更多的实施方式和方法，也看到复盘的重要性与重点。展开作者回复: 对的！
2019-11-14第一次在音频中听到蓓蓓老师的笑声，很开心~
我印象最深的一次“复盘”，是我做项目管理之后负责的第二个项目。项目第一次提测结束后，测试部门反馈了很多的问题，当时看到问题之后也有点不知所措。
但是又不想像以前那样“问题来了，各自拿回去修改，改完后，继续提交测试，一次、两次、三次...”
记得当时突发奇想，把项目组所有成员全部召集起来，针对这次测试结果做一次分析、总结：
1、把报告中的问题一个一个的讨论，确定哪些问题要修改，哪些问题不用修改；
2、要修改的问题，统一修改方案和最终要达成的效果；
3、问题修改完成后，项目组成员交叉验证修改结果是否达标；
之所以印象最深，是因为项目第二次测试居然通过了，要知道在之前，没有三四次，根本不可能的事。
也是从那时起，我开始思考、尝试、总结工作中的方法（我们项目组小伙伴好可怜啊，都成了小白鼠）。
现在，我常常把自己当初趟出来的“捷径”，用来“忽悠”我的几个项目负责人。但是自己趟的毕竟是“野路子”，用来培养项目负责人感觉很心虚啊，当然也促使自己学习。展开作者回复: 忽悠也是一项技能呢
3
2019-11-14我們公司的retrospective就是文中說的流於形式的甩鍋會，每兩週一次，全組絞盡腦汁編good/bad point，項目經理為了不被director罵就儘量掩蓋問題，做得好的基本都是大同小異的內容，整個會議形成的文檔空洞無物，什麼作用都沒有，還讓大家浪費半小時時間憋在會議室裡作者回复: 其实，再好的形式，也全在于如何运用。重要的是，要回到复盘的初心。
不知道你在项目中的角色，你可以试着，每次改变那么一点点，只要有正向变化，团队就会感知到的- 2019-11-14老师你好，我们研发团队采用的是敏捷Scrum研发，主要环节包括每日站会、计划会议、评审会议以及回顾会议。我们的回顾会议跟老师讲的复盘会议流程很相似。我们是每两周举行一次，每次大约为1小时，研发团队人数为9人。
我的现状是每次举行这种复盘会议的时候，大家情绪不高、参与度低、经常提一些不痛不痒的问题，最后形成的改进项基本上都是3条，真正能落实改进的项就寥寥无几了，大家都是为了复盘而复盘，更谈不上团队和个人能力的持续提升了。
请问老师，针对以上现状，该如何破？谢谢作者回复: 你好，文中都有讲，例行公事的复盘会，改进措施又落不下去，大家当然没热情。与其这样流于形式，不如减少次数，把复盘会真正开出效果。
流程不是最重要的，复盘会前基调的设定和充足准备，会后改进措施的落地，才是最重要的！ 
2019-11-14复盘是为了发现问题，解决问题，而不是推卸责任，解决问题不要一次贪多，挑出最主要的一个确实解决掉，不再发生，复盘的目的就达到了，不知道我理解对了吗？作者回复: 正解！
2019-11-14原来项目管理还有这么多小魔术，如此有趣，在原本平淡无奇的项目开发中还能带来一点乐趣。作者回复: 请叫我魔法师🧙♀️，哈哈