别当取数机器：BI 的价值不在剥蒜，在三句话和需求表

结论

取数是数据分析师的必修课，但不是岗位价值，更不该成为核心任务。 入职半年到一年后，若仍陷在机械跑数里，老板会觉得「换新人也行」；硬拒又会被说「不赋能业务」——这就是取数死亡循环。应对心法：该做的应当做，不该做的坚决不做，实在不想做的让他们自己做；落地靠优先级排序 + 三句话 + 需求可行性验证表。

关键论点（MECE）

跳出取数循环
├── 一、诊断：剥蒜困境与死亡循环
├── 二、定位：取数为何必做、为何不能止步
├── 三、三句话：挡需求、定边界
└── 四、工具：优先级 + 需求可行性验证表 + 自助取数

一、诊断：剥蒜困境与死亡循环

现象	本质
去阿里做 BI，天天加班被业务要数据	像进米其林当厨师，每天却在剥蒜
Leader 说：取数帮 BI 了解业务、平台大结构复杂、业务没技术	有道理，但只描述了起点，不是终点
提意见不想只跑数 → 上面驳回	技术与业务结合才能解决问题——对，但不等于永远跑数

死亡循环（约半年～一年后）：

熟悉数据底层
    ↓
仍忙于跑数取数
    ↓
老板：没价值，新人也能做  ⟷  拒单：不响应业务、价值受疑
    ↓
离职 / 转岗 / 转行

根因：跑数枯燥、机械、无上升空间。

二、定位：取数为何必做、为何不能止步

必须做取数的理由（Leader 说得对的部分）：

分析最重要的是数据源准确（口径、指标、表）
业务放权自跑也效率低——重复跑、重复分析
新人学 SQL 取数，有利于熟悉数据底层与业务层

但不能止步于此：

取数是成长必经阶段，不是岗位价值
不应成为核心任务

三、三句话：挡需求、定边界

第一句：「你这个需求有没有人看？老板会不会看？」

不要接需求就立刻埋头做——很多需求做完无人问津
业务毛病：小事就提需求（临时报表），应用范围极小

优先级（必须排序）：

层级	说明	响应
1 · 领导/老板	大老板需求	快速响应、仔细产出、不能出错
2 · 部门/跨部门	如电商销售成本贯穿财务、销售、仓储	第二优先
3 · 个人/小部门	如某部门运营仪表板	最次要

第二句话：「你这个需求是不是已经是最详细、最完全的版本了？确定不改了？」

业务需求永远模糊——提出时往往不知改什么、改到什么程度
不问清就做 → 得不到业务部门认同

落地：

需求文字化，需求方签字认同
制度约定：什么做、什么考虑后做、什么不做 → 与业务协商落地

第三句话：「你这个需求太小太窄，完全可以自己做；有困难我们帮，但不会花很多时间。」

后招：一般难推（业务学新技术不如你代跑快）
适用：反复、临时、看完即弃的小需求（如时不时查销售数）
长痛不如短痛：帮 IT 开数据权限 + 你顶多设计取数面板；能不能要到权限是业务与 IT 的事

四、工具：需求可行性验证表

接需求前填表，业务认可方案后再分析，避免做完不被认。

类别	解释	示例（提高复购率）
核心目的	想实现什么目标？	提高复购率
定位问题	出现了什么问题？	新客户获客成本太大，增加了 10%
逻辑关系	目的与问题是否存在逻辑关系？	复购率能否降低获客成本？
场景拆解	分析内容是什么？	复购率与会员体系、商品、活动等有关
效果验收	需要做到什么程度？	将复购率提高 10%
预案时间	需要什么时候完成？	月底之前
成本控制	需要花费多大成本？	优化成本在 10w 以内
价值性	投入产出比多大？	投入产出比较高

需求可行性验证表示例

行动建议

本周：用验证表过一遍手头 1～2 个需求，找业务确认「逻辑关系 + 效果验收」。
本季：与业务落地「需求分级 + 什么做/不做」书面约定。
长期：重复临时需求 → 推权限 + 面板，把剥蒜变成开自助。

边界

大厂/业务型公司初期取数多属正常；三句话是减熵，不是拒服业务。
领导 KPI 若只看响应量，需结合主要矛盾判断是熬阶段还是换环境。

知乎收藏整理 · 2026-06 · 金字塔结构