目录：
需求对于产品的重要性，相当于一日三餐对于人的重要性，需求是我们产品不断迭代的动力之源；本文所指需求，主要针对企业服务企业服务产品的需求，项目型需求和C端产品需求的处理会有差异，仅供大家参考。
需求的来源多样，重要性、紧迫性也不一样；如何处理好纷繁复杂的需求，对于产品发展至关重要。
如果处理不好，无法辨别出需求的范围、重要性，无法合理安排需求的优先级等，都可能将产品方向“带偏”，浪费公司资源，错失发展时机，失去产品竞争力，严重的将会将丢掉市场和客户；相反，如果能够识别关键需求、紧急需求、紧跟市场，需求处理及时得当，将有助于提高产品竞争力。
在上一篇文章中，介绍到：需求=预期-现状，这是一个简单的描述，大家对于需求有一个形象的了解。
在不同的领域，对于需求有不同的定义，在产品中，我理解需求是与具体产品有相关性的、为解决具体问题而提出的、尚未满足的要求。
需要与需求两个词语相似，词义相近，但在产品中，这两个词有比较大的差异。
需要往往为用户提出的诉求，希望满足某一个要求；而需求是与产品有相关性，并且一般为可设计、可实现的要求。
用户“需要”一般经过提炼、转化后才能成为“需求”，而有些需要受制于客观限制，是不能转化为需求的。
需求一般分为功能性需求和非功能性需求：
提到需求的层次，一般绕不开马斯洛需求理论，虽然这是基于个体的需求理论，但企业需求场景仍然具有借鉴意义；毕竟B端的产品使用对象，也是一个个鲜活的个体。
但总体上企业服务产品更多注重实用性和效率提升，对于美观性和心里满足的要求相对较弱，但这是由行业现状导致的；从长远来看，企业服务产品应吸纳借鉴C端产品设计的一些优秀特点。
企业服务产品需求有自身的特点，比如：
基于此，企业服务产品也可分为几个层面的需求：
1）业务需求
业务需求实际上为满足企业某一使用场景和目的，必须实现的功能，主要体现在满足业务规则、管理制度、业务流程等方面。
比如开具一张发票，需要有发票数据相关字段的录入功能；添加一张凭证，必须录入一些摘要、科目、借贷方等信息；再比如一些工作审批流程功能，没有流程的相关处理，就没法完成业务的流转。
2）用户需求
企业服务产品的使用对象，是一个个有情感的人，在满足业务需求后，产品是否好用，会成为评判产品优劣的重要指标。
产品页面表达是否清晰、操作是否便捷、反馈是否准确、效率能否提升，都是用户体验相关的重要因素。
我们在一些项目型需求中，经常会专注于满足业务需求；但在SaaS、PaaS等平台型产品中，仅满足于业务需求，是远远不够的；产品在具备良好的产品体验后，才会真正具备一定的市场竞争力。
3）产品需求
产品需求一般是由产品团队自发提出的，基于公司战略及产品战略，满足企业持续发展的需要，如用户中心、消息中心、订单中心、账户中心、短信服务、邮件服务、认证中心等服务建设。
解决产品发展的重复建设问题，搭建技术中台服务；满足产品生态建设，建设代理、运营管理平台，建设合作伙伴开放平台等等，都可以归类于产品需求——产品需求在一定阶段又会转化为业务需求和用户用户。
业务需求是企业服务产品的需求基石，需求功能的健全程度决定企业用户是否能够使用产品；用户需求解决企业服务产品体验的问题，是企业服务产品具备竞争力的主要产品因素，满足用户更好的使用产品的诉求；产品需求基于集团战略及产品战略的规划而提出，为企业服务产品的可持续发展及最终成功提供产品支持。
需求调研有多种方式，有行业调研、用户访谈、需求沟通会等等，其中：
需求调研的方式多样，在产品的不同阶段、产品所在的不同行业、不同场景，需要选择不同的调研方式；需求调研的每一种方式方法，都可以作为专题来研究。
1）测试反馈
测试人员在测试系统的过程中，实际是在模拟用户的操作；在这个过程中，可以发现一些系统问题，提出比较好的需求建议，特别是用户体验相关的建议。
2）客户反馈
实际用户在使用过程中，会发现一些系统提供的功能同实际操作需要之间不匹配的一些功能点，如果沟通渠道通畅，也会收集到一些用户反馈的需求。
3）运营反馈
在一些有运营支撑部门的公司，运营团队会代表用户向产品团队提出使用反馈的需求，以帮助产品改进。
用户反馈和需求调研的差异，主要在于是主动还是被动的收集需求。
公司会根据发展需要，推出一些新的发展方向或者提出新的产品方向，对这些公司战略的分解与分析，形成产品需求。
公司战略形成的需求，有些可能不是真实的用户需求，有些是在创造用户需求，这些都需要产品同学花费更多的精力去研究，对产品有更好的预判能力，避免产品掉入“伪创新”的泥坑。
产品同学可基于对行业的理解、用户的研究，规划产品设计，对产品进行优化迭代；产品研究一般更侧重产品宏观发展和产品内在管理逻辑的实现。
在一些国家监管或者存在行业管理标准的行业中，企业服务产品需要满足国家的政策、文件及行业标准的要求，为此需要设计相关的功能、流程、管理机制，确保产品本身合法规范。
此类需求，需要产品同学或者公司反馈机制，去查找相关的政策、文件、标准，并确保产品及时更新，在要求的时限内完成或尽快完成产品改造，满足监管要求。
通过多种渠道获取需求后，一定要对需求进行记录，我总结需求记录一般遵循以下原则：
需求来源可追溯：一般需要对需求来源记录清楚，当有些需求问题存在不确定性或需要对异常流程进行补充处理时，可以再次进行沟通。
需求场景可还原：需求记录要能够清晰的描述用户实际场景需要，看到需求记录的相关描述，要能够明白用户的实际需要是什么，尽量不要产生歧义，避免难以理解的需求记录。
需求分析可实现：需求记录的问题，应该是经过一定的过滤，比如重复问题、与系统无关的问题等，这些问题需要在更靠前的环节解决掉，需求记录的问题应该是可实现或理论可实现的需求。
需求推进可持续：有时会存在需求后续推进过程中，提需求的人，我们已经找不到或者无法确认，这种情况时有发生。一个后续无法获取反馈的需求，上线后无人使用，会浪费团队大量的精力，我们在需求收集阶段，就需要开始辨别此类风险。
需求采集表一般需要体现出如下信息，比如需求来源（比如客户、企业员工等）、提出人、提交时间、企业客户名称、客户联系人、客户联系方式、需求描述、涉及系统、功能节点等，也可以根据产品的实际情况，调整需求记录的项目。
做需求管理时，我们需要先弄清楚几个问题，这个需求是否为个性化需求？覆盖的用户范围有多大？带来的价值有多高？紧迫度有多高？如果对需求工作量有一定的判断经验，可以初步评估实现的难易度和工作量。
需求影响力：指需求能够影响的用户范围，对用户影响范围越大，得分需要越高，反之越低；例如分值可以为5、4、3、2、1、0，其中5代表最大范围，0代表无影响范围。
需求复杂度：评估需求影响产品范围,可通过数值来标识，可以通过判断影响功能范围、复杂度高低，进行评分，用于评估后续的实现难易程度；影响功能范围越大，复杂度越高，实现难易度就越困难，反之越容易，可用数值进行标识；例如分值可以为5、4、3、2、1，其中5代表实现最简单，1代表实现最复杂。
需求紧急度：可跟提交需求的伙伴沟通优先级，了解紧急程序，也需要根据产品同学的经验进行判断，对于业务需求、阻断流程需求、政策性需求，可给与较高的紧急程度；例如分值可以设定为5、4、3、2、1,5代表最紧急、1代表不紧急。
需求价值：需求价值可区分为经济价值和产品价值（没有想到特别好的命名）。
需求经济价值是指这个需求的满足，是否能够直接带来经济价值，在企业服务SaaS产品中，会有客户愿意为某一定制化功能买单；对于SaaS产品来说，需要慎重评估经济价值和需求影响力之间的关系；例如分值可以设定为5、4、3、2、1进行评估。
需求产品价值：可通过典型的KANO模型进行分类，KANO模型将需求分为五类。
KANO模型经常用于C端产品需求分类的工具，关于KANO模型的应用，可以参考《善用KANO模型，做需求分类与评估优先级》，辛小仲老师对于KANO模型的理论和实操做了非常详细的讲解，可以通过需求调研问卷的形式获得相对准确的KANO分类，再通过Better-Worse系数确定落入的象限范围，判断需求优先级。
一般来说，可以分别使用3、2、1、-1、-2来分别代表必备需求、期望需求、魅力需求、无差异需求、反向需求。
需求价值可以通过需求经济价值+需求产品价值来表达。
处理需求的过程中，很重要的事情就是确定需求优先级，优先级的确定可以参考使用ICE方法。
ICE是将需求分为影响范围、自信程度、实现难易3个层面进行评估：
在上个章节中，我们将需求进行分类打标签，我们对需求分类标签的目的，是希望通过对需求进行客观的分析，以数值的方式记录评估；然后对需求的总得分比较排序，尽量避免用拍脑袋的方式定义分值，让使用ICE方法时更加合理。
最终将每个需求的ICE三个分值相加，根据得分顺序，排列需求优先级。
对于每一个需求的归类和分值定义，可以在实际的操作过程中进行调整，摸索出一套适合自己产品的方法。我们在对外沟通的过程中，也可以将确定优先级的方法作为一套标准，争取各环节共识，各环节能够理解并达成一致后，有助于产品推进。
需求变更是难以避免的。
有人说唯一不变的就是变——我深以为然，变更对于产品来说可能是好事也可能是坏事，所以我们需要做好需求变更的控制——对需求变更的管理，不是为了杜绝变更，而是降低需求变更对产品的负面影响，让产品向更好的方向发展。
在PMP的知识体系中，对于需求变更非常重视，在传统的瀑布式项目开发过程中，需求变更意味着项目计划的调整、资源投入的调整，实际情况是大多数情况都会导致项目进度延期或者增加资源投入。
在产品迭代（常采用敏捷开发的方式）过程中，我们对于需求变更的控制力度或流程管控力度有所降低，迭代开发模式追求快速上线、快速试错、快速调整，本身也容易导致需求变更的发生。
前期需求不够明确：我们在一些产品早期或者功能早期建设过程中，有时会缺少参照，需要进行一些产品创新；此时对于需求的评估还不够精准，用户研究也不够透彻，上线往往需要根据用户反馈调整产品设计。
业务场景不够了解：我们在分析客户的使用场景的过程中，由于自身专业知识水平和行业经验的限制，对业务的使用场景不够了解；对用户的需求描述，仅看到表面问题，没有分析到本质问题，设计出来的产品，往往不能满足客户的真实完整需要。
业务形态发生变化：当公司的商业形态或者业务运营逻辑发生变化时，我们也需要根据情况进行调整；这类问题在业务主导型公司经常发生，产品团队作为提供服务方，往往会比较被动。
在管理的过程中，我们需要根据造成需求变更的原因，有针对性的进行管理，在有些产品中，多种情况可能会同时出现。
对于需求不够明确的情况，我们需要控制需求量，避免一次投入过多的工作量，采用小步快跑的模式，减少资源的浪费。
因为业务场景了解不够导致的需求变更问题，在设计产品前，需要产品人员多方面、深入、客观的了解业务需求，增强自身对业务场景的认知，了解需求的真正痛点，不要浮于表面。产品设计过程中，多考虑新需求的相关性，有助于发现更多的场景问题；在产品评审时，需要仔细跟用户讨论确认（有条件的情况下），让用户帮助评估是否符合业务场景，对于客户的疑虑或不解，多追问、多了解。
当业务形态发生变化时，需要评估影响范围和紧迫度，比如公司战略调整，就需要尽快全面响应需求变更。
当业务管理部门的频繁变动或业务规则频繁调整时，我们需要适当降低需求的优先级；在设计产品的过程中，针对这类频繁变更的需求，产品同学需要注意总结需求变更前后的特点，找到规则，通过可配置的产品设计实现需求，让用户自行配置，保持产品功能的灵活性，减少需求的变更。
在实际的需求管理过程中，需求变更的原因是比较复杂的，有产品自身的原因、有业务的原因、公司管理的问题；我们需要根据具体情况具体分析，当遇到较大的需求变更风险时，应及时反馈到上级。
在产品迭代过程中，变更的需求往往被作为新需求进行处理，这是目前一些公司的现状，产品同学可根据自己所在公司的情况，选择需求变更的控制流程。
但总体来说，遇到需求变更时，需要提升对变更需求的风险关注度。
我们可以总结出相对通用的需求变更控制流程，作为参考：
我们在确定大致的需求优先级后，根据项目团队的初步评估，确定上线周期，及时同各方做好需求的反馈工作。
新产品和处于迭代中的产品，在处理需求的过程中，会有一些差异。
新产品一般需要经过立项过程，其需求来源相对简单，沟通反馈过程也相对简单；而迭代中的产品，可能会出现部分需求重要但没有马上给出排期计划的情况，需要分别对待。
一般在沟通需求反馈时，需要对需求受理状态、解决方案、解决时间等给出响应。
在需求管理完成后，后续还有很多工作需要处理，比如产品设计、产品评审、UI设计评审、研发过程跟进、配合测试评审、产品验收、产品发布、收集反馈意见等，这些内容我们会在后续章节继续探讨。
既然来了，说些什么？