复盘一：需求调研阶段，业务方说的和真正要的往往不是一回事

在九游参与的数据管理项目中，需求调研几乎是所有问题的源头。有个做建材供应链的客户「恒茂达」，最初提出的需求是“把各分公司的销售数据汇总到一张表”。听起来很简单，但真正落地时才发现，各分公司对“销售额”的理解完全不同：有的含税，有的不含税，有的把退货冲减放在月末统一处理。如果调研阶段只记录需求描述而不追问业务口径，后面所有的报表开发都会变成返工。

九游的经验是，调研时至少要让业务方把“这个数字从哪里来、经过谁的手、最后给谁看”讲一遍。这个过程比填需求表有效得多。另一个常见问题是，业务方只提自己部门的诉求，跨部门的数据流转没人负责，等到集成时才发现上下游对不上。九游通常会在调研阶段拉一张跨部门的数据流向草图，把断点提前标出来。

  • 追问口径来源，而不是只记录需求名称
  • 识别跨部门数据断点，明确责任接口人
  • 把“汇总”拆解为采集、清洗、映射、呈现四步分别确认

复盘二：数据标准不先定，报表开发就是反复改

第二个项目是一家连锁餐饮企业「味知源」，门店数量在扩张期增长很快，九游在介入时发现，同一套会员数据在三个系统里有三套编码规则。报表开发团队每做一张新报表，都要重新确认一次字段含义，效率极低。后来九游建议先做一轮轻量的数据标准梳理，把客户、门店、商品三类主数据的编码和关键属性固定下来，再继续报表开发，返工率明显下降。

这件事说明一个道理：数据标准不是大企业的专利，也不是非得做成厚厚一本规范才叫标准。九游在实践中更倾向于“最小可用标准”，先把高频使用的字段和编码统一，剩下的在迭代中逐步补齐。标准定得太重，业务方配合意愿反而低；定得太轻，又起不到约束作用，这个度需要在项目节奏里找平衡。

复盘三：系统集成不是接上就完事，监控和异常处理才是长期成本

第三个项目涉及业务系统与数据平台的对接。上线初期一切正常，但运行两个月后，九游的运维同事发现某张中间表偶尔会出现数据延迟，原因是源系统在夜间批量任务中偶尔超时。这类问题在集成方案里往往只写一句“异常重试”，实际却需要明确的告警规则、重试策略和责任人。

九游在复盘时把集成工作分成两层来看：一层是接口能不能通，另一层是通了之后稳不稳。很多项目只验收第一层，第二层靠人盯。更合理的做法是在交付时就把监控指标、异常日志和值班机制一并移交，让客户团队有能力自己定位常见问题。集成不是一次性的技术动作，而是一项需要持续运营的能力。

  • 接口验收要包含异常场景，而不只是正常流程
  • 监控指标和告警规则应在交付清单中明确列出
  • 运维交接要有可执行的排查手册，而非口头说明

复盘四：运营交接做得好，平台才不会交付即闲置

三个项目有一个共同点：上线不是终点。九游观察到，平台能否持续产生价值，很大程度上取决于交接阶段是否把“怎么用、谁来用、用出问题找谁”讲清楚。有的客户在项目结束后，业务团队仍然习惯用原来的手工表，原因不是平台不好用，而是没人告诉他们新报表在哪里、怎么看、和旧表有什么区别。

九游现在的做法是在交付阶段安排面向业务团队的场景化讲解，不讲功能菜单，而是拿他们日常关心的几个问题现场演示。同时留下一份常见问题清单，把口径说明、字段解释和更新频率写进去。这些动作不复杂，但能显著降低平台闲置的概率。数据管理项目的价值最终体现在业务的使用习惯里，而不是验收报告上。