BI 项目做到一半返工，常见原因不在开发速度。业务方说要一个看板，数据团队照着做了，上线后却没人打开；或者会上三个人都说销售额，数字却对不上。需求收集阶段留下的模糊，会在开发和验收时变成反复修改。
这类返工在数据看板项目里很常见。把 BI需求分析做扎实，产出应该是一组可验证的决策任务：谁在什么场景下看什么数，看到变化后做什么，做到什么程度算通过。下面按这条线拆解方法，附一张可直接用于访谈的需求卡和两组改写示例。
先问决策场景，再问要什么图
BI需求调研常被跳过的是决策场景。访谈第一句可以换成：“最近一次因为缺少哪个数据，会议延迟、争论或拍错板？”对方回答的具体事件，比“想看经营情况”更有信息量。
继续追问五件事：
- 你看到什么变化，会调整预算、排期、投放或人员？
- 变化到什么程度算异常，和哪个基准比？
- 数据晚一天或晚一小时，会不会影响动作？
- 这个数你会转给谁，对方拿它做什么？
- 如果只能保留三个数，你留哪三个？
访谈对象至少分三类。决策者说明动作和后果，执行者说明触发条件和操作细节，数据实现者说明来源、粒度、权限和刷新能力。只找 IT 或只找业务，都容易漏掉一半约束。
结束前用一句话复述场景：谁，在什么时点，看到什么信号，采取什么动作。对方补充不出新的关键条件，场景才算清楚。先问最近一次决策，再问需要什么图。
一句业务问题，要拆成哪几层问题
业务问题通常混着现状、原因和行动。直接丢给开发，容易变成一张大而全的报表。可以按五类拆开。
| 问题类型 | 要回答什么 | 例子 |
|---|---|---|
| 现状 | 现在是多少，趋势如何 | 上周支付净额是多少，离目标差多少 |
| 结构 | 哪些维度贡献了变化 | 哪个渠道、品类、新老客贡献最大 |
| 原因 | 变化与哪些版本、活动、外部事件同时发生 | 下降是否与新版本发布或投放调整重叠 |
| 预测 | 按当前趋势会走到哪里 | 按近四周趋势，本月能否达标 |
| 行动 | 看到什么信号，做什么动作 | 低于目标 10% 时暂停哪类投放 |
监控型看板通常解决现状和结构，诊断型任务重点在原因，探索型问题可能需要先做一次分析，稳定后再固化成看板。展示需求和分析任务要分开。 用一张看板承接所有问题，最后往往既不好看，也不好查。
每个问题再标三个条件：统计粒度、分析维度、对比基准。按天还是按周，按渠道还是按门店，和上周期、目标还是同类业务比。没有对比基准的数字，很难支持行动。
Oracle 在 Fusion Data Intelligence 实施文档 中建议，需求阶段要明确需要监控的业务指标、分析工作簿功能、权限与数据限制、数据来源和数据加载频率，并为每项功能需求约定测试场景。这个顺序值得借鉴，先把问题和验证方式说清，再进入开发。
指标口径要写到能复算
把业务需求转成指标，公式之外，更花时间的是边界。指标名称相同，含义可能完全不同。销售额可以指下单金额、支付金额、扣除退款后的净额；活跃用户可以按登录、启动或产生关键行为来算。需求卡里只写“销售额”，开发和业务就会各自理解。
一个可执行的口径至少写清六件事：业务含义、计算公式、数据来源、统计粒度、统计维度和过滤条件。再补时间口径、负责人和版本。
| 要素 | 要回答的问题 | 示例 |
|---|---|---|
| 业务含义 | 这个数支持什么判断 | 渠道真实收入贡献 |
| 计算公式 | 分子、分母和加减项是什么 | 支付成功金额减退款金额 |
| 统计对象与粒度 | 按订单、用户还是门店计数 | 按订单号去重，按日汇总 |
| 时间口径 | 按创建、支付还是退款时间归期 | 按支付时间归日 |
| 过滤条件 | 哪些记录不计入 | 排除测试、取消、风控拦截订单 |
| 数据来源 | 来自哪些系统或表 | 订单库、退款表、渠道映射表 |
两个容易漏的边界是退款跨期和拆单支付。退款算在支付日还是退款日，拆单按父订单还是子订单计数，都要提前写明。业务负责人对含义签字，数据团队负责实现和校验，变更保留版本。这样同一指标换一个入口查询，才有机会得到同一个数。更完整的口径管理方法，可以参考统一指标口径的搭建思路。
一张需求卡，把访谈变成可开发任务
下面这张卡可以直接带进访谈。每个场景填一张，不追求一次填满，先把影响决策的字段写清楚。
| 字段 | 访谈时要问清 | 填写示例 |
|---|---|---|
| 场景名称 | 这个需求服务于哪次具体决策 | 周一渠道预算会 |
| 使用角色 | 谁看，谁据此行动 | 渠道负责人 |
| 决策动作 | 看到什么信号会做什么 | 净销售贡献连续两周低于目标，调减预算 |
| 核心问题 | 一个主问题加最多三个追问 | 上周各渠道净销售贡献如何变化，下降由谁贡献 |
| 指标与口径 | 名称、公式、统计对象、时间、过滤条件 | 支付净额等于支付成功金额减退款金额，按支付时间归日，排除测试与取消订单，按订单号去重 |
| 维度与下钻 | 哪些切分能解释波动 | 渠道、品类、新老客、日和周 |
| 时间范围与对比 | 看多长，和谁比 | 近八周，对比目标与上周期 |
| 时效与刷新 | 数据晚到多久就没用 | T+1 数据，每日 8 点前刷新 |
| 数据来源与权限 | 从哪来，谁能看，哪些字段脱敏 | 订单库、退款表、渠道映射表；渠道组可见，手机号脱敏 |
| 展示形式 | 首屏放什么，如何下钻 | 首屏三个指标，点击进入渠道和品类 |
| 验收任务 | 谁在什么时间完成什么动作，达到什么结果 | 周一 9:30 前，三次点击定位下降前三个渠道，抽样差异不超过 0.5% |
| 负责人和版本 | 口径谁签字，变更谁审批 | 业务负责人签字，数据产品经理维护版本 |
填写时守住两条。核心问题不超过一个主问题加三个追问，问题太多说明场景还没收窄。验收任务写到可观察的动作和时间，不写“体验流畅”“数据准确”这类无法判定的描述。这张卡覆盖 BI需求分析里常被漏掉的五类信息：决策、问题、口径、时效、验收。评审后再补数据依赖、开发估算和风险，进入排期。
验收任务怎么写，才能避免看板做完没人用
看板验收标准如果只列功能，很容易通过：数据源接入了，报表能打开，权限配置生效。上线后业务还是找分析师取数。验收对象从功能改成任务，情况会不同。
第一层是定义验收。业务负责人逐条确认指标含义、公式、时间口径和过滤条件。取消、退款、拆单、跨时区、测试账号这些边界样例要有明确结果。版本、变更人和确认记录都能查到。
第二层是数据验收。拿看板结果与源系统或财务日结对账，抽查明细，检查重复、缺失和异常值。确认刷新时间和延迟，用不同权限账号验证可见范围。数据质量很难靠一次验收解决，已知限制要写在验收记录里，不能把未验证的部分说成完整事实。
第三层是场景验收。找三到五名目标用户，在约定时间内完成三个真实任务。记录完成时间、点击路径、是否需要分析师协助，以及用户能否复述结论和下一步动作。
一条可用的验收任务可以写成这样：渠道负责人能在周一 9:30 前打开看板，三次点击内定位到净销售贡献下降的前三个渠道，抽查五个渠道的周合计与财务日结差异不超过 0.5%，并能说出本周预算调整依据。任一项未达到，记录为未通过。0.5% 是示例阈值，企业要按自己的数据基础设定。
不建议把营收增长作为单一验收标准。业务结果受市场、活动、供给等多重因素影响，单靠 BI 很难归因。把定义、数据、场景三层验收做扎实，再在上线后两到四周观察使用频次和动作记录，判断会更可靠。
两组改写示例，从想要一个数到可验收任务
下面两组示例都来自常见诉求。数字只用于说明写法，不是行业基准。
示例一，监控型需求，各渠道销售看板
原话是“给我做一个各渠道销售看板，最好能按天看”。这句话缺少决策场景、口径和验收条件。
- 场景：渠道负责人每周一 10 点开预算会，决定下周渠道预算增减。
- 主问题：上周各渠道支付净额是多少，离目标差多少；下降由哪些渠道、品类、新老客贡献。
- 口径：支付净额等于支付成功金额减退款金额，按支付时间归日，排除测试、取消和风控拦截订单，按订单号去重。
- 维度与时效：渠道、品类、新老客；日和周；T+1 数据，每日 8 点前刷新。
- 权限：渠道组和财务可见，手机号等个人信息脱敏。
- 验收：周一 9:30 前，三次点击定位下降前三个渠道；五个渠道周合计与财务日结差异不超过 0.5%；负责人能复述预算调整依据。
改写后，开发知道先做哪几个指标、从哪张表取数、什么时间必须跑完，业务也知道上线后要怎么用。
示例二，诊断型需求，转化率下降找原因
原话是“最近转化率掉了，帮我看看原因”。这是一次分析任务，直接做成每日看板，很容易堆很多图，却回答不了当前问题。
- 场景：增长负责人发现日支付转化率连续三天低于近四周基线 10%，要决定暂停投放还是修漏斗。
- 主问题：下降从哪天开始；集中在哪些渠道、机型、版本；漏斗哪一步贡献最大；是否与新版本或活动重叠。
- 口径：支付转化率等于支付成功用户数除以进入商品详情页用户数，按天、渠道、版本统计，用户按账号去重。
- 任务类型：先做一次诊断分析，不固化为每日看板；结论稳定后再沉淀监控指标。
- 时效：当天给出首轮结论，支持小时级数据。
- 验收：30 分钟内给出变化贡献前三的维度；每个结论能回溯到查询和口径；业务据此执行一次动作并记录结果。
诊断型需求要允许分析师追问和调整假设。把探索过程硬写成固定报表，反而会把有用的分析挡在验收之外。
评审、排期与变更怎么管
需求卡填完，不等于可以直接开发。评审会上至少要有业务负责人、数据开发、分析师和权限负责人。大家过的是场景、口径、数据依赖和验收任务，不逐页讨论原型好不好看。
排期先做影响决策的三到五个指标，覆盖一个核心场景。数据缺口、依赖系统和权限审批单独列出来。以后可能有用、先加上的需求放进候选池，不进入首版。
口径变更要走版本。改一个公式，可能影响看板、报表、接口和自然语言问数。变更记录写清谁改、何时改、为什么改，以及影响了哪些下游。没有影响面检查，口径会越改越乱。
当指标定义、权限和验收任务都能落到可执行语义层，自然语言问数才有稳定基础。先统一指标，再开放自然语言问数。 否则业务问得越快，错误答案传播得也越快。ThinkingAI 的数据分析 Agent 面向这类任务，支持自然语言追问、归因和可视化，是否能给出可用结果，仍要拿企业自己的数据、权限和已知答案的问题去验证。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款，这些数据基础设施经验可以作为参考，不能代替企业自己的验收。
常见问题
BI 需求访谈应该找哪些人
至少找三类：能拍板业务动作的负责人，每天执行动作的一线人员，负责数据接入和口径实现的数据人员。每类找两到三人，分别核对同一场景，能发现口头描述和实际做法之间的差异。
业务方只说“做个看板”，怎么继续问
请对方回忆最近一次相关决策，问清当时缺什么数、看到什么变化会行动、数据晚到会不会影响判断。把回答写成一句场景描述，再让对方确认。场景不清楚时，先做一次小范围分析，比直接排开发更省时间。
指标口径由谁确认
业务负责人对含义负责，数据团队对实现和校验负责。口径要书面确认，边界样例要写清，变更要留版本。数据团队可以提出计算约束，不能替代业务定义。
需求一直变，怎么控制
把需求分成影响决策的核心项和探索项。核心项进入首版并设定变更窗口，探索项走小范围分析或候选池。每次变更说明原因、影响面和验收调整，不把新增图表直接塞进当前迭代。
数据质量差，验收还能通过吗
可以在明确范围内通过，不能把未知说成已知。验收记录要写明哪些数据已验证、哪些存在延迟或缺失、报表在哪些场景下不适用。先保证关键决策所需的数据可信，再逐步扩大范围。
BI 需求文档要写多长
一个场景一张需求卡，通常一到两页，附指标口径和验收任务。文档长度不是重点，能否让业务确认、让开发复算、让验收人判断通过，才是重点。
