做数据工作久了，你会遇到一种很熟悉的消息。
业务同事在群里说：“能不能帮我看一下最近用户流失有点高？”
这句话看起来很正常。甚至很像一个清楚的需求：用户流失，高了，需要分析。很多数据分析师看到之后，会立刻打开数据库，找用户表、订单表、活跃表，开始写 SQL。做数据开发的同学可能会去看有没有现成宽表，有没有留存指标，有没有行为明细。
但越是这种看起来简单的需求，越容易返工。
因为“用户”是谁？“流失”怎么定义？“最近”是哪段时间？“高”是和上周比，还是和去年同期比？业务想要的是一个原因分析，还是一个可以拿去开会的判断？最后要一张图、一份表，还是一句结论？
如果这些问题没有先问清楚，SQL 写得越快，返工可能越快。
模糊需求最危险的地方，是它看起来不模糊
真正难处理的需求，往往不是那种完全听不懂的。完全听不懂时，大家反而会停下来问。
危险的是半懂不懂。
“看一下流失”“分析一下转化”“拉一下 GMV”“对比一下新老用户”“看看活动效果”——这些话每个数据人都听过，也都能大概猜到要做什么。问题在于，大概猜到不等于真的对齐。
业务同事说“流失”，他脑子里可能想的是连续 30 天没下单；产品同事说“流失”，可能想的是 7 天没打开 App；运营同事说“流失”，可能想的是加入社群之后没有复购；老板说“流失”，可能只是看到收入下降，想找一个解释。
同一个词，在不同角色那里代表不同问题。
所以接到需求时，第一反应不应该是“我会不会写这个 SQL”，而应该是“这个问题现在被定义清楚了吗”。
SQL 是最后的执行动作，不是需求澄清本身。
写 SQL 前，先问五个问题
我通常建议把模糊需求先压成五个问题。
