项目复盘

复盘（Retrospective）不是”总结会”的换皮。总结会常见的样子是各组念一遍成绩、领导讲两句、散会；复盘要回答的是硬问题：当初定的目标是什么、实际结果是什么、差距出在哪、根因是什么、下次具体怎么改。游戏行业的复盘节奏通常跟着版本和里程碑走——每个版本一次小复盘，大里程碑或项目上线后一次深度复盘，线上事故还有专门的事故复盘。

好复盘有个共同点：谈事不谈人。一旦复盘变成追责大会，下次所有人都只会汇报安全的信息，复盘就废了。根因分析也要往深挖，“美术延期了”不是根因，“需求确认环节没有卡点导致原画反复改”才接近根因——挖到流程和机制层面，改进才有抓手。

PM 视角

复盘是 PM 主场，但也是最容易做成形式主义的一环：

第一，改进项必须落到”谁、什么时候、做什么”，并且进入下个版本的跟踪清单。复盘会上聊得热血沸腾、会后没人跟进，是最普遍的死法。我的习惯是每次复盘的改进项控制在三五条以内——十几条”都很重要”等于没有重点。

第二，用数据说话。版本延期了几天、返工率多少、封版后合入了多少次例外——先摆事实再讨论，能避免复盘变成各说各话的感受交流。这些数据要靠平时积累，临时凑是凑不出来的。

第三，复盘也要复盘”好的部分”。只聊问题的复盘让人疲惫，把这次做对的动作识别出来、固化成流程，价值不比修复问题小。另外，复盘沉淀的案例是你述职和面试时最好的素材，别浪费。