报表需求评审该问清楚哪几件事——别等上线才发现理解错了

报表开发最亏的返工，不是SQL写错了改SQL，而是理解错了推倒重来——表结构、ETL、前端配置全部白做。而理解错误几乎都能追溯到需求评审那一刻没问到位。我带过的新人里，十个有九个吃过这个亏：接到需求兴冲冲就开写，上线后业务方说“这不是我要的”。面试官问这道题，考的是你的需求分析能力——报表开发里，问对问题比写对SQL更能决定交付质量。

第一问：为什么要——需求背后的决策是什么

我在某短剧出海公司接到过一个需求：“做一张各国家每小时充值金额的实时报表。”如果直接照做，就是一个实时链路的活。但我多问了一句“这个报表你们打算怎么用”，答案是：投放同学想在新剧上线当天判断要不要追加投放预算。顺着这个目标聊下去，真正需要的是新剧上线后的分时段ROI对比（对比同类剧的历史同期曲线），而不是全量国家的充值流水——最终交付的报表和最初的描述完全不是一张，但业务方非常满意。

这一问还有一个作用：判断需求值不值得做。说不清楚决策场景的报表，上线后大概率没人看，白白增加维护负担——后面讲报表治理时你会看到，每一张“先做了再说”的报表都是未来的下线成本。

第二问：算什么——口径要抠到字

业务方嘴里的每个名词都可能有歧义，评审时要逐个抠。以“订单量”为例：

-- “订单量”至少有四个口径分歧点，评审时逐个确认：
SELECT COUNT(*) FROM dwd_trade_order_di
WHERE dt = '${bizdate}'
  AND order_status = ?    -- 1. 含不含未支付？含不含已取消/已退款？
  AND order_type   = ?    -- 2. 含不含0元单、测试单、补偿单？
  -- 3. 按下单时间还是支付时间归属到“这一天”？
  -- 4. 一单多商品，算1单还是算N个子单？
 
-- 评审产出：每个名词落成一句无歧义的定义，写进需求文档
-- 例：“订单量=支付成功且未全额退款的主订单数，按支付时间归属”

确认口径时有个高效技巧：拿真实数据当场对。跑一个昨天的数给业务方看，“按这个口径昨天是8,432单，和你的预期一致吗？”数字对上了，口径大概率理解一致；对不上，当场就能发现分歧，而不是上线以后。

第三问：怎么看——维度、粒度和展示形态

维度决定表设计，粒度决定数据量和成本，这两个问不清楚，底层表就没法设计。要确认的具体是：需要哪些维度（国家/渠道/版本…）、需要下钻到什么粒度（到天还是到小时？到渠道还是到素材？）、要不要看趋势（决定保留多长的历史）、期望的展示形态（看板、明细表还是推送到群里的日报消息）。

这里有个经验：业务方倾向于“维度越多越好、粒度越细越好”，但每多一个维度，宽表行数可能翻几倍。我的做法是评审时当场跑一个粒度成本估算，把数字摆出来一起做取舍：

-- 评审现场花两分钟估算粒度成本，用数字代替争论
SELECT
  COUNT(DISTINCT country)                    AS country_cnt,   -- 30
  COUNT(DISTINCT channel)                    AS channel_cnt,   -- 20
  COUNT(DISTINCT creative_id)                AS creative_cnt,  -- 8000+
  COUNT(DISTINCT country, channel)           AS grain_channel, -- 渠道粒度日行数
  COUNT(DISTINCT country, channel, creative_id) AS grain_creative -- 素材粒度日行数
FROM dwd_ad_stat_di WHERE dt = '${bizdate}';
-- “到素材粒度行数是渠道粒度的50倍，查询明显变慢，
--  你的决策真的用得到素材级吗？”——多数时候对方会主动收敛