接到一个模糊需求，数据人别急着写 SQL

做数据工作久了，你会遇到一种很熟悉的消息。

业务同事在群里说：“能不能帮我看一下最近用户流失有点高？”

这句话看起来很正常。甚至很像一个清楚的需求：用户流失，高了，需要分析。很多数据分析师看到之后，会立刻打开数据库，找用户表、订单表、活跃表，开始写 SQL。做数据开发的同学可能会去看有没有现成宽表，有没有留存指标，有没有行为明细。

但越是这种看起来简单的需求，越容易返工。

因为“用户”是谁？“流失”怎么定义？“最近”是哪段时间？“高”是和上周比，还是和去年同期比？业务想要的是一个原因分析，还是一个可以拿去开会的判断？最后要一张图、一份表，还是一句结论？

如果这些问题没有先问清楚，SQL 写得越快，返工可能越快。

模糊需求最危险的地方，是它看起来不模糊

真正难处理的需求，往往不是那种完全听不懂的。完全听不懂时，大家反而会停下来问。

危险的是半懂不懂。

“看一下流失”“分析一下转化”“拉一下 GMV”“对比一下新老用户”“看看活动效果”——这些话每个数据人都听过，也都能大概猜到要做什么。问题在于，大概猜到不等于真的对齐。

业务同事说“流失”，他脑子里可能想的是连续 30 天没下单；产品同事说“流失”，可能想的是 7 天没打开 App；运营同事说“流失”，可能想的是加入社群之后没有复购；老板说“流失”，可能只是看到收入下降，想找一个解释。

同一个词，在不同角色那里代表不同问题。

所以接到需求时，第一反应不应该是“我会不会写这个 SQL”，而应该是“这个问题现在被定义清楚了吗”。

SQL 是最后的执行动作，不是需求澄清本身。

写 SQL 前，先问五个问题

我通常建议把模糊需求先压成五个问题。

第一，分析对象是谁？

是全部用户，还是新用户？是付费用户，还是注册用户？是某个渠道来的用户，还是某个城市、某个品类、某个客户分层？对象不清楚，后面的所有口径都会漂。

第二，核心指标是什么？

“流失”要落成指标。可以是 7 日未活跃，可以是 30 日未购买，可以是会员到期未续费，也可以是连续两期没有使用某个功能。指标不落地，就无法写 SQL，也无法复盘。

第三，比较基准是什么？

“变高”一定要有参照。和上周比、和上月比、和去年同期比、和活动前比、和其他渠道比，结论可能完全不同。很多争论不是数据错了，而是大家拿不同基准在说话。

第四，业务动作是什么？

这是最容易被忽略的问题。数据分析不是为了把原因穷尽，而是为了帮助下一步动作。如果业务只是想知道“是不是渠道 A 有问题”，那你不需要展开十个维度；如果业务准备调整补贴策略，你就要把流失和补贴、价格、频次联系起来。

第五，交付形态是什么？

有时对方要的是一张临时表，有时要的是一页 PPT，有时要的是一个可复用看板，有时只是需要你在会上给一个判断。交付形态不同，投入程度也不同。

这五个问题问完，SQL 往往反而更简单。

因为你已经知道要查谁、查什么、和谁比、为什么查、查完怎么用。

不要把“问清楚”理解成推活

有些刚开始做数据工作的同学不敢问。他们担心业务觉得自己不专业，或者觉得自己在推活。

但真正专业的数据同事，不是别人说什么就立刻做什么，而是能帮对方把问题变成可以被回答的形式。

当然，问问题也有方式。

不要一上来反问：“你这个需求不清楚，流失定义是什么？”这种问法容易让对方防御。更好的方式是给选项。

比如可以说：“我先确认一下，你这里说的流失，是想看 30 天未下单用户，还是 7 天未活跃用户？如果是为了看复购问题，我建议先用 30 天未下单作为主口径。”

这句话的区别在于，你不是把问题丢回去，而是提供一个默认方案。

数据工作里的沟通，很多时候不是问“你要什么”，而是说“我理解你可能要 A 或 B，如果目标是 C，我建议先按 A 做”。

这会让对方感觉你在推进，而不是在阻塞。

口径确认要留下痕迹

另一个很实际的建议是：关键口径要留下文字。

不要只在电话里说清楚。电话里大家都觉得对齐了，过两天复盘时很容易忘。最好在群里或者文档里补一句：

“本次先按 30 天未下单定义流失用户，分析对象为 2026 年 4 月有过购买行为的普通用户，不含企业客户；对比口径为 3 月同周期；输出一页原因拆解和渠道明细表。”

这句话不复杂，但它能避免很多后续扯皮。

做数据的人最怕的不是计算复杂，而是算完之后对方说：“我不是这个意思。”

留下痕迹，不是为了免责，而是为了让协作有共同记忆。

需求澄清不是多一步，而是少走弯路

很多团队把需求澄清看成额外流程，觉得会拖慢速度。其实恰恰相反。

快，不是马上写 SQL。快，是第一次就尽量接近正确问题。

一个没有澄清的需求，可能半天能出结果，但第二天要改口径，第三天要补维度，第四天发现对象选错了。一个澄清过的需求，前面多花二十分钟，后面可能少改三轮。

我建议每个做数据分析或数据开发的人，都给自己准备一张很短的需求澄清清单。不是为了把流程搞复杂，而是为了让自己在压力下不漏关键问题。

清单可以只有六行：对象、指标、时间、对比、动作、交付。

每次接到需求，先快速过一遍。能确认的确认，不能确认的写出默认假设。只要这一步做了，后面的 SQL、看板、分析文档都会稳很多。

真正的技术能力，也包括问题定义能力

有时候我们谈数据能力，容易只谈 SQL 写得快不快，模型建得好不好，平台熟不熟。

这些当然重要。但在实际工作里，一个人能不能把模糊问题变成清楚问题，同样重要。

因为企业里的数据需求，很少天然就是干净的。它们总是带着情绪、压力、模糊目标和不完整背景来到你面前。业务说“最近不太对”，老板说“帮我看一下”，产品说“是不是这个功能有问题”。如果你只会接字面意思，就会被需求推着走。

更成熟的做法，是先把问题稳住。

问清对象，落下指标，明确边界，写出假设，再开始取数。

这不是慢。这是在保护自己的时间，也是在保护数据结论的可信度。

如果你想系统补齐需求澄清、指标口径、SQL 分析和业务沟通这几块能力，可以继续看数据从业者全栈知识库。这些内容会比单篇文章更完整地拆成工作模板和实战场景。