定义需求

地图不是疆域

这两年我越来越觉得，“定义需求”这四个字，比“解决需求”难得多。解决一个已经定义清楚的需求，是个技术活，努努力，方法总是有的。但如果一开始就定义错了，后面再怎么努力，也是在错的方向上使劲，跑得越快，错得越远。

先说一个容易被忽略的事实：我们写在文档里的那句“用户需求是……”，从来都不是需求本身，只是我们对需求的一张地图。地图这个东西，画得再仔细，也只是某一个时刻、某一个人对疆域的理解，不是疆域本身。疆域一直在变，用户的处境、心情、身边的选择都在变，你上个月画的那张地图，这个月可能就已经过时了。

更麻烦的是，画地图的人是有偏见的。你去做一次用户访谈，你问出来的问题、你听到的答案、你最后写下来的结论，都掺杂着你自己的经验和预设。你以为自己在客观记录，其实你从提问的那一刻起，就已经在按自己的理解裁剪现实了。所以我现在看需求文档，习惯先问自己一句：这是疆域，还是我画的地图？

必要不等于充分

第二个容易踩的坑，是把“用户说的话”直接当成“用户的需求”。用户会告诉你他想要一匹更快的马，这句话是真的，但它只是一个必要条件，不是充分条件。你真去给他配了一匹更快的马，他可能还是不满意，因为他真正要的是更快到达目的地，马只是他能想到的、也是他知识范围内唯一的解法。

必要性和充分性这两件事，我们太容易混着用了。用户提的这个功能，也许确实是解决问题的必要一环，但满足了它，未必就充分解决了问题。定义需求的时候，多问一句“这是必要的，还是充分的”，能省下很多后面返工的功夫。

相关不等于因果

再往深一层，是因果和相关的问题。你看到某个功能上线以后，某个指标涨了，很容易得出“是这个功能带来了增长”的结论。但世界上大多数你观察到的关系，都只是相关，不是因果。可能同时还有别的事情在发生，恰好也在往好的方向推。

定义需求如果建立在一次巧合的相关关系上，那这个需求本身可能压根不成立，你只是在追逐一个幻觉。我自己现在的习惯是，看到一个漂亮的相关关系，先高兴三分钟，然后花更多时间去想，这中间是不是还藏着别的变量。

不断往回问“为什么”

那到底该怎么定义需求呢？我觉得第一性原理这个东西，虽然听起来很大，用起来其实很朴素，就是不断往回问一句“为什么”。用户为什么会这么说，这么说背后他到底想解决什么，如果没有现在这些工具和习惯的束缚，他真正想要的状态是什么样。这几个“为什么”问下去，很多表面上的需求会自己散掉，露出后面那个更本质、也往往更简单的东西。

这里又能用上奥卡姆剃刀：如果一个需求，你需要编织很多个假设才能自圆其说，而另一个解释只需要一两个假设就说得通，那大概率是后者更接近真相。复杂的需求描述，很多时候只是我们自己没想清楚的遮羞布。

看清自己的能力圈

但往回问“为什么”这件事，也不是谁都能问到点子上的。这就牵扯到能力圈了。在自己熟悉的领域里，你能很快分辨出用户说的哪句话是真需求，哪句话是随口一提，因为你早就见过类似的场景，知道该往哪个方向深挖。

可一旦跑到自己不熟的领域，同样一套提问方法，效果会差很多，因为你连该问什么都不知道。这时候诚实地承认自己是“陌生人”，去找真正懂这个领域的人聊，哪怕只是花点时间做点功课、想清楚该问哪些问题，都比自己关起门来瞎猜要可靠得多。定义需求做得好不好，很大程度上取决于你有没有搞清楚，这次自己是站在能力圈里面，还是外面。

从一阶看到二阶

还有一件事我以前经常忽略，就是只盯着眼前这一步。用户提出一个需求，你满足了，第一时间他很满意，这是一阶效应。但这个需求满足以后，会不会带来别的连锁反应，会不会让别的用户、别的场景变得更麻烦，半年以后回头看，这个选择到底是不是划算的——这些是二阶效应，往往才是真正决定一个需求值不值得做的东西。

定义需求如果只看第一层反馈，很容易被一时的掌声骗过去。

从反面定义边界

有时候，正着想想不明白的问题，反过来想反而清楚。与其苦苦追问“用户到底想要什么”，不如换个角度问“什么样的结果是我们必须避免的”。把不能接受的结果一条条列出来，剩下的空间，往往就是需求真正的边界所在。

这种逆向的定义方式，尤其在需求本身很模糊、正面描述怎么说都不对的时候，反而更容易先站稳脚跟。

让地图持续更新

最后我想说的是，定义需求这件事，本身就该带着一点谦卑，而不是一次性把它做“对”。你画的地图会过时，你的判断会有偏见，你今天笃定的因果关系，明天可能就被证明只是巧合。

比较靠谱的态度，是把它当成一个不断用新信息修正旧判断的过程——这次访谈到的东西，跟上次比、跟你原来的假设比，是不是让你对这个需求的理解往前挪了一点。每一次新信息进来，都在原来的判断基础上更新一点点，而不是全部推倒重来，也不是完全无视。