开场：一份被退回三次的报表需求单

周敏是九游的一名实施顾问，常驻客户现场。她接手过一个供应链看板项目，客户方提交的需求单上写着“按区域展示库存周转情况”。开发团队照单做了一版，客户看完摇头；改了两版，还是不对。到第三版被退回时，双方都有点急。周敏没有急着改需求，而是把客户方运营主管和九游的开发负责人拉到一张桌子前，逐字拆解“区域”这个词——是销售大区、仓储片区，还是物流覆盖范围？三种理解对应三套数据源，做出来的报表自然长得不一样。半小时后，口径统一了，第四版一次通过。这件事让她更确信：九游在项目里最该发挥的作用，不是把需求单原样转交，而是把业务语言翻译成数据语言。

现场一：需求澄清会上，先问“这个数用来做什么”

很多需求描述停留在“我要看什么”，却没说“看了之后做什么”。周敏养成了一个习惯：拿到需求先问用途。有次客户要求“每天推送客户活跃度排名”，她追问后发现，运营团队真正想做的是识别沉默客户并安排回访，而不是看一个静态名次。于是九游团队把方案调整为分层清单加触发规则，报表从“排名展示”变成“行动入口”。她总结了几条澄清动作，在九游内部被不少同事拿去复用：

  • 把需求里的名词逐个确认归属，比如“客户”指签约主体还是使用者账号；
  • 问清数据的使用频率和决策场景，日更和月更对应不同的建设成本；
  • 让业务方用一句话描述“看到异常数字后的第一反应”，反推指标设计；
  • 把确认结果写进需求纪要，由双方签字，减少后续反复。

周敏说，九游的项目复盘里，返工最多的环节往往不是技术实现，而是这一步没做透。

现场二：口径对齐，靠一张“指标身份证”

另一个项目里，财务部和业务部对“回款率”的算法各执一词，报表上线后两边数字对不上，会议开了三轮。周敏的做法是拉着双方一起建“指标身份证”：每个指标登记名称、业务含义、计算公式、数据来源表、责任人和更新频率。九游团队把这套登记表做成了在线文档，改动留痕。争论最激烈的时候，她让双方各自写出计算过程，摆在一起看差异点，问题很快定位到退款是否计入分母。口径定下来后，报表争议少了大半。她的体会是，口径不是技术问题，是共识问题，九游顾问的价值在于把共识沉淀成可查的记录，而不是每次开会重新吵一遍。

现场三：系统集成，先画一张数据流向草图

在对接客户已有的业务系统时，周敏习惯先手绘一张数据流向草图：数据从哪个系统产生，经过哪些环节，最终落到报表的哪张表。有次集成项目卡在数据延迟上，开发认为是对方接口慢，对方认为是九游的抽取逻辑重。草图一画，发现中间还有一个未被注意的中间库在定时同步，瓶颈就在那里。她把这套方法带进了九游的集成实施流程：先理流向，再谈接口，最后才排开发计划。对客户团队来说，这张草图也成了后续运维的入门材料。

周敏的手记里没有惊天动地的故事，多是这类琐碎的对接现场。但正是这些环节，决定了一套数据系统能不能真正被用起来。九游在项目里反复强调的，也正是这种把业务意图稳稳落到数据链路上的耐心。