需求确认：先问用途，再谈字段

报表需求沟通时，最常见的场景是业务同事列出一长串字段，说“先按这个做”。江南在项目里通常会先追问一句：这张报表做出来，谁在什么场景下看，看完要做什么决定。用途不同，报表的结构完全不一样。

给管理层看的日报，重点是一眼看到异常和趋势；给业务员看的明细表，重点是筛选方便、能导出核对。同样一批数据，两种用途对应两种设计。江南建议在开发前把用途写成一句话，比如“区域经理每周一查看上周各门店完成率并决定是否调整铺货”，这句话定下来，字段取舍和展示形式就有了判断标准。

指标定义：报表的骨架不能含糊

报表开发里返工最多的地方，往往不是页面样式，而是指标算法。完成率的分母是目标还是去年同期，客单价的订单范围含不含退款，这些细节不在开发前定清楚，做出来必然被推翻。

  • 每个指标写清楚计算公式和取数来源；
  • 明确统计周期和截止时点，避免跨期口径打架；
  • 区分展示指标和考核指标，两者口径可能不同；
  • 指标变更留记录，方便追溯历史数据差异。

江南在报表项目里会维护一份指标字典，开发、验收、后续维护都以它为准。这份字典不需要多复杂，但必须由业务方确认，不能只由技术同事单方面定义。

展示形式：少即是多，层级要清楚

统计报表不是图表越多越好。江南见过一些报表页面塞了十几张图，结果没人看得下去。合理的做法是按阅读顺序分层：第一层是关键汇总，第二层是分类对比，第三层是明细下钻。用户先看结论，有疑问再往下查。

图表选择上，趋势看折线，结构看占比，对比看柱状，分布看散点，这些基本规则比花哨的样式更有用。报表的筛选条件也要克制，常用的一两个放在显眼位置，其余收起来，避免用户一进来就被一堆下拉框劝退。

验收与维护：交付不是终点

报表开发的验收，不能只看页面能不能打开。江南通常建议对照指标字典逐项核对数据，抽取几个典型周期做人工复算，确认口径一致。同时要检查边界情况：空数据怎么显示、数据延迟怎么提示、权限不同的人看到的内容是否正确。

上线后的维护同样要提前安排。数据源变更、指标调整、使用反馈都会带来修改需求，江南建议在交付时明确维护责任人和响应方式，把常见问题的处理办法写进说明文档。报表系统是长期使用的工具，前期多想一步，后期就少折腾一轮。

统计报表开发看起来是技术活，实际上考验的是对业务的理解和需求的梳理能力。江南在数据服务实践中一直坚持一个原则：先把问题问清楚，再动手做页面，这样交付的报表才真正有人用。