从一次口径对不齐的例会说起：开云数据顾问林嘉禾的项目复盘手记

例会上的三张报表，说了三种“销售额”

林嘉禾是开云的一名数据实施顾问，手头同时跟进着四家制造与零售企业的数据项目。她印象最深的一次现场，是在客户月度经营例会上，销售负责人、财务负责人和运营负责人各自打开了一张报表，屏幕上写的都是“本月销售额”，数字却相差近两成。会议开了四十分钟，前二十五分钟都在争论谁的数对。

散会后，林嘉禾没有急着改报表。她把三张报表背后的取数逻辑逐一拆开：一张含税、一张不含税，一张把退货冲减放在次月，另一张放在当月。开云团队随后用两天时间把三个口径摆在同一张对照表里，请三方业务负责人逐条确认。她后来在项目记录里写：口径不是技术问题，是业务共识问题，技术只是把它固定下来。

需求澄清阶段，最容易被跳过的那一步

在开云参与的多个数据管理项目中，林嘉禾养成了一个习惯：正式开发前，先约业务方做一次“指标走查”。不是问他们要什么图表，而是请他们用一句话说清楚这个指标回答什么业务问题、由谁负责、异常时找谁。

• 指标名称是否在各部门叫法不同，比如“活跃客户”在销售和运营那里指的是两批人。
• 统计周期是否统一，自然月、财务月、滚动三十天混用的情况并不少见。
• 数据来源是否唯一，同一字段从两个系统取数，迟早会对不上。
• 异常处理是否有归属，退货、调账、跨期补录由谁在什么节点确认。

这套走查看起来慢，却让开云在后续报表开发中少走了不少返工路。林嘉禾的体会是，需求文档写得再厚，如果口径没有业务方签字确认，上线后依然要被推翻。

看板上线那天，真正的项目才刚开始

项目交付那天，客户运营主管在会议室投屏上看了一遍新看板，说了句“比原来清楚”。林嘉禾没有就此收工，她拉着对方又坐了半小时，把每个图表的查看频率、责任人、更新节点记在一张维护清单上。开云在这些项目里逐渐形成一个做法：报表上线只是起点，后面还需要口径变更记录、数据异常反馈通道和定期回访。

她印象里有一次，客户在季度末临时调整了区域划分，如果没人跟进，看板上的区域对比就会悄悄失真。正是因为维护清单上写明了变更同步责任人，这次调整在两天内完成了口径更新。林嘉禾说，数据项目做久了会发现，交付物不只是看板，还有一套让人愿意持续用下去的小机制。

写进项目记录的三句话

复盘这次例会风波，林嘉禾在开云内部的项目记录里留下三句话：第一，先对齐业务语言，再谈字段和表结构；第二，口径确认要落到具体的人，而不是停留在会议纪要里；第三，上线之后仍要有人对数据负责。她说，这三句话不新鲜，但每做一个项目，都会重新验证一遍。