工作总结 / 创意风 / IT互联网 / 橙系 / 双色 · 配色「焦糖拿铁」 · 共 19 页
做对了什么、踩了哪些坑、下次怎么改
把问题摊开,是为了下次少犯错
年初定的三个目标,最后两个达成、一个延期。达成的说说靠什么,延期的把原因讲透,别用外部因素糊过去。先摆事实,数据从系统里拉,不靠回忆。
· 3次 需求返工
· 92% 验收通过率
条形长度按最大值等比换算,右侧为该项在合计中的份额
真正有用的是两件事:需求评审时把验收标准写死,以及每周一次十五分钟的同步会。前者省掉后期扯皮,后者让问题在还小的时候就被看见,这两条已经写进团队手册。
最大的坑是需求在开发中期还在变。表面看是客户改主意,根子是早期只对了功能清单,没对业务流程。返工三次、工期丢两周,就是这么来的。联调环境不稳定又雪上加霜。
三个目标逐条对照,达成的看超额多少,延期的看到底卡在哪个环节,不做模糊表述。
立项、评审、开发、联调、上线五个节点,每个节点标出计划与实际之间的时间差。
把踩过的坑整理成检查清单和流程卡,新项目开工前先过一遍,不重复交学费。
下次开工前先过一张检查清单:验收标准谁签字、环境谁负责、变更走什么流程、风险谁盯。四行字,能挡掉大半返工。复盘的价值不在写得漂亮,在于下次真用上。
需求和验收标准写清楚再动手。
接口约定前置,问题早暴露。
固定节奏同步进展,减少猜测。
· 「联调」占比最高,约 35%,是本页结构里的主要构成。
· 其余 4 项合计约 65%,可按占比高低分优先级投入。
先看结果与目标的差距。
关键节点按顺序排开。
不停留在表面现象。
· 「联调」最高(22),「上线」最低(6),差 16。
· 合计 63,均值 12.6,可按高低落差定优先级。
延期集中在中段联调,前期需求反复导致开发启动晚了一周多…
三次返工合计投入约一百二十人时,其中两次本可在评审阶段避免…
未通过的集中在报表口径与权限配置,验收后两周内已补齐并复测…
下一步:按既定节奏推进,持续迭代优化
复盘结论已同步至团队文档