软件分析与设计笔记 06：范围界定（数据侧）：用数据校验你的判断

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。04 做了预习、05 界定了范围，这一篇用数据去校验前两篇里那些「假设」。

0 当访谈结论和数字对不上

先看一个和本项目结构一样的矛盾。

客服小林在访谈里说：「最麻烦的是找不到工程师，我一天有半天在打电话问他们有没有空。」听起来，核心需求就是「排期可见」。

但翻开她自己的 Excel 记录，统计一下 80 通来电的类型，会看到另一幅图景：

这不是谁在说谎。「我认为我最头疼的是找不到工程师」和「我一半的时间在接客户的催促电话」可以同时成立。访谈拿到的是自我认知，数据拿到的是实际时间分配。

两者的含义完全不同：如果照访谈做「排期看板」，小林自己那 20% 的问题解决了；但如果照数据做「客户自助查进度」，解决的是一半的电话量。这两件事都得做，但优先级不一样了。

笔记 02 已经讲过：数据告诉你发生了什么，用户告诉你为什么。这一篇讲数据这一侧具体怎么用。

1 分析的四个层次

1.1 四个层次与它们的前提

从低到高，分析（analytics）通常分四层：

关键在第三列：每一层都比上一层多一个前提。很多数据项目失败，不是因为模型不够好，而是基础没打牢就直接去做上一层 —— 比如口径都没统一，就急着建预测模型。

拿贯穿案例走一遍这四层：

这张表本身就是个有价值的结论：「提前预判哪些配件下周会短缺」这个诉求，在本例里做不到 Predictive 这一层。数据只有 8 个月、且没有季节性标记，预测出来的东西不可信。

那怎么办？退一步做 diagnostic 加一条简单的规则 —— 「某配件连续两周出库量上升且当前库存低于两周用量就提醒」。这不是预测，是基于规则的处方，但它现在就能做。

知道哪一层做不到，比硬做上一层更有价值。这一点在考试里也是加分项：能说出「这一层的前提不成立，所以我退回到上一层」比硬写「用 AI 预测」强得多。

1.2 处理文本的两类方法

除了这四层，还有一类方法处理的是非结构化的文本，而不是报表数字：sentiment mining（情感挖掘）从评价、客服记录里提取情绪倾向；big data analytics（大数据分析）面对的是数据量本身超出常规工具处理能力的场景。它们的共同点是：先解决「怎么把文本变成可统计的东西」，再谈分析。

本例里有一份现成的文本数据：客服通话记录。把 80 通电话按「问进度 / 报故障 / 催单 / 投诉」分类，就是一次最朴素的情感挖掘 —— 不需要模型，人工标 200 条就能看出分布。

2 数据准备、搜集与应用地图

2.1 三步，写成一张表

数据侧的工作可以归成三步：

1. 明确业务目标（business objective） —— 这件事是为了改什么？通常要落成可测量的 KPI（关键绩效指标）。
2. 选分析手段 —— 对应上面四个层次里的哪一层。
3. 列出所需数据 —— 需要哪些字段、从哪个系统来、能不能采到。

把这三步写成一张表，就是应用地图（application map）：每一行从「目标」推到「手段」再推到「数据」。它同时暴露两种问题：目标说不清的，以及数据拿不到的。

本例的应用地图：

注意第一行那个 ❌：「来访原因」这个字段现在不存在。这意味着要实现这个目标，必须先把它加进系统 —— 而这本身就是一条需求。

2.2 两个需要单独留意的动作

这张表里有两个动作需要单独留意：

• data preparation（数据准备） —— 清洗、补全、统一口径。这一步通常占掉整个数据工作一半以上的时间；
• data collection（数据搜集） —— 有些数据现在根本没采，需要在系统里新增埋点。而新增埋点意味着这是需求，要写进需求文档。

第二点是数据侧最容易漏掉的产出：「我们需要采集这些字段」本身就是一条需求。

本例里这条需求长这样：

系统应记录每次客户来电的原因分类（报修 / 问进度 / 改约 / 投诉 / 其他），由客服在挂断时选择，用于后续分析。

写给开发看，这就是一个下拉框加一个字段；但如果没有这句，整个「把问进度来电降到 20%」的目标就无法验证。

3 数据能做什么、不能做什么

3.1 能做：量化、验证、发现异常

能做：

• 量化规模 —— 到底是 5% 的工单白跑，还是 30%；
• 验证假设 —— 笔记 04 里那些「假设与理由」，靠数据推翻或确认。本例里「客服人力是瓶颈」这个假设，就被 20% 的往外拨号占比推翻了；
• 发现异常 —— 找出与预期不符的地方。比如某个片区的缺料率是其他片区的三倍，这就提示那里有没被理解的东西（可能是配件型号特殊）。

