项目情况：
需求文档：_

项目复盘主要在于从已经实战的项目中回顾，推荐使用 GRAI 复盘法：

1.回顾目标 Goal

回想当时的目标或预期结果是什么，可以是业务上目标、技术上的目标，关键时间节点

• 项目目标
• 期望结果&里程碑

  2.评估结果 Result

  | 实际结果 | 预期结果 | 与预期相比 | | —- | —- | —- | | | | 超出预期 | | | | 超出预期 | | | | 未达预期 | | | | 未达预期 |

3.分析原因 Analysis

3.1项目过程

整个项目的历程

说明哪里，哪个环节有问题

例如按照上面的有以下问题：
2022-09-08 前端研发延期 1 天
2022-09-13 前后端联调延期 2 天
2022-09-19 测试缺陷较多延期 3 天
2022-09-22 测试缺陷较多延期 5 天

:::danger 原因分析建议的格式

1.xxx 不足，比如： 哪一个 BUG 是典型的因为此问题导致

举例

1. 接口定义的评审薄弱，导致后续联调问题多，比如：数据脱敏、加密字段的定义等； :::

3.2 原因 1 分析

3.3 原因 2 分析 【假如是 BUG 问题】

放所有 BUG 的统计表数据

放总体的统计结果概述： BUG 归属人分布、BUG 原因分布（数量，占比） ，有图表更好

BUG 归属人分布

BUG 原因分布

问题出现原因

按照一定的分类不同的视角分析 如：项目过程阶段， 每个人的总结分析 、 TL 的视角

阶段1 ：技术方案阶段

:::danger

1. 对依赖资源了解不充分，比如：短信日发送短信限额，短链的批量限制，文件中台的大小限制等；
2. 对需求细节未考虑周全，比如 证件类型与姓名新规则的校验， 附件下载文件夹命名同名情况未考虑到等；
3. 接口定义的评审薄弱，导致后续联调问题多，比如：数据脱敏、加密字段的定义等； :::

阶段2:研发阶段

:::danger

1. 自测不充分：边界值测试、单元测试，比如：E端展示应为商户配置中的E端名称等；
2. 校验职责划分不清晰，比如：修改电话号码时未校验重复等；
3. 对提示文案不够重视，比如：错误提示信息未按原型定义、空对象展示 null 等； :::

阶段3 ：…

3.4 原因 x 分析

4.总结规律 Insight

改进措施

具体、 可落地、可被监督