返工那天，老陈把需求文档摊在了会议桌上

陈立衡是开云的一名数据工程师，做统计报表开发已经有些年头。前一阵子，他接手了一家连锁零售企业的月度经营报表项目。业务方在需求会上提得很简单：要一张能看各门店销售、库存和毛利的管理报表。老陈按惯例出了原型，开发、联调、上线，结果第一轮验收就被打了回来。业务负责人指着屏幕说，这个“销售”和他们理解的不是一回事，门店调拨算不算销售、退货冲减放在哪一天，双方各有一套说法。返工不可避免，老陈也由此重新审视了自己接需求的方式。

这类场景在开云的服务记录里并不少见。报表本身不难，难的是把业务语言翻译成数据语言。老陈后来总结，问题往往不在开发阶段，而在动手之前少做了几步确认。

第一张草图：把指标写到不能再拆

返工之后，老陈没有急着改代码，而是先画了一张指标草图。他把报表上出现的每个字段都列出来，逐个追问：这个指标的业务定义是什么、由哪几个原始字段计算得出、统计周期按什么时间口径、是否包含退货和赠品。比如“销售额”一栏，最终被拆成含税与不含税两个口径，并明确调拨不计入销售。

  • 指标名称与业务叫法保持一致，避免同义词混用；
  • 每个指标标注计算公式和数据来源表；
  • 明确时间归属规则，比如按订单创建时间还是发货时间；
  • 标注异常处理方式，比如负数金额和跨期退货如何归集。

这张草图后来成了开云项目组的标准动作。指标写到不能再拆，业务方签字确认，开发阶段就少了很多来回拉扯。

第二张草图：把使用场景画成流程

光有指标还不够。老陈发现，业务方说的“看报表”，实际包含好几种动作：店长每天早上看昨日销售排名，区域经理每周看库存周转，财务月底核对毛利。不同角色关注的粒度和频率完全不同。他把这些场景画成一张简单的流程草图，标出谁在什么节点打开报表、看完之后要做什么决策。

这张图帮项目组定下了报表的筛选维度和默认视图。开云在后续的报表开发中延续了这个做法：先确认使用场景，再决定页面布局和交互方式，而不是把所有字段堆在一张表上。业务方看到流程图后也更容易提出具体意见，而不是笼统地说“再改改”。

第三张草图：把验收标准提前写出来

第三张草图是验收清单。老陈和业务方一起，把“什么样算做完了”写成可核对的条目：某门店某月的销售额能否与财务账对上、库存数量能否与系统导出结果一致、筛选条件切换后汇总数是否同步变化。清单不追求面面俱到，但每一条都能实际验证。

这份清单在开发前就发给了双方，开发过程中按条目自测，验收时逐条勾选。老陈说，返工那次最大的教训就是验收标准来得太晚。如今在开云的统计报表项目里，验收清单和指标草图、场景流程图一起，构成了交付前的三道确认。报表开发终究是件细活，把边界谈清楚，后面的路才好走。