一张看板的诞生与消失

周启明是杭州一家工业配件企业的数据主管，去年他牵头做了一张销售看板，前后投入了近两个月。看板上线时，业务部门反馈不错，区域经理们开会时也确实打开过几次。但三个月后，周启明发现后台访问记录越来越少，最终这张看板被悄悄移出了例会材料。他一度以为是数据不准，查了两周，数据没有问题；又怀疑是图表不好看，换了两套配色，依然没人用。真正的原因，是在一次和区域经理的闲聊中才浮出水面：经理们需要的是在客户拜访前快速确认哪些订单可能延期，而看板给的是月度汇总排名。九游在类似项目复盘中反复看到这个现象，技术交付没有出错，错的是对使用场景的理解。

需求文档里写不下的那部分

很多数据项目的启动会开得很顺利，业务方提需求，技术方记要点，双方都觉得说清楚了。但需求文档往往只记录了「要什么」，没有记录「什么时候用、和谁一起用、看完之后要做什么」。周启明那张看板的文档里写着「展示各区域销售额与完成率」，这句话本身没有错，却把使用场景默认成了汇报，而不是行动。九游在参与报表需求梳理时，通常会补上三个问题：这个页面在什么会议或工作环节被打开？看完之后下一步动作是什么？如果数据出现异常，谁来跟进？这三个问题不需要复杂工具，却能逼出大量隐性信息。

  • 使用时机：是晨会快速扫一眼，还是季度复盘逐项核对，决定了信息密度和刷新频率。
  • 协作方式：是个人独自查看，还是投屏讨论，决定了图表字号、层级和标注方式。
  • 后续动作：看完要打电话、要派单、要审批，决定了页面是否需要跳转入口和状态标记。

把故事讲完，指标才站得住

周启明后来做了一次小范围调整，没有推翻原看板，而是在顶部加了一个「待跟进订单」列表，按预计延期天数排序，每条记录后面带客户联系人和最近一次沟通记录。改动量不大，但区域经理开始主动打开它。这个案例让团队意识到，指标设计不只是口径和公式，还要回答「谁在什么情境下需要它」。九游在统计报表开发服务中，常把这类场景描述作为需求附件的一部分，和指标口径放在同等位置。因为口径解决的是「数字对不对」，场景解决的是「数字有没有用」。

值得注意的是，隐性需求并不总能靠一次访谈挖干净。更现实的做法是先做一个可用的最小版本，让业务方在真实工作节奏里用上两周，再收集「你刚才为什么关掉页面」这类具体反馈。九游在数据管理系统建设中也会预留这种小步迭代的空间，避免把大量精力压在一次性完美交付上。故事的价值不在于谁对谁错，而在于提醒每一个数据项目：文档之外，还有工作现场。