我们在使用手机上的C端APP时，很多APP在第一次使用时除了知道它的产品分类外，对它具体的功能一般知之甚少，然后在使用过程中会不断探索它的玩法和价值。
但是这种情况在B端产品中是不存在的，因为一个B端产品在设计好之后其所有功能都要用标准参数一条一条列在合同里。即客户在上线我们产品时，对我们产品所具备的功能是心中有丘壑的，这也是B端产品的商业性质决定的。
这篇文章我就按照B端产品的招标参数和合同里的参数对需求进行分类，并结合KANO模型，方便大家更好的理解B端产品的需求。
以我们公司产品为例，我们在审核招标参数和合同时，会将参数需求分为以下四种：
与KANO模型对应关系如下：
先说标准版参数与基本需求，B端产品标准版参数基本是业务的主流程，要能满足用户的核心需求。
比如我们公司的手术室麻醉信息管理系统，最基本的需求就是要能满足麻醉医生术前访视、手术排程、术中麻醉记录、术后苏醒记录、术后访视的记录。
这个领域所有软件的标准版参数最基本的要求就是满足这个基本流程的信息化，且大部分厂商的这一部分功能差异不会太大。这也是我们在入职这个行业之后，需要第一时间熟悉的主业务流程。
再说魅力需求，因为通常大部分客户购买的都是我们的标准版参数产品，所以既然各厂商的基本需求都能满足的时候，我们就要在基本需求上做魅力需求来吸引客户注意力，提高客户满意度了。
比如针对产品的手术排程功能，除了提供基础的通过拖拽形式的便捷排程，在此之上我们设计了智能排程的功能，将麻醉医生排程的效率提高三倍以上。
并且针对B端产品大多重业务逻辑，不重用户体验的现状，我们将产品的用户体验从页面展现上做了很大的提升。以至于我们给客户展示产品demo时，客户都会下意识的说一句“你们的界面看着还是蛮舒服的。”
这些需求魅力型的需求，从业务流程上来说没有必要，不做也不会降低客户对我们产品的满意度，但是做上之后一定是能提升客户的满意度。各个公司设计的魅力需求根据每个公司的实际运营情况不尽相同，这就要由客户来决定哪些是让他更满意的需求了。
二、高级版参数——期望需求
有些客户希望我们除了满足核心的麻醉业务流程外，还能针对围手术期更大程度的进行信息化管理，并根据信息化的管理实现数字化各种业务的统计，甚至能覆盖部分手术护士与麻醉医生合作的相关工作内容。
当行业内较多客户都拥有这些期望需求时，我们就会将其放到高级版的产品参数中，由用户选择性进行购买。避免为部分用户上线多余功能也避免部分用户想用而我们又不能满足的情况。
比如麻醉计费功能，通常在医院是由麻醉医生开具处方单，然后由护士统一的录入到HIS（医院信息系统）中。这中间就会有一个由护士进行信息转递的过程，客户就希望能够优化掉这个流程，让麻醉医生能够通过我们的系统直接进行麻醉项目的计费，然后将计费结果通过接口发送到HIS中，避免人为的信息转递失误。
所以我们的高级版参数就会设计这些较多客户都会提出的超过基本需求之上的期望型需求。
三、定制参数——期望需求
上面第二点中的高级版参数我们提到它要满足一个条件，就是较多客户都有这种期望需求。
而还有一些少数客户也会针对他们医院的实际部分特殊业务场景提出一些期望需求。这些期望需求通常只是为了满足某个客户的现场情况，我们就会与医院商定好需定制的需求功能，专门为其设计研发。
比如我们有一个客户提出，有些情况下病人在做完手术后可能会进行非计划的二次手术，但是他们不希望重新开启一台手术记录，要求我们能够支持这种特殊情况下打破原有手术流程的设计。
这个改动不仅仅影响的是手术中的记录，所有跟患者信息相关的记录都会被这些手术流程的关键节点所影响，属于比较复杂的需求。
但是鉴于这个客户在某个区域还是比较有影响力，对我们的产品口碑可能会产生影响，我们将这个需求纳入到了定制需求中，为其设计和研发了满足其要求的手术流程。
所以我们的定制参数是为了满足少量重要客户提出的超过基本需求之上的期望型需求。
首先说无差异需求，无差异需求就是指做了和没做对产品和客户的业务而言都没有什么影响，这种需求通常考虑到成本等原因不会进行响应。
比如有的客户会提到，是否能把手术室的人员值班做到麻醉信息系统中，这个需求与麻醉医生的业务是毫不相关的，可能只是手术室的管理者想借着手术室中现有的信息系统顺便给放进去算了，所以这种需求我们的产品不会对其进行响应。
然后是反向需求，这个就需要很仔细的进行甄别了。因为从客户的角度来看他们不可能去提一个影响他们体验的需求，我们也不可能去提一个对产品有负面影响的需求。那么反向需求是怎么来的呢？
反向需求通常是隐藏在客户的期望需求中，客户为了解决他的一个问题提出一个需求，但是这个需求不一定能很好的解决问题，甚至会为产品带来更多的问题。
这就要求我们在评估客户需求的时候一定要多问几个为什么来避免这类需求的产生，比如客户为什么提出这个需求？他想解决什么问题？有其他更好的实现方式吗?这个需求会带来什么延伸问题？
五、总结
上述就是我基于我们公司从参数的角度对产品需求进行的分类，通常在现实中一个需求划分到哪个类别中还会有更复杂的考量，比如客户的影响力、需求的成本等等，这些我们有机会在探讨。
