本文深入探讨了如何为TOB系统产品提出有效的需求，分享了在需求收集和分析过程中的关键步骤和注意事项，希望对你在产品管理和需求工程方面提供实用的指导。

在TO B的产品工作中，最重要的一个需求来源就是实施交付的项目。

实施交付项目上的需求是最能够代表真实用户心声，最后能够体现系统在业务中的价值。

但是，往往在需求收集和传递的过程中，最重要的、最有价值的信息被损失掉了，项目过多、客户过多的时候，特别是SaaS系统，产品经理不可能每个项目都和客户直接进行沟通，必须要面对二手需求。

为了避免在传递的过程中损失太多信息，特意编写此文档说明如何对提TO B系统产品提出好的需求。

一、需求模板规范

首先，给出一个需求模板：

二、什么是需求

2.1 需求的定义

在经济学中对需求的定义：需求是人们在某一特定的时期内、在各种可能的价格下、为了达到某种目标，愿意并且能够购买某个具体商品的需要。这里面涉及到四个关键词：

1. 人
2. 场景（在某个特定的时期）
3. 问题（为了达到目标）
4. 购买能力（愿意并且能够购买）

在To B系统的场景下，需要强调的两个词的差异，业务需求和功能需求，这是两个完全不同的概念：

1. 业务需求才是我们说的真正的需求，是需要解决的问题，是需求挖掘和需求分析的产出
2. 功能需求是对系统某个具体能力的描述，一般是产品设计的产出

2.2 需求的构成是什么

需求的4个关键词也就组成了需求的4个要素，缺一不可

2.2.1 人

人是需求的中心，全部都是围绕人来说的，也就是用户；在需求的语境下，用户不是自然人，而是一种角色。例如：只有在爸爸的角色下，一位30谁的男士才会有尿不湿的需求，没有角色的背景，这个爸爸就不会有需求。

PS.其实我们都是带着角色的面具而生活。

2.2.2 场景

场景是为了更好的理解需求，同样的需要，在不同的场景下就变成了不同的需求，脱离了实际场景的需求就是无源之水、无本之木。例如：一个人打车，在这个人要上班和要下班的场景下，需求将会有明显的变化，上班的核心是时间，其他占比小，下班要综合考虑事件、价格、舒适度、路线等等。因此，虽然有些需求看起来好像很相似，但是在不同的场景下需求的差异是非常大的。

2.2.3 问题

问题是对现状和理想差距的刻画，是需求的核心部分。问题的描述包括现状是什么样的，目前的解决方案是什么，和理想的差距是什么。这里尤为重要的现状，现状也就是目前的解决方案，不仅仅是狭义的解决方案，而是包括了对需求的深入洞察，解决方案是建立在对需求的深入理解后的产物，要多问几个为什么，最终的目的是什么。

2.2.4 购买能力

需求是建立在交易的基础上的，没有交易需求就永远无法被满足，有交易就会有价值交换，也就是购买能力；客户为了这个需求愿意付出的价值也侧面体现了这个需求的重要程度。购买能力不仅仅指经济成本，也包括时间成本、信用成本、机会成本等。例如客户愿意直接支付的人天、是不是愿意等待、还是愿意拿这个来卡主验收甚至是替换供应商（卡验收和替换供应商其实客户也要付出很多代价）。

2.3 需求洞察，揭开需求的面纱

在“问题”部分，提到了需求的洞察，这是非常有意思、非常开放且知易行难的一点，因此，我们在花一个小节对这一点再进行单独的阐述。需求洞察是建立在对整体业务逻辑和业务结构的深刻理解之上的，对业务逻辑和业务结构不理解，就犹如盲人摸象、坐井观天，永远无法跳出到更高的高度解决问题，陷入解决问题的细枝末节，越陷越深，很可能会带来无法解决的困难，最终也无法很好的解决问题。

什么是业务的逻辑和业务结构？举一个新能源汽车行业的很简单的例子来说明，如下图：无论是什么需求其实都是在解决最终的整体经营利润的问题，遇到的实际问题可能是某个分支上的问题，如果能解决高位的的问题，那么分支上的问题也就不是问题了。

明确需求洞察最重要的手段就是多问几个为什么？一直问、一直问、一直问……业务的最终目标是什么？如何反映下指标上？为什么要这样不是那样？为什么数据不能多一点？…… 当然，如果一直问下去肯定会落在人性的“贪嗔痴慢疑”，这就问的太深，不是TOB系统语境下关注的。

