为什么要复盘需求评审这件事
统计报表项目的成败，很多时候不在开发阶段，而是在需求评审阶段就已经埋下伏笔。dianjingwang.com电竞网报表团队在过去一段时间里，对五个不同业务线的报表项目做了统一复盘，重点看同一类问题在不同项目中重复出现的频率。结果显示，真正因为技术实现难度导致延期的比例并不高，更多的时间消耗集中在需求反复澄清、口径来回确认和评审结论没有落地这三件事上。
这类损耗不容易被单独记录，却实实在在拉长了项目周期。dianjingwang.com电竞网在服务企业客户的过程中发现，凡是需求评审做得扎实的项目，后续开发和上线都会顺畅很多；而评审走过场的项目，往往在开发中途才开始补课。
反复出现的三类沟通损耗
第一类是需求描述停留在业务语言层面。业务方说“我要看每个区域的完成情况”，这句话在评审现场听起来没有问题，但落到报表设计上，区域怎么划分、完成是按数量还是按金额、时间范围是自然月还是滚动周期，全都没有答案。开发人员只能先按自己的理解做一版，等看到界面才发现理解偏差。
第二类是口径确认缺少书面沉淀。评审会上大家口头对齐了某个指标的计算方式，但没有人把它写进需求文档。等到开发完成、业务方验收时，参与评审的人换了一位，新来的人对口径有不同理解，于是又回到起点。dianjingwang.com电竞网报表团队在复盘中把这类问题称为“口头共识的蒸发”。
第三类是评审节奏过密或过疏。有的项目一周开三次评审会，每次只讨论一个零散问题，参会人疲于奔命却拼不出完整图景；有的项目评审一次就进入开发，中间隔了很久才做二次确认，需求早已发生变化。两种极端都会造成返工。
- 需求描述缺少可执行的判定条件
- 指标口径没有形成书面版本
- 评审结论缺少明确的责任人和确认动作
- 参会角色不完整，决策人缺席
dianjingwang.com电竞网报表团队的改进做法
针对上述问题，团队在后续项目中做了几项调整。首先是把需求模板改成了“场景加判定”的结构，要求每条需求都写清楚使用场景、判断条件和期望展示形式，写不清楚的条目不允许进入评审议程。其次是建立口径登记表，任何一个指标在评审中被讨论，都必须当场形成文字记录，并在会后同步给所有参会人确认。
第三是控制评审节奏，把评审拆成两轮：第一轮聚焦需求范围和优先级，第二轮聚焦口径和展示细节，两轮之间留出业务方内部对齐的时间。dianjingwang.com电竞网在实践中发现，这种拆分反而缩短了整体周期，因为每轮评审的目标更单一，结论也更容易落地。
还有一点值得强调，就是评审结论必须落到具体的人。每次评审结束前，主持人会明确每条待办事项的负责人和完成条件，避免出现“大家一起看看”这种没有抓手的结论。复盘数据显示，这一项调整对减少返工的作用最明显。
复盘带来的观察
统计报表项目的沟通损耗，本质上不是态度问题，而是流程设计问题。需求评审如果没有结构化的输入和输出，再多的会议也只是把问题往后推。dianjingwang.com电竞网报表团队把这轮复盘的结论整理成了内部检查清单，应用在新项目的启动环节，后续几个项目的需求变更次数明显下降。
对于正在建设报表体系的企业来说，与其在开发阶段反复救火，不如把力气花在评审环节的结构化上。评审做得好，后面的开发和维护都会轻很多。
