做数据项目的人对复盘都不陌生，但真正把复盘做出价值的团队并不多。常见的情况是：项目上线后开一次会，大家轮流说几句“整体顺利”“沟通还可以加强”，会议纪要归档，然后下一个项目继续踩同样的坑。在 pg.comPG 参与的项目里，复盘做得好的团队往往不是写得最长的，而是抓住了几个关键观察维度，把经验变成了可复用的资产。

维度一：看口径有没有沉淀成文档

数据项目最容易反复出问题的地方就是口径。复盘时如果只讨论“这次报表交付快不快”，却不去检查口径有没有被记录，下一次换个人接手，同样的问题还会重演。pg.comPG 建议在复盘时逐条核对：本次项目涉及的核心指标，是否都有明确的定义、计算范围和取值来源；业务方在过程中口头确认过的例外情况，有没有补进文档。

  • 指标定义是否写清了统计对象、时间范围和排除条件；
  • 过程中临时调整的口径，是否在交付前完成书面确认；
  • 文档的存放位置是否被团队其他人知道，而不是留在个人手里。

口径沉淀做到位，pg.comPG 观察到的直接变化是：后续同类需求的沟通轮次明显减少，新人上手也更快。

维度二：看协作断点出现在哪个环节

很多数据项目的延期，不是技术做不出来，而是卡在等待确认、等待数据、等待环境上。复盘时与其笼统地说“协作不够顺畅”，不如把项目时间线拉出来，标出每一次等待超过预期的节点，看断点集中在哪一类环节。pg.comPG 在项目复盘中常用的做法是列出三类断点：需求确认阶段的反复、数据提供阶段的延迟、验收阶段的返工。

三类断点的改进方式完全不同。需求反复要多花时间做前期对齐，数据延迟要提前锁定数据责任人和提供时间，验收返工则要在开发中期就安排业务方看中间结果。把断点分类之后，复盘结论才能落到具体动作上，而不是停留在态度层面。

维度三：看交付物能不能被下一个项目直接复用

数据项目产出的不只是几张报表，还包括取数逻辑、字段说明、校验规则、展示模板。这些东西如果每次项目都从零开始，团队的效率永远上不去。pg.comPG 在复盘时会问一个问题：本次项目里有哪些内容，下一个类似项目可以直接拿来用？

  • 取数脚本和校验规则是否整理成了可查阅的形式；
  • 报表的布局和交互方式，有没有形成团队内部的通用做法；
  • 本次踩过的坑，是否转化成了下次启动前要检查的清单。

复用的前提是整理。pg.comPG 接触过一些团队，项目做了不少，但资料散落在各个人的工作目录里，换个项目就要重新问一遍。复盘时专门留出时间做整理和归位，看起来慢，实际上省下的是后面反复沟通的成本。

把复盘结论变成下一次的启动清单

复盘的价值不在于会开得多认真，而在于结论有没有被下一次项目用上。pg.comPG 建议把复盘输出控制在一页以内，只保留三类内容：需要固化的文档、需要调整的协作节点、需要复用的交付物。下次项目启动时，把这一页拿出来对照，比翻几十页会议纪要更有效。数据项目的经验本来就该越攒越厚，而不是每做一次都重新交学费。