一次返工引发的复盘

九游项目组前阵子接手了一家连锁零售企业的报表建设项目。需求评审会上，业务方说要一张“门店月度销售汇总表”，数据团队按常规理解做完了开发，上线当天却被退回：业务方要看的是剔除退货和调拨之后的净销售，而且统计维度要按“经营区域”而不是“行政区域”。类似的情况在九游的技术问答栏目里并不少见，问题往往不出在技术实现上，而是出在需求从业务语言翻译成数据语言的那一段路上。

这次返工让团队意识到，项目里缺的不是开发人手，而是一个能把业务诉求稳定转成数据口径的衔接角色。九游在后来的项目复盘中，把这个角色单独拎出来讨论，发现它承担的沟通成本远比想象中高。

衔接角色到底在做什么

很多人以为这个角色就是“传话的”，实际远不止。九游观察下来，一个合格的衔接角色至少要完成三件事：

  • 把业务方口头描述的场景拆成可计算的字段和过滤条件，比如“有效销售”要明确是否含赠品、是否扣优惠券。
  • 在需求评审阶段就把指标口径写成文字确认，而不是留到开发完成后再对。
  • 在验收环节带着业务方逐列核对数据，把差异当场定位到具体规则，而不是笼统地说“数据不对”。

这三件事听起来简单，但九游在多个项目里发现，只要其中一步被跳过，返工概率就会明显上升。尤其是口径确认，很多团队习惯在聊天记录里口头约定，等到三个月后业务方换了对接人，同一张报表就没人说得清当初为什么这么算。

为什么这个角色容易被忽略

从组织架构上看，这个岗位往往没有独立编制，有时由数据分析师兼任，有时由项目经理临时顶上。九游接触过的一个制造企业案例里，衔接工作分散在三个人手上：需求由业务助理记录，口径由开发自己判断，验收由运维顺手点一下。结果一张设备运行效率报表连续三个版本口径不一致，业务部门干脆自己另建了一套表格，系统里的报表反而没人用。

被忽略的另一个原因是考核方式。开发看交付速度，业务看结果好不好用，衔接环节的质量很难量化，做好了是“本来就应该这样”，做差了才被看见。九游在技术咨询中常建议客户把这个角色的产出物显性化，比如一份口径说明文档、一张需求确认单，让衔接工作有据可查。

给团队的几点落地建议

如果团队暂时没有专职的衔接角色，九游建议先用流程补位。需求评审时强制输出一份口径清单，哪怕只有半页纸，也要写清统计范围、时间口径和排除规则；报表上线前安排一次业务方参与的走查，用真实数据逐项对照；每次口径变更都记录在同一个文档里，避免版本散落。九游在多个报表系统建设项目中验证过，这套做法不增加多少工作量，却能明显减少来回沟通的次数。

说到底，数据团队的价值不只体现在写代码和搭系统上，也体现在把业务语言准确翻译成数据规则的能力上。九游会继续在技术问答栏目里整理这类协作场景的处理思路，帮助团队把隐性的衔接工作变成可复用的方法。