产品设计和研发过程中，最怕的就是需求夹杂不清，导致最后做的工作都白费了。浪费大家的时间还达不到效果。

比较典型的例子就是标题所示的段子：

产品经理：你能不能做一个右滑能出菜单，然后还需要一个闪烁的动画，这边这个tab可以拉下来，你懂了吧

程序员：别废话了，把你要抄的那个产品拿给我看一下

这个段子之所以经典，是因为：

1. 特么的现实中就是有很多这类的故事在发生着。有些甚至导致严重的冲突事件。
2. 不依常规，打脸式的解决方案一针见血，一步到位，直接搞定所有问题。
3. 解决方法不针对某个事情，无招无式，不接不架，近乎是魔法般的一句话解决所有类似问题。
4. 最关键的，这个魔法真的有效！

对于绝大部分人，尤其是程序员来说，掌握这个魔法基本就能省去很多的纷争。

但！

魔法毕竟是魔法。真的应对到千奇百怪的具体案例中，魔法也不是万能的，并不能保护你免于所有的困扰。 所以对于需求分析师来说，光有魔法是远远不够的，还需要深入掌握魔法的核心本质，从而在最合适的时机，最恰当的方式来使用他。

举例来说，比方说提出需求的是甲方的领导，对接需求的是乙方的分析师。 这个时候显然魔法需要以一种更加委婉，但是更专业，更精准的方式来表述。 如何更专业的同时又更委婉，同时还要能精准的解决问题,不掌握魔法的核心本质是不大可能的。这里面包括要扭转甲方领导的意见、看法甚至认知！

所以这个魔法的核心本质是什么呢？

首先，是需求提供方提了一个错误的需求。

但是需求本身是没有错误这一说法的，每个需求能提出来，再荒唐背后都一定有真实原因支撑。 被认为是错误的需求，基本上有如下三个可能：

1. 真实的需求是明确的，但是不能说的。
2. 真实的需求是隐藏的，无意识的，想象不到的。因此能想到的和表达出来的是需要的一个侧影。
3. 真实的需求和表述出来的需求不一致。属于有想法但不懂得正确表达的。

不能说的需求

这个需求说实话，比较有特色，真正想做事情的人不至于会到这个地步。另外，这种情况没有逻辑可言，但是对经验阅历丰富的人又很简单。 因此实际项目中处理起来，也比较简单。找市场人员一起跟进就好了。

这个与分析无关，这里就不展开了。 只需要秉记一旦遇到奇怪的不可思议的阻碍，找市场，销售等高手一起参与下就行。

自己都不知道的隐藏需求

每个人都有自己的圈子，知识的圈子，经验的圈子，去过的地方经历过的事情形成的圈子。 这些圈子实际上就是个人的认知边界。每个人都会碰到形形色色的问题，但是都只能在自己的边界内思考，并形成界限内的思维体系。

这类需求其实还比较好处理。通常多问几个为什么，追到根源，找到困难，问题，不便等等阻碍，然后根据最新的业界信息，重新定义需求即可。

比较老掉牙的例子就是“我想买一匹日行千里的宝马”， “不，你需要的是买一张高铁票。”

表述不到位的需求

这种情况其实是现实中最普遍的现象。对于普通人来说，绝大部分的人基本上都是很难准确清晰的描述出自己的需求的。最多的情况就是自认为说明白了，实际上对于和他没有完全相同的生活学习工作经历的人来说，根本就不知道他到底想表达什么。
当然这也是分析师存在的意义。 对于分析来说只需要回归到基础的需求要素既可以简单的解决。

我们常常见到争论不止的俩人互相完全不能认同。导致基本上都是在自说自话。这时如果理智一些的人，会稍微抽身一下，重新定义一下概念，也提醒对方澄清一下概念，就能起到很大的帮助理解的作用。 --- 这就是需求文档 ^[1]里最重要通常也最不起眼的 “名词定义”的部分。

所以一些高质量的争论局，我们常可以见到“请定义一下你说的XX概念”这样子的对话。

