有个做数据分析的朋友，最近被一句话弄得有点沉默。
他们团队花了一个多月，给业务线做了 10 张看板。经营日报、渠道转化、用户留存、复购分析、商品动销、活动效果，能想到的几乎都铺上去了。
结果周一早上，老板还是在群里问：
“上周新客复购到底怎么样？谁给我拉一下数。”
群里安静了几秒。然后有人说，看板里有。又有人补了一句，那个看板口径可能不是老板要的。再过一会儿，数据同学打开 SQL，重新查了一遍。
这事挺常见。
做看板的人很委屈。你要的东西我不是没做，我甚至做了很多。可是使用看板的人也不一定错。他不是不知道有看板，他是不敢直接拿那个数做判断。
这就是很多 BI 项目最尴尬的地方：
看板交付了，问题没有消失。
看板太多，有时说明问题还没被翻译清楚
很多公司做 BI，第一反应是补页面。
老板问经营情况，就做经营看板。运营问渠道效果，就做渠道看板。商品问动销，就做商品看板。后来每个人都想要自己的页面，于是看板越来越多，入口越来越散，字段越来越像。
做数据工作的同学坐在工位上，常常会有一种错觉：只要页面足够完整，业务就会自己去看。
可是业务不是去图书馆查资料。
他打开看板时，脑子里通常只有一个具体问题：
- 这个活动要不要继续投？
- 这个渠道是不是变差了？
- 这个商品是不是该补货？
- 这个客户群是不是值得再触达？
如果看板不能顺着这个问题往下走，它就会变成一个很漂亮的数据库橱窗。
橱窗里东西不少，但没人知道该先拿哪一件。
所以老板在群里问数，不一定是他懒，也不一定是看板少。很多时候，是看板没有把“业务问题”翻译成“判断路径”。
这两个词听起来像一个意思，其实差得很远。
指标页面告诉你：这里有 GMV、订单数、客单价、复购率。
判断路径告诉你：如果复购下降，先看新客质量，再看触达节奏，再看商品结构，最后再判断是不是活动带来的短期波动。
前者是数据陈列，后者才接近业务工作。
这也是很多数据产品经理最容易被误解的地方。
业务说“我要一张看板”，不一定是真的缺一张页面。他可能缺的是一条能放心走下去的路：从哪个入口看，看到异常先拆哪一层，什么情况下要找数据同学确认，什么情况下可以自己在会上拍板。
如果这条路没有被设计出来，看板越多，业务越像进了一个很大的仓库。货架很多，标签也有，但他不知道哪一排是今天要找的东西。
所以评审看板时，我现在更愿意先问一句：
“这张看板要替谁减少哪一次重复判断？”
这个问题比“还要不要加筛选器”重要得多。
老板不问看板，是因为他不确定那个数能不能签字
我见过一种很典型的场景。
一个看板里有“复购率”。运营自己的表里也有“复购率”。财务月报里还有一个近似指标。三个数不完全一样，差得不算离谱，但足够让人心里发毛。
于是老板不会在会上说“以 BI 看板为准”。他会说：“你们再核一下。”
这句话一出来，看板就退回成了参考资料。
数据团队最容易低估的，就是这个“签字感”。
一个数能被使用，不只是因为它算出来了。它还要让人知道：
- 这个指标的业务定义是什么？
- 统计周期从哪里到哪里？
- 哪些订单被排除了？
- 哪个系统是来源？
- 异常波动谁负责解释？
- 和财务、运营、增长团队各自手里的数有什么关系？
这些东西不写清楚，页面做得再漂亮，也只能解决“看见”，不能解决“相信”。
所以很多看板没人用，不是因为图不好看，也不是因为筛选器不够多。
是因为它没有成为一个可被引用的共同答案。
在公司里，一个数最重要的价值，不是显示在屏幕上，而是能不能被带进会议、周报和决策里。能带进去，它才算活了。带不进去，它就是一块亮着的背景板。
这个“能带进去”，不是一句口号。
它通常要经过几次很具体的确认。财务看过，确认收入口径没有冲突；运营看过，确认活动用户没有被重复计算；业务负责人看过，知道异常波动由谁解释；数据同学看过，知道这个口径以后不能随便改。
这些动作听起来琐碎，却是看板从“展示页面”变成“公司共识”的过程。
群里问数，其实是在问“你帮我判断一下”
还有一个更隐蔽的问题：很多业务问的不是数，而是判断。
他说“帮我查一下复购”，真正想知道的可能是：
- 活动带来的用户质量是不是差？
- 这周要不要继续投这个渠道？
- 新用户首单补贴是不是该降一点？
- 这个指标下降，是不是我的责任？
如果数据同学只回答一个数字，业务还会继续追问。
这时你会觉得他需求变来变去。他会觉得你只会查数，不懂业务。
两边都不舒服。
看板也是一样。如果一张看板只回答“发生了什么”，但不帮助用户继续判断“为什么发生”和“下一步看哪里”，它很难替代群里的人工问答。
这不是说看板要替业务做决策。数据团队也不该替业务拍脑袋。
但一个好看板至少要把下一步问题摆出来。
比如看到渠道转化下降，页面不能只放一根向下的线。它可以顺手把 3 个拆解入口放在同一屏：
- 流量结构有没有变？
- 落地页转化有没有变？
- 新客和老客的表现是不是分开变？
这样业务不是“看完一个数再去群里问”，而是可以沿着路径自己查下去。
这才是看板真正省人的地方。
它不是让数据同学少写一条 SQL，而是让同一个判断过程少被重复问 10 次。
下一张看板，不一定该马上做
如果你现在又收到一个新看板需求，我建议先别急着打开 BI 工具。
可以先问 4 个问题。
第一个问题：这张看板服务哪一个固定场景？
是周会复盘、日常监控、活动追踪，还是老板临时看经营？不同场景的页面密度、更新频率和指标顺序都不一样。没有场景的看板，很容易长成指标展厅。
第二个问题：这张看板要替代哪一种重复问数？
如果它不能减少某类重复沟通，可能只是又多了一个入口。入口变多，不等于工作变少。
第三个问题：里面的核心指标，谁有最终解释权？
如果复购率、转化率、活跃用户这些指标没有共同定义，看板上线后还会继续吵。吵到最后，大家还是回到群里找人确认。
第四个问题：用户看完以后，下一步动作是什么？
继续投放、暂停活动、排查渠道、调整商品、通知销售，至少要有一个方向。没有下一步动作的看板，很容易沦为“知道了”。
这 4 个问题问完，很多看板需求会变小。
有些只需要补一个指标解释。有些只需要改一个入口。有些需要先统一口径。有些压根不是看板问题，而是业务流程没有人愿意负责。
这时候你会发现，少做一张看板，可能比多做一张看板更专业。
数据团队真正要沉淀的，不是页面数量
我后来跟那个朋友聊，他说他们团队最累的不是做看板，而是每次都从头解释。
为什么这个指标这么算，为什么和上次不一样，为什么渠道 A 不能和渠道 B 直接比，为什么本周数据要剔除异常订单。
这些解释一开始在群里，后来在会议里，再后来散落在飞书文档、Excel 注释和某个同事的脑子里。
这才是问题。
看板只是最后一层界面。真正该沉淀的是三样东西：
- 指标口径：这个数到底怎么定义，什么情况下不能直接比较。
- 判断路径：看到变化后，先看什么，再看什么，最后怎么定位。
- 责任边界：这个数谁维护，谁解释，谁使用，谁拍板。
这些东西如果不沉淀，看板越多，误会越多。
因为每张看板都会带来新的解释成本。
所以我后来做 ss-data-skills 时，很自然地把“看板审查”“需求澄清”“指标口径审查”放了进去。
它不是一个神奇工具，也不替你做业务判断。它更像一套放在手边的工作提示卡：接需求前看一眼，看板评审前过一遍，提醒自己别只盯着页面，还要问场景、口径、路径和责任。
完整清单放在这里：https://github.com/shisuidata/ss-data-skills
不是为了显得流程正规。
是为了少一点“做完以后才发现大家理解不一样”。
说到底，数据团队的价值，不是把每个问题都做成一个页面。
而是让公司里那些反复出现的问题，逐渐有共同语言。
有了共同语言，群里问数会少一点。
就算还会问，至少大家知道该从哪里开始看。
我叫石头，在数据行业里摸爬滚打了十几年，也见过不少越做越厚的看板墙。这里写的，就是这些教训——我觉得值得说出来的那部分。
