软件项目复盘怎么做？分享一套简单有效的复盘框架
很多团队在复盘时只靠回忆，容易遗漏关键信息。为了让复盘更有价值，通常需要提前准备哪些资料和数据？
复盘前需要准备的核心材料
建议提前整理项目计划、需求文档、迭代记录、缺陷统计、上线记录、工时与资源投入、关键会议纪要，以及项目目标达成情况。若有用户反馈、线上监控数据、报警记录，也应一并收集。材料越完整，复盘越容易定位问题根因，也更方便把经验沉淀成可执行的改进措施。
有些项目看起来按时交付了，但过程里可能埋了很多隐患。复盘时应该从哪些维度去看，才能更准确地识别亮点和问题？
从目标、过程和结果三个层面看复盘
可以围绕项目目标、执行过程和交付结果来分析。目标层面看是否真正解决了业务问题；过程层面看需求是否清晰、协作是否顺畅、风险是否被及时识别；结果层面看质量、进度、成本、用户反馈是否达到预期。对做得好的部分，要提炼可复制的方法；对出问题的部分，要区分是需求、沟通、技术还是管理原因，避免只停留在现象描述。
很多复盘报告都会写成宽泛的描述，真正落地时却不知道该改什么。有没有更实用的方法，帮助团队找到问题背后的根因？
用问题追问法定位根因
可以围绕问题不断追问：为什么会发生、是谁在什么环节做了什么、当时缺少什么信息或机制、如果重来一次哪里能提前拦截。也可以把问题拆成需求、计划、设计、开发、测试、发布、协作几个环节逐一排查。这样能把‘沟通不好’细化成‘需求确认缺少统一模板’、‘变更未同步到测试’等可执行问题，便于后续改进。
复盘如果没有后续跟进，很容易变成一次性讨论。怎样把复盘结果转化成实际改进动作，并持续检查效果？
把复盘结论转成可跟踪的行动项
建议把复盘结论整理成明确的行动项，包括要改什么、由谁负责、完成时间、验收标准和影响范围。行动项数量不宜太多，优先处理对质量和交付影响最大的事项。复盘后的改进行动还应纳入周会、迭代回顾或项目例会中持续检查，确认是否真的生效。这样复盘才不是记录问题，而是推动团队形成持续改进机制。