3. 需求调研与指标体系：业务方访谈技巧、核心指标定义（KPI/OKR）、指标分级与维度设计

做治理看板，最怕什么？

怕你吭哧吭哧画了一堆图表，业务方看一眼说：「这不是我要的。」

我早期就踩过这个坑。花了两周搭了个数据质量看板，自认为逻辑清晰、图表精美。结果业务负责人来了句：「你这些指标，跟我考核有什么关系？」

嗯，从那以后我学乖了——先搞清楚业务方到底要什么，再动手。这一章，我们就聊聊怎么做好需求调研，怎么把模糊的业务诉求翻译成可落地的指标体系。

3.1 业务方访谈：别让沟通变成「鸡同鸭讲」

访谈不是聊天，是结构化信息采集。我习惯把访谈对象分成三类：

访谈时，我常用一个「三问法」：

1. 你现在怎么衡量这件事？——了解现状，找到已有指标
2. 你觉得哪里最痛？——定位核心问题，这是看板要解决的关键
3. 如果有一个数字能帮你做决策，你希望是什么？——挖掘真实需求，避免「伪指标」

3.2 核心指标定义：KPI 还是 OKR？

很多团队在指标定义上翻车，是因为没分清衡量什么和驱动什么。

我个人习惯这样区分：

• KPI（关键绩效指标）：用来衡量「做没做到」。比如「数据完整性 ≥ 99%」。
• OKR（目标与关键结果）：用来驱动「做没做好」。比如「提升数据质量，将核心表完整性从 95% 提升到 99%」。

看板里两者都要有。KPI 告诉你现状，OKR 告诉你方向。

举个例子，我在一个金融项目中，帮业务方梳理了这样一组指标：

3.3 指标分级：把「重要」和「紧急」分开

指标不是平级的。我习惯把指标分成三级：

• L1 - 战略级：老板看的，反映整体治理水平。比如「数据资产健康度」。
• L2 - 战术级：业务负责人看的，反映流程效率。比如「数据接入成功率」。
• L3 - 操作级：一线人员看的，反映具体问题。比如「某张表的字段缺失率」。

为什么要分级？

说白了，不同角色关注点不同。老板不想看某个字段的缺失率，一线人员也不需要看整体健康度。分级之后，每个看板只展示对应层级的内容，信息密度刚刚好。

我曾在项目中用过一个「指标分级矩阵」，效果不错：

3.4 维度设计：让指标「可下钻、可对比」

指标定义好了，但光看一个数字没意义。你得让业务方能下钻——比如「数据完整性 98%」，是哪个部门拖了后腿？是哪个数据源出了问题？

这就是维度设计要做的事。我常用的维度包括：

• 时间维度：日、周、月、年，支持趋势分析
• 组织维度：部门、团队、个人，支持责任归属
• 数据源维度：系统、表、字段，支持问题定位
• 流程维度：采集、清洗、存储、应用，支持全链路监控

举个例子，一个「数据质量得分」指标，可以这样设计维度：

数据质量得分
├── 按时间：2024-01 得分 92%，环比 +2%
├── 按部门：市场部 88%，技术部 95%
├── 按数据源：CRM 系统 90%，ERP 系统 85%
└── 按流程：采集阶段 96%，清洗阶段 88%

这样，业务方一眼就能看出问题在哪。我曾经帮一个电商团队做看板，他们发现「订单数据完整性」只有 85%，下钻后发现是「支付接口」这个数据源的问题——修复后，完整性直接提升到 98%。

3.5 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作需求调研和指标体系设计的「路线图」：

3.6 避坑指南：我踩过的几个坑

最后，分享几个我亲身经历过的教训：

• 坑一：访谈只找一个人。 我曾经只跟业务负责人聊，结果做出来的看板，一线人员根本不用。后来我学乖了——至少访谈 3 个不同角色的人，交叉验证需求。
• 坑二：指标定义太模糊。 比如「数据质量好一点」——什么叫「好一点」？一定要量化。我后来强制要求：每个指标必须有明确的计算公式和目标值。
• 坑三：维度设计太粗。 只按「部门」下钻，发现不了根因。我建议：至少包含时间、组织、数据源三个维度，这样问题定位才够快。

好了，这一章的内容就到这里。记住：好的指标体系，是看板的灵魂。调研做得越扎实，后面的设计就越顺畅。