项目出问题了。
“数据不对！“业务在群里@你。“怎么回事？“老板立刻追问。
你赶紧查。查了两个小时，发现是业务自己配置错了，跟你没关系。你解释清楚，问题解决了。但是你花了两个小时，搞得很狼狈，还给老板留下了”这个人负责的数据出问题”的印象。
然后项目成功了。
业务在汇报时说：“这个项目我们团队做了什么什么，产品做了什么什么，效果很好。”
你呢？没提。你做的那些数据支持、数据分析、数据监控——好像从来没发生过一样。
功劳是别人的，锅是你的。你愤怒，但不知道该愤怒谁。
核心洞察：数据工作的原罪——做好了是应该的，做不好是你的问题这不是你个人的失败，而是数据岗位的结构性困境：你的工作像水和电——有的时候没人感谢，没的时候所有人都骂。破局的关键是两件事：出问题时保护自己（明确归因），做好事时让人知道（主动记录和展示）。（如何让你的日常工作被更多人看见，我们在B9系统地讲。本篇聚焦在”归因和保护”——当问题和功劳的天平不公时，如何扳回来。）
为什么会这样
数据工作的特殊性。
数据工作有一个特点：做好了没人感谢，出问题所有人都知道。
数据正确的时候，没人说”多亏了数据团队”。因为数据正确是理所当然的。数据出错的时候，所有人都来找你。因为数据出错会影响业务。
这就像水和电：有水有电的时候，没人感谢供水供电公司；停水停电的时候，所有人都在骂。这是数据工作的原罪，你很难完全改变它。
支持性岗位的困境。
数据团队在很多公司是”支持性”的角色。业务做决策，你提供数据支持。产品做功能，你提供数据分析。支持性角色的特点是：成果归业务，问题归你。
因为在汇报的时候，汇报的是”业务做成了什么”，不是”数据提供了什么支持”。你是幕后，他们是台前。观众看到的是台前的人。
你没有主动claim功劳。
功劳不会自己跑到你头上，需要你去claim。别人汇报的时候没提你，是因为他们不觉得需要提。不是故意抢你的功劳，是没想到。
而你呢？你觉得”功劳应该是大家的""我不好意思邀功""说了也没用”。你不说，别人怎么知道你做了什么？
问题责任的不对等。
出问题的时候，为什么会找你？因为数据是最容易被质疑的环节。业务的判断是主观的，数据是客观的——至少看起来是。出了问题，第一反应是”数据是不是不对”。而且，查数据问题需要专业能力，只有你能查，所以只能找你。
但问题解决后呢？大家就散了。没人记得你花了多少时间排查。
这个状态的危害
你可能觉得：算了，忍忍就过去了。但这个状态长期下去，危害很大。
你的价值被低估。你做了贡献，但这个贡献不在别人的认知里。绩效评估的时候老板不会把这些贡献算给你，资源分配的时候你的团队不会得到足够的重视，组织调整的时候你的岗位可能被认为”可有可无”。
你承担了不成比例的压力。出问题都来找你，你的压力很大。功劳都是别人的，你的回报很少。压力大、回报少——这种状态很难持续，时间长了你会倦怠。
你的成长受限。如果你永远是”救火队员”和”支持者”，你不会有机会做更重要的事。你会一直被困在”出问题来救火”的循环里。
问题记录四要素模板
每次出问题被找来排查的时候，用这个模板记录。积累下来就是你的”价值证据库”：
| 要素 | 记录内容 | 示例 |
|---|---|---|
| 问题描述 | 什么时间、什么系统/报表、出了什么问题 | ”2024-11-15 14:30，运营日报GMV数据异常偏低，运营在群里反馈” |
| 排查过程 | 你做了什么排查、花了多少时间 | ”排查了数据管道、ETL日志、源系统数据，耗时2.5小时” |
| 根因与归属 | 问题的根本原因是什么、责任归哪个团队 | ”根因：业务侧配置了错误的活动ID，导致过滤条件异常。归属：运营团队配置错误” |
| 你的价值 | 你解决了什么、避免了什么、改进了什么 | ”快速定位问题，避免了运营用错误数据做决策；新增了配置校验逻辑，防止同类问题再次发生” |
