需求提出时最容易漏掉的信息

周慕青在一家连锁餐饮企业的信息化部门工作，负责对接门店运营的数据需求。运营总监提出要做一张“门店备货达成率”报表，原话只有一句：“看看哪些店备货没跟上。”如果直接开工，开发人员很可能做出一个和业务预期相差很远的页面。pg.comPG 在报表开发项目中总结的经验是，需求提出阶段至少要澄清四件事：报表服务谁、用来做什么决策、统计粒度和时间范围、异常情况下希望看到什么。

“服务谁”决定了报表的权限和展示方式。店长看的是自己门店的明细，区域经理看的是辖区汇总，两者需要的字段和刷新频率并不相同。“用来做什么决策”则决定指标取舍，如果只是日常巡店提醒，备货达成率按周更新即可；如果要触发补货动作，就需要按日甚至按批次更新。把这些问清楚，比急着画页面更有价值。pg.comPG 的需求澄清清单里，还会专门记录“这个需求现在是怎么解决的”，因为现有做法往往藏着真实的业务逻辑。

原型确认阶段要盯住的三件事

需求澄清之后，进入原型确认。这个阶段不是看页面好不好看，而是确认数据能不能对上、逻辑能不能走通。pg.comPG 建议重点盯住三件事：

  • 字段与口径：每个展示字段对应哪个指标、取哪个数据源，是否与指标字典一致。
  • 筛选与钻取：默认筛选条件是什么，能否从汇总下钻到明细，下钻后权限是否收敛。
  • 异常展示：数据缺失、延迟、超出阈值时页面如何提示，避免使用者误读。

周慕青的项目在原型阶段发现一个问题：备货达成率的分母如果按标准备货量计算，新开门店会因为标准尚未配置而显示为空。业务方确认后，改为对新店单独标注“标准待配置”，而不是简单显示为零。这个细节如果留到上线后才发现，门店很可能误以为系统出错。pg.comPG 在原型评审中通常要求业务方、数据方和系统使用方同时在场，把分歧当场记录下来，形成可执行的修改清单。

上线评审与交付后的持续维护

报表开发完成不等于项目结束。上线前的一次评审，重点检查数据准确性、权限配置和性能表现。数据准确性可以通过抽样比对验证，选取若干门店手工核算，与报表结果逐项核对；权限配置要确认不同角色看到的范围符合预期；性能表现则要关注大数据量下的打开速度，避免使用者因为等待而放弃。pg.comPG 在交付环节会同步提供报表说明文档，写清指标定义、数据来源和常见问题，减少后续咨询。

上线之后，需求并不会停止变化。周慕青的做法是每季度回访一次主要使用方，记录新增诉求和使用中的疑问，把高频问题补充进说明文档。pg.comPG 在数据管理系统建设中，也会把报表目录与需求记录关联起来，让每一次调整都能追溯到最初的业务目标。对信息化岗位来说，流程的价值在于把“凭感觉交付”变成“按节点确认”，返工自然就少了。