因此，需要先了解业务结构，了解了业务结构就知道了业务边界，讨论范围不能出了业务边界。根据经验，一般情况，根据问题所在的位置向上问2-3层即可，当然可能有时候向上求几层也无法绕开问题，那就是确实只有一条路了，但是这个过程可以让我们对需求的理解更加透彻。综上，在理解业务框架的前提下多问几个为什么，深刻理解真正目的，明确差距，切实为客户带来业务价值。

三、提需求的误区

3.1 拒绝功能描述，拒绝不求甚解

汽车大王亨利·福特的名言：“如果当初我问客户想要什么，他们一定会告诉我，想要一匹更快的马”。一匹更快的马就是功能描素，从A点到B点，更快的到达，更舒适的到达，更低成本的到达，才是需求。我们与客户沟通时，大多数的情况，客户不会把最真实的需求直接呈现给我们，而客户往往喜欢直接给出一个方案或功能点的需求，特别是对于有产品或技术背景的客户，这种情况尤甚。

这样的需求非常具有迷惑性，看起来是非常明确、非常具体，各种逻辑也非常清楚，而实际上，这种需求大部分是功能描述（功能需求），并非业务需求。在这种情况下，加之人性的懒惰，很容易就把功能描述当成了需求进行处理，这会导致：

• 失去了对真实业务的理解，失去了从其他角度解决问题的可能性
• 长此以往只会被需求的提出者牵着鼻子走，失去了自己的节奏
• 需求的处理人、产品的设计者沦为功能点设计的机器人，丧失了全局的视角

之所以出现这种情况，是因为每个人的知识背景、逻辑结构、过往经历、看过的书、见过的人都是不同的。

每个人对事物的认知存在一定的差异，客户提出的解决方案是在他的认知下的解决方案。这种解决方案并不是经过论证分析的、最合适的、可落地的；大多数情况下都不是最佳解决方案，且很难实现。我们不能直接认为客户的表述就是需求，然后就开始聚焦在这些语言上进行解决方案的探索如果这样，那就是一叶障目，失去了发现语言背后隐藏的真实需求的机会。

总而言之，遇到这样的情况，我们要多一层思考对方到底想解决什么问题，这也是本文一直强调的“需求洞察”，通过多轮有意义沟通，与客户沟通需求，在沟通过程中不断挖掘客户的真正需求，揭开需求的面纱。

3.2 拒绝空对空，拒绝一句话的需求

一句话能说清楚需求吗？能、也不能。之所以说能，是因为对话的双方对某个具体的事物拥有相同的认知，这这种情况下，即使通过几个简单的词汇也能相互理解具体的需求当时大多数情况，我们与客户，我们内部的不同部门之间是很难建立高度相同的认知的，之所以无法建立：

• 我们与客户的认知不同，这很好理解
• 内部的各个部门的信息很难在一开始就完全互通的，客户的业务情况、项目的特点、客户的调性……是非对客部门无法完全知晓的

在无法建立相同认知的前提下，贸然的通过一句话来完成需求的传递是有风险的，这会造成鸡同鸭讲的情况出现，客户和项目说的不完全理解，项目和非对客部门说的也不理解，最终做出来的功能无法切实解决客户问题，赔了夫人又折兵。

在这样的情况下，一定要通过详细的需求描述和分析文档进行沟通。需求的提出方尽量按照需求的4个要素说清楚需求，非对客部门也要再编写需求分析文档，强化对需求的理解，和项目同学对齐。借用技术的语言来说，至少要做到三次握手，意思就是项目上的同事对需求描述一遍，其他部门的同事复述一遍，项目的同事再确认一遍。

总而言之，遇到这样的情况，我们要多通过《需求文档》和《需求分析文档》确保对需求的理解深刻且一致。

3.3 拒绝经验主义，拒绝先入为主

经验是个好东西，经验可以提升效率，少走弯路。但是如果犯了经验主义错误，无意识地使用理性,却拒斥理性的使用，那么就会增加失败的风险。需求的传递和说明也是这样，刚开始说就以为自以为自己理解了，不在进行深入了解了，或者简单几句话的说明，就以为其他人都应该明白了，这样很有可能会造成需求理解的偏差，而且这种偏差一般都不小。

为了避免经验注意，我们要时刻保持谦虚的态度，保持对需求的敬畏之心，不要有刻板印象，过早的下结论，该有的沟通和分析流程都应该有。

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

题图来自 Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。