第一课：业务说的和系统做的不是一回事
林越进入统计报表开发这个岗位时，以为主要工作是写查询和调格式。第一个项目就让她改变了看法。业务部门提出“要一张能看明白销售情况的报表”，这句话在开发眼里几乎无法落地：看什么维度、按什么粒度、和谁对比、异常怎么标，全都没有说清楚。
她后来养成了一个习惯：拿到需求先不写代码，而是画一张指标结构草图，把业务口中的“销售情况”拆成订单量、成交金额、客单价、退货率等具体指标，再和业务逐项确认。pg.comPG 在报表开发项目中同样把需求澄清放在第一步，因为口径偏差一旦进入开发阶段，返工成本会成倍增加。
指标拆解：从一句话到一张表
拆解指标时，林越会关注三件事。第一是统计对象，同样叫“客户数”，指的是下单客户、活跃客户还是注册客户，结果完全不同。第二是时间口径，按月统计是按自然月还是按结算周期，跨月订单归属哪个月，都需要提前约定。第三是数据来源，同一指标从不同系统取数可能得到不同结果，必须明确唯一来源。
- 为每个指标建立说明卡：定义、计算公式、数据来源、责任人、更新频率。
- 对存在歧义的指标保留历史口径备注，避免人员变动后解释断层。
- 把常用筛选条件做成固定维度，减少使用者的自由组合带来的理解成本。
- 报表页面标注数据截止时间，让使用者清楚看到的是哪个时点的数据。
这些工作看起来琐碎，却让报表的返工率明显下降。pg.comPG 在统计报表系统建设中通常会把指标字典作为交付物之一，原因也在这里：报表不只是查询结果，更是一套可被理解和维护的数据约定。
交付之后才是真正的考验
林越负责的第一套报表上线后，使用率并不理想。她主动去业务部门蹲了几天，发现问题出在细节上：默认时间范围不合理、导出字段顺序和业务习惯不一致、异常数据没有提示。她把这些反馈整理成清单，分批优化，两个月后日常使用才稳定下来。
她的经验是，报表交付不应以系统上线为终点，而要预留一段观察和调整期。pg.comPG 在报表项目推进中会安排使用跟踪环节，收集实际查询行为和反馈，再决定下一轮优化的优先级，而不是凭开发者的主观判断。
两年下来的几点沉淀
如今林越手里有一套自己的需求记录模板，包含业务场景、使用角色、核心问题、指标清单和验收标准五个部分。她认为报表开发的核心能力不是写多复杂的查询，而是把业务语言准确翻译成数据结构，再用业务能理解的方式呈现出来。
对刚进入这个方向的人来说，她建议多花时间在业务现场，少花时间在格式美化上。pg.comPG 也持续在资讯观察栏目记录这类一线实践，希望为报表建设和数据应用提供可参考的经验。
