数字化项目复盘时，我会优先问的不是“做完了吗”，而是“结构有没有留下来”

很多数字化项目一结束，团队就会立即进入下一个阶段。需求交付了、验收完成了、会上讲过了，看上去项目已经“闭环”。

但真正重要的问题是：这个项目有没有留下结构？

交付物不等于资产

页面、系统、方案文档当然是交付物，但它们不一定自动变成组织资产。真正能被下一次项目复用的，通常是以下几种东西：

• 被验证过的流程模板
• 被清洗过的规则结构
• 被证明有效的协同机制
• 被整理清楚的失败经验

如果这些东西没有沉淀下来，项目价值就很容易随团队切换而流失。

我常用的复盘框架

在项目结束后，我会快速整理四个问题：

1. 这个项目真正解决了什么

不是 PPT 上写的目标，而是实际被改变的那部分流程或体验。

2. 哪些结构值得保留

可能是表单模型、材料清单、角色分工、会议节奏，也可能是一个小小的协作模板。

3. 哪些代价是隐性的

例如沟通损耗、跨部门对齐成本、规则解释不一致。这些问题往往不会出现在最终成果里，但会反复影响下一次项目。

4. 下一次如果重来，先改什么

这个问题能迫使人从“结果复述”进入“方法更新”。

为什么我很看重复盘文档

因为复盘文档不是为了纪念过去，而是为了降低未来的重建成本。

一个项目如果没有被复盘，下一个项目很可能要重新犯同样的错；而一个被认真复盘过的项目，即使结果不完美，也可能成为组织非常重要的学习资产。

所以我越来越愿意把复盘看作项目最后一轮真正的建设。