从数据堆到决策桌：开云顾问程一舟的四个项目现场笔记

开场：为什么记下这些现场片段

程一舟在开云做数据实施顾问已经有些年头。他经手的项目不算惊天动地，多是报表开发、数据整合、看板搭建这类日常工程。但正是这些日常，让他攒下了一本厚厚的现场笔记。他说，数据项目里真正难的部分，往往不在技术选型，而在人跟人之间那些没说透的话。开云内部做项目复盘时，他常被请去讲这些片段，因为新同事听了能少走弯路。这篇文章整理了他近期分享的四个现场，分别对应业务访谈、口径对齐、看板验收和上线之后的维护沟通。

现场一：访谈时先问“这张表谁在看”

第一个项目是给一家做工业配件分销的企业搭建经营分析看板。程一舟第一次去访谈，业务负责人一口气提了十几个指标，从库存周转到客户复购，讲得很热闹。他没有急着记需求，而是问了一句：这些数字最后是给谁看的，那个人一周看几次。对方愣了一下，回答说老板每周例会看一次，区域经理每天看库存。

这一问把需求拆成了两层。老板那层要的是趋势和对比，区域经理那层要的是当日可动的明细。开云团队后来按这个分层设计页面，例会用的页面只留六张图，日常用的页面则把筛选和明细放在前面。程一舟在笔记里写：访谈不是收集愿望清单，而是先弄清使用场景。他习惯在开云的项目启动会上就把这句话讲给客户听，免得后面反复改。

• 先确认看表的人、看表的频率、看表之后的动作。
• 把“我要这个指标”翻译成“我要用它判断什么”。
• 访谈记录当场复述一遍，让业务方确认没有理解偏差。

现场二：口径对不齐，往往卡在一个词上

第二个项目做的是销售数据整合，涉及三个业务系统的订单表。开云团队在梳理口径时发现，三个系统里“有效订单”的含义各不相同：一个按付款状态算，一个按发货状态算，还有一个把退货前的都算进去。业务部门开会时各说各的，数字自然对不上。

程一舟的处理办法是把三个定义并排写在一张纸上，请三方各自说明业务背景，再一起定一个主口径和两个辅助口径。主口径用于对外汇报，辅助口径留在明细里供追溯。他在开云的内部培训里常提这个案例，因为口径问题看似技术，实则是业务语言没有统一。他建议项目前期留出专门的口径确认环节，把定义写进文档并让各方签字确认，比事后争论省力得多。

现场三：看板验收，别只看图好不好看

第三个项目是可视化看板上线前的验收。客户方一位运营主管看完演示说挺漂亮，程一舟却请她把日常最关心的一个问题现场查一遍：上周华东区退货率突然升高，能不能在两分钟内从看板上找到原因。主管操作后发现，页面虽然好看，但下钻路径断了，只能看到汇总，看不到具体品类。

这次验收暴露了展示与分析的脱节。开云团队随后补上了联动筛选和下钻明细，并把常用查询路径做成快捷入口。程一舟在笔记里总结：验收要带着真实问题去点，而不是顺着演示脚本走。他后来把这个方法固定进开云的项目验收清单，要求每个看板至少通过三个真实业务问题的检验。

现场四：上线不是终点，维护沟通要提前排

第四个项目做的是数据管理系统，上线三个月后客户反馈部分报表加载变慢。排查发现是业务量增长带来的数据量上升，而索引和汇总策略没有随之上调。问题本身不复杂，复杂的是没人负责跟进。程一舟借此推动客户指定了一位数据接口人，并把开云的维护沟通机制写进交付文档：每月一次使用反馈收集，每季度一次性能回顾。

他在分享最后说，数据项目做久了会发现，交付物不只是报表和系统，还包括一套能持续运转的沟通习惯。开云在这些项目里扮演的角色，一半是技术实施，一半是帮客户把使用和维护的节奏建立起来。这大概也是他愿意把这些现场片段记下来的原因。