我将不会谈马斯诺的需求理论，或者用户和场景的概念。而是借用Gerald M. Weinberg在《探索需求》这本书中提到的理论，用新的视角来看待需求。说的玄虚一些，就是讲一些关于需求的哲学和理论。

顺便提一句，Gerald M. Weinberg是软件领域最负盛名的专家之一，美国计算机名人堂代表人物。《你的灯亮着吗？》，他写的这本书在国内比较出名。

先从日本海军的故事说起

写这个故事的目的，就是想说一个常识：正确的理论，为实践指引正确的方向。但是，常识却并不常用。就拿日本海军的故事来说。

在甲午战争和日俄战争中取胜的日本海军，是当时世界上非常强大的军事组织。他们的海军战略思想，在二战初期还是一战时期的思维，用船坚巨炮打败对手。日本海军认为，只要我的炮弹比敌人打的远，我的船体经得住轰击，我就是海上的霸主。

所以，在这种思想指导下，日本海军的舰艇笨重而巨大。并且，还造出了一种超远距离攻击的鱼雷。但是，在太平洋海战的初期，这种鱼雷的命中率极低。后来，人们分析发现，这种超远距离攻击的鱼雷，导航装置根本经不住发射后的长途奔袭。也就是说，这种鱼雷打出去，能不能打中基本靠瞎猫碰死耗子了。

而美军的鱼雷艇在海战中，取得了不错的战果。因为鱼雷艇轻便而速度快，迅速靠近日军舰艇，并发射鱼雷，然后迅速离开，日本笨重的舰艇也无法追击。这样就使鱼雷的攻击效果和命中率大大的提升。

所以，对于理论的探索，是必要的。有了需求相关的理论认识，具体的工作中才会更好的实践。

需求是什么？

直接抛出答案：需求是明确的指出，我们想要的东西和我们不想要的东西。

而我们从事的互联网或者用户体验相关的工作，就是从需求的角度，在“我们想要的东西”和“我们不想要的东西”之间，画一条清晰的分界线。

然而，这只是很理想的情况。就像物理题中，光滑的平面或者没有能量损失的小滑块。关于需求，真实的情况却是如下图。

我们在探索需求时，划出的不是直线，而是波浪线。我们必定会混淆“我们想要的东西”和“我们不想要的东西”。图中绿色区域，就是我们混淆的区域。换句话说，在我们获得的需求中，“我们想要的东西”中混杂了“我们不想要的东西”，反之亦然。

而我们做需求的工作，就是不断将波浪线，不断的近似接近于那条直线。有点像数学中的概念，无限接近，近似于等于。

含混性是需求探索中永远的主题

如果爱情是文艺的永远主题，如果加速度是物理的永远主题。

那么含混性，就是探寻需求过程中的永远主题，伴随始终。那条波浪线覆盖的区域，就是含混性。

说白了，挖掘需求，就是降低需求中的含混性，将那条波浪线近似率直。

所以，在做与需求相关的工作中，要花费大量的时间在前期的需求上，降低含混性的需求。

换句话说，在需求落地成型阶段，才发现含混性，这个时候的改正成本实在是太高了。

就像那个不太好笑的笑话，一个工程队一直挖深井。工程快结束的时候，工头大叫：不好，快停工。我把施工图拿倒了，甲方要建烟囱。

含混性的来源

说到含混性的来源，这个更像是一个心理学、或者社会学的命题。比如，我们经常说到的“击鼓传花”。所以，我也只能用比较笼统的方式来说，每个人由于生活背景、知识体系或者专注能力的不同，对与事物的理解是不一致的。

比如，一个对二次元文化比较了解的人，会看懂的笑话：

小明想要撩小红。小明问小红：你周末做什么了呢？

小红说：也没做什么，就是和朋友玩滑翔。

小明：滑…翔…23333

当然，解决含混性的根本大法，就是发现问题。

什么是问题？问题是感受到事情和期望的事情之间的差别。发现问题，找到解决方案，做出决策，这是解决含混性的基本要点。

需求中的受害者

如何发现问题？或者如何问问题，这是一个庞大的体系，和用户研究的知识体系相关，就不展开了。

我更想提到的是Veblen原理。无论多坏的改变，都会有一些人收益；无论多好的改变，都会使一些人受损。在实际工作中，需求的提出者，可能是需求的受益者。但是，也要关注需求的受害者。

换句话说，尽可能考虑更多的角色，在一个需求中的谁有获利或损失，哪些人被友好的对待，哪些人被不友好的对待。当然，这有可能会有无限多的角色被考虑。所以，有些角色注定要被忽略掉。

比如，公交专用车道的设计，就要损失私家车出行，所以在设计规则时，要多角度的考虑获益和受损失的角色。

要敢于承担风险

写到这里要收一收了。前面提到含混性是探索需求的主题，是将波浪线不断趋近于直线的过程。但是这一过程，是无限的趋近。也许，探索的需求，是一个永无终点的过程。

所以，我们要适可而止。

当我们认为需求基本可以划分清楚时，应该立刻投入到具体的下一步工作。

因为，这是一条近似的直线，所以，我们要就要承担风险，去执行下一步工作。

换句话说，勇于冒险，才有可能成功。不去冒险，只是在无限趋近的道路上，议而不决。

如何降低如何降低冒险失败的风险，我将会写另一篇文章，聊一聊这个话题。

最后，总结一下，我们在探索需求时，永远要记住有含混性的存在。我们尽可能的降低含混性。

作者：wideplum，产品经理，微信公众号wideplum，分享构建知识体系和思考框架的书籍和知识！以及关于读书的一切问题！

本文由 @wideplum原创发布于人人都是产品经理 ，未经许可，禁止转载。