其次，是需求提供方(发起人)僭越了角色定位。或者说，职场道德越界了。

这其实是最常见的情况。甲方通常是看到了一个例子，才会想做什么事情。需求这个东西，并看不见。所以他提出来的需求，是以看到的实物为基础，然后再加上自己的理解和想法。 但这个看得见的实物，是产品的最终形态，而不是初始形态。
换而言之，看得见的，是需求+设计+研发+测试+部署+运维+营销+运作等等之后的最终结果。

而这里真正需要发起人提供的，只是需求部分。但发起人实际提出来的，却是（想象中的）整体解决方案。

所以，问题的根结就在于，提供方(发起人)提的是解决方案，而不是需求。 而解决方案，是分析师负责的部分。

这里存在的严重的角色 ^[2]错位。

想象一下，你是董事长，你找来一个分析师来做某个系统。 然后你尽力做的事情，是做分析师责任内的事情。 显然

1. 在专业上你没有分析师专业，肯定不如分析师做的好。
2. 在本职责任上，没尽到董事长的责任，项目的方向目标就很难保证了。

在这里，分析师要特别注意的事情，就是需要区分提供方(发起人)，尤其是高位的领导，提出的需求中，哪些真的是需求，哪些是解决方案。 并且需要明确的向发起人澄清解决方案的部分。

清晰的界限出提供方描述的需求和方案部分，是分析师最大的魔法

分析师最大的挑战就是识别并区分客户（或项目发起人）提出的究竟是需求，还是解决方案。这不仅需要深入理解客户的需求 ^[3]背景、业务流程和目标，还需要具备强大的沟通能力和清晰问题解决的能力。 只要熟练的掌握需求的本质和如何区分需求与方案，才能恰如其分的施展分析魔法，找到真实的有效需求。

了解需求的本质

首先，深入了解需求的本质是非常关键的步骤。需求通常指的是用户希望得到的功能或者特性，能够满足他们的特定工作或生活中的某种需求。它是一种“想要什么”的表述，可以是明确的、可测量的目标。

区分方案与需求的标志

区分需求和解决方案的关键在于识别客户（发起人）表述中是否包含了以下要素：

1. 特定功能或特性：这是需求的核心部分，通常不会包括设计、实施细节或预期的结果。
2. 目标结果：需求是关于想要达到什么结果的描述，并不一定包含具体的实现方式。
3. 限制条件和约束：需求可以提及资源限制、时间框架或其他制约因素。

交流与澄清

在项目初期，分析师应该与发起人积极沟通，明确询问以下问题以识别他们提出的是需求还是解决方案：

1. 具体功能描述：请详细描述您希望系统具备的特定功能。
2. 业务目标：此功能将如何支持您的业务目标或解决当前的问题？
3. 预期结果：如果满足了这些需求，将会带来哪些具体的改善或结果？

通过这些问题的交流和澄清，分析师可以有效地识别需求的核心内容，并避免后续可能出现的角色混淆。

通过这个过程，分析师不仅为项目提供了清晰的方向，还为后续的开发、测试和实施阶段打下了坚实的基础。这种明确的工作计划和需求管理能够确保项目的顺利进行，并有效避免资源浪费和误解。

结语

在与客户（发起人）合作的过程中，区分并处理好需求与解决方案的关系至关重要。通过深入沟通、清晰的问题定义以及建立详细的工作计划，分析师不仅能够满足客户需求，还能够在项目管理中扮演更为有效的角色，从而提高项目的成功率和效率。记住，在任何合作过程中保持耐心、细心的聆听以及对细节的关注，是成功的关键。

本文同步发表在 软件需求探索的http://www.srs.pub/case/magic-sulotion.html

1. 需求文档的编写.http://www.srs.pub/theory/xu-qiu-wen-dang-de-bian-xie.html ↩

2. 商业分析中的五十种分析方法和技巧之39-角色与权限矩阵.http://www.srs.pub/babok/juese-yu-quanxian-juzhen.html ↩

3. 客户的需求观.http://www.srs.pub/theory/ke-hu-de-xu-qiu-guan.html ↩