3.2 不能做：解释原因

不能做：

• 解释原因。 数据能告诉你缺料工单占 11%，但不会告诉你是因为仓管没看申请，还是因为供应商交期太长。

所以回到那个词：data-informed design。数据负责指出「哪里不对劲」，用户负责解释「为什么」。

本例里那条 11% 的缺料率，必须去问仓管小周才能定性 —— 她可能会说「申请是收到了，但那个型号供应商要等两周」。这句话数据里没有，但它决定了方案是「加库存」还是「换供应商」。

4 数据最容易在哪几个地方骗你

• 样本偏差（sample bias）。 只统计了用了这个功能的人，没用过的人不在样本里，而后者往往才是重点。本例：只统计线上报修的用户，会漏掉那些「打过一次电话就再也不来了」的客户；
• 幸存者偏差（survivorship bias）。 你看到的是留下来的用户，流失用户的行为轨迹在他们离开后就断了；
• 指标口径不一致（metric definition）。 「完成率」在两张报表里定义不同 —— 是「当天完成」还是「一周内完成」？结论就会互相打架；
• 数据质量（data quality）问题。 埋点漏报、字段缺失、时间戳时区错乱。本例：Excel 里的日期手填，有 11/3 也有 2026-11-03，直接排序就乱；
• 数据管道（data pipeline）中断。 中间某个环节停了几天，导致对比的两个时间段根本不可比。

这五条有个共同特征：它们都不会报错，只会给出看起来正常的错结论。所以在用数据下判断前，先花点时间确认数据本身可信。

本例里最该先做的是口径统一：「白跑一趟」到底算不算「到了现场但客户不在家」？如果不先定义，11% 这个数字每人数出来都不一样。

5 数据侧的四个准备动作

把上面这些收成可执行的四步：

1. 先写业务目标与 KPI，再谈数据。目标不明确的报表，做出来也没人看；
2. 确定基线（baseline） —— 改动之前的数值是多少？本例的基线是：问进度来电 50%、缺料率 11%、月报耗时 3 天；
3. 检查数据质量 —— 这个时间段的数据是全的，还是台账刚记了一半；
4. 最后才看数，并且把结论写成可验证的假设，回到数据里确认（和笔记 02 的四步法同一个落点）。

第 2 步的基线很容易被跳过，但它决定了这个项目最后能不能证明自己有用。没有基线，上线后无论数字是多少，都没法说「改善了」。

本节自测

1. 访谈说「最头疼找不到工程师」，数据说「一半时间在接催促电话」，这个矛盾怎么解释？它如何改变了优先级？
2. 分析的四个层次里，为什么不能跳过前两层直接做预测？
3. 本例「提前预判配件短缺」为什么做不到 Predictive 层？退而求其次的做法是什么？
4. 什么是应用地图（application map）？它能暴露哪两类问题？
5. 为什么「新增埋点」本身也是一条需求？举出本例中的一条。
6. 举出一个「不会报错、但会给出错结论」的数据问题，用本例说明。
7. 为什么必须先确定基线？本例的基线是什么？

参考答案

1. 因为访谈拿到的是自我认知，数据拿到的是实际时间分配，两者可以同时成立。它把优先级改了：按访谈只做「排期看板」，解决客服往外拨的 20%；按数据做「客户自助查进度」，解决的是一半电话量 —— 两件都做，但顺序不同（§0）。
2. 因为每一层都比上一层多一个前提：预测要求历史规律稳定、样本足够，而这依赖口径统一（描述层）和可对比维度（诊断层）。基础没打牢直接建模，模型再好也无效（§1.1）。
3. 因为数据只有 8 个月、且没有季节性记录，Predictive 的前提不成立。退法是做 diagnostic 加一条规则：「某配件连续两周出库量上升且库存低于两周用量就提醒」—— 不是预测，是规则，但现在就能做（§1.1）。
4. 应用地图把「业务目标 / 分析层次 / 所需数据」三列对应起来。它暴露两类问题：目标说不清的，以及数据拿不到的（§2.1）。
5. 因为没有这个字段，目标就无法验证。本例那条需求是「系统应记录每次客户来电的原因分类（报修/问进度/改约/投诉/其他）」，由客服挂断时选择 —— 这就是一个下拉框加一个字段，但缺了它，「把问进度来电降到 20%」永远无法度量（§2.2）。
6. 数据质量里的口径不一致。本例「白跑一趟」若没有定义（算不算客户不在家？），11% 这个数字每人数出来都不一样，而且系统不会报错（§4）。
7. 因为没有基线就无法判断改进有没有效果。本例基线是：问进度来电 50%、缺料率 11%、月报耗时 3 天（§5）。

术语表