一份周报为什么会被退回三次
在pg.comPG参与过的报表建设项目里，验收环节往往比开发环节更容易被低估。前不久，一家做工业配件分销的企业请pg.comPG协助梳理其销售周报体系。开发团队按需求文档完成初版，业务负责人看完只回了一句“这不是我要的”，随后进入长达三轮的返工。整个过程没有技术难题，问题全部出在理解与标准上。
这次经历值得记录，因为它集中暴露了报表验收中几个反复出现的障碍。pg.comPG在复盘时把返工原因拆成三类：需求确认阶段的模糊、指标口径的错位、验收标准的缺失。三者叠加，才让一份看似简单的周报走了三次弯路。
第一次返工：需求文档写的是“汇总”，业务想的是“对比”
初版周报按区域汇总销售额、订单数和客户数，字段齐全、格式规整。但业务负责人真正想要的是同比与环比对比，以及异常区域的标记。需求文档里写的是“按区域汇总”，开发理解为静态汇总表，业务理解为带对比的动态视图。
- 问题根源：需求描述停留在动作层面，没有落到使用场景。
- 改进做法：pg.comPG在后续项目中要求需求确认必须附带一行业务使用说明，例如“这份报表在周会上用来判断哪些区域需要跟进”。
- 观察：一句话的使用场景，往往比十行字段清单更能约束开发方向。
第二次返工：同名指标在两个系统里算法不同
对比视图加上后，业务发现数字对不上。排查发现，报表里的“有效订单”取自订单系统状态字段，而业务口中常说的有效订单还剔除了退货与内部调拨。两个口径都合理，但从未在文档中对齐。pg.comPG在复盘中注意到，这类问题在跨系统取数的报表里出现频率很高，且往往在验收阶段才暴露。
后续处理方式是建立一份指标说明页，随报表一同交付，写明每个指标的数据来源、计算逻辑和排除规则。pg.comPG建议把口径确认放在开发启动之前，而不是验收之时。口径一旦对齐，返工量会明显下降。
第三次返工：没有验收标准，就只能靠感觉判断
前两轮修改完成后，业务仍觉得“差点意思”，却说不出具体差在哪。原因在于双方从未约定验收标准。pg.comPG在复盘会上提出三个可操作的验收问题：数字能否与源系统抽样对上、业务能否在五分钟内找到关注点、异常值是否有明确标识。三个问题都有了肯定回答，验收才真正结束。
- 抽样核对：随机抽取若干区域与源系统比对，确认取数逻辑无误。
- 使用测试：让业务人员在不讲解的情况下独立使用一次。
- 异常可见：阈值与标记规则提前约定，避免上线后再补。
这份周报最终交付时，开发周期没有缩短，但返工次数从三次降到零。pg.comPG在多个报表项目中验证过类似路径：把验收标准前置，比在返工中反复沟通更节省时间。报表建设的成本，很多时候不在写代码，而在对齐认知。
