一个管理系统做完，报表往往是最晚定稿、改动最多的部分。业务说要做一张月度统计表，开发做出来，业务说不是这个意思。来回几轮，双方都累。
问题多半出在需求描述的颗粒度上。报表看着简单，实际包含大量隐含约定，不写清楚，每个人的理解都不一样。
一、每张报表要说清四件事
第一件是口径。数字怎么算出来的，这是最容易出分歧的地方。比如本月新增客户数，是按建档时间算还是按首次成交时间算，退单的要不算，重复建档的算不算。这些都要明确写下来。
第二件是维度。就是按什么分组，按部门、按人员、按产品、按地区还是按月份。多个维度还要说清能不能交叉，比如要一张部门乘月份的表格。
第三件是时间范围。默认展示哪一段，能不能自选，跨月跨年怎么处理。年末年初的报表最容易出问题，因为很多业务在这个时点上有特殊处理。
第四件是展现方式。是列表还是图形，要不要导出，导出成什么格式，需不需要打印。要打印的报表还要额外约定纸张规格和分页方式。
二、样例数据比文字描述管用
提报表需求最有效的方式，是把期望的结果做出来给人看。用 Excel 手工排一张表，填几行示例数据，画出列头和分组方式，标出总计行在哪。这张手工表拿给开发看，理解偏差会小很多。
样例数据还有个隐藏作用，能暴露逻辑漏洞。手工做样例的时候，往往会发现某个字段在不同情况下含义不一样，或者某些行的数字怎么算都对不上。这些问题在写文字需求时想象不到，一动手就冒出来了。
样例最好是真实业务的抽样，脱敏之后使用。用真实数据做的样例，能覆盖到边界情况，用编造的数据做的样例，往往过于理想化。
三、固定报表和自定义报表要分开
有些报表是每月每季都要用的，格式固定，这类适合做成固定报表，由开发方实现，追求准确和稳定。有些报表是临时想看的，比如某个领导突然想看看某个角度，这类如果每张都找开发做，成本会失控。
做法是配一套自定义查询能力。让业务人员自己选字段、选条件、选分组方式，系统实时生成结果。自定义查询不追求格式精美，能看能导出就够，它的价值在于把临时需求从开发流程里摘出去。
分界线的判断标准可以这样定。一张报表如果连续三个月每个月都要看，就固化成标准报表。偶尔看一次或者只看一次，走自定义查询。
四、报表上线后怎么减少返工
有个做法效果不错，报表开发完成后，先不急着上线，而是用历史数据跑一个月的结果出来，让业务人员拿现有手工做的报表核对。对不上的地方，正好就是要澄清的口径问题。
核对通过之后再上线，能避免上线后业务发现数字不对，进而怀疑整个系统的数据准确性。这种信任一旦丢了，后面要花很大力气才能找回来。
另外建议在报表页面上标注口径说明。鼠标悬停在列头上能看到这个数字是怎么算的、取的是哪张表、什么时间点的数据。有了这个，业务人员自己就能回答大部分疑问，不用每次都问开发。