编辑导读：产品经理每天都在和需求打交道，每天都会遇到琐碎却又不得不解决的问题。例如，需求如何寻找，如何进行判断需求的优先顺序，如何落地等等。本文作者以B端产品为例，分析如何做好需求管理，希望对你有帮助。
作为一个产品经理，从开始接手产品工作的那一刻起，就在和各种各样的需求打交道。
打交道的过程中会遇到如下各种问题：
需求应该要从哪里去收集？各种渠道，各个相关角色会反馈给你一堆需求，这时应该如何去落地？当需求越来越多时，需要一个需求库来进行相关需求的管理，这时需求库如何做，需求库里应该要包含哪些要素会比较好？接到的需求到底该不该做，什么时间做，应该如何去判断？等等。这一系列的问题，通过做好需求管理的一套方法，将会一一得到解决。
这一套方法是什么？
我将从以下3点展开来讲：
需求全生命周期管理；需求库管理；需求取舍、优先级判断原则。
01需求全生命周期管理
关于“需求”相关的问题，我们首先要建立一个基本的认知，那就是：需求全生命周期管理。
需求不是一个零碎、单一环节的存在，它有相应的一套完整管理过程。
这一套完整的全生命周期管理，大概可以分为以下6个关键点：
需求收集；需求分析；需求确定；需求评审；需求推进；需求变更。以上6个关键点，这里我将一一拆开来详细讲讲。
第一个关键点，需求收集。
需求管理的第一步就是收集需求，没有收集到需求，何来后面的全生命周期管理。
收集需求的方法有很多，比如：
可以通过用户访谈的形式收集需求；可以通过用户调查的方式收集需求；可以通过深入一线，观察、学习的方式收集需求；可以通过会议沟通的方式来收集需求；可以通过竞品分析的方式来收集需求；等等。关于收集需求具体更详细的理解，可以参考我之前的一篇文章：《Ｂ端产品需求的3个层次，你都了解吗？》。
第二个关键点，需求分析。
通过第一阶段收集到的需求，可能会来自于不同部门、不同角色、不同颗粒度且零散的需求。这时就需要对需求进行分析。
需求分析的目的就是业务分析，也就是：
选择一种以业务为导向的方式将零散的、不同颗粒度的需求串起来，形成一个完整的、内容清晰的框架，指导后续相关的产品设计、产品开发工作。
做需求分析时，我们可以用业务流程图，业务场景，领域建模，状态图等思考模型来进行需求分析。
具体如何用这些模型来做需求分析，可以参考我之前写过的两篇文章：《Ｂ端产品如何进行业务流程的梳理与绘制？》；《Ｂ端产品如何进行业务全场景的需求梳理？》。
第三个关键点，需求确定。
对分析完成的需求，接下来就要和需求发起者进行确定，这是不是他们想要的需求。
第四个关键点，需求评审。
需求确定以后，接下来需要与技术团队评审需求，需要开发的周期、投入的人力需要多少进行沟通。
第五个关键点，需求推进。
对已经完成确定、完成评审的需求，需要进一步往下进行原型设计、UI设计、技术开发等工作的推进。
如何推进？
需求推进的过程中有哪些关键点需要注意，可以参考我之前的一篇文章：《B端产品如何做好项目管理？》。
第六个关键点，需求变更。
已评审完成的需求，在往后推进落地的过程中，可能会遇到需求变化的情况。
可能是业务方提出的需求变化，也可能是技术在开发过程中遇到了技术挑战，提出了需求变更的请求。
这时通过再次沟通、评估新的产品方案、评估新的技术方案，选择合适方案，往下进行需求落地的推进。
从需求收集到需求变更是一个完整、闭环的需求管理过程。
只有认清需求管理的全生命周期，才能管理好全生命周期中动态的变化，管理好每一个“需求管理”的节点。
02需求库管理
一家初创的企业级Saas公司，或者是一家传统企业开始开发软件来解决企业数字化转型问题的公司，刚开始需求没有多少，收集到的需求可能找个文档简单记录一下需求就可以。
随着业务的发展，需求越来越多，面对庞大的需求，这时就需要找一个合适的工具来进行需求管理。
这个工具叫做“需求库”，也有人把它称为“需求池”。
通过需求库的使用，可以把需求按照标准的方式汇集在一起，方便后面对需求的统一管理（可以在需求库里增加需求、修改需求、查看需求，对需求进行归类、优先级排序等等）。
需求库里包含的要素主要有5大类：
1.需求，包括
需求描述，提出人，提出职级，提出时间。
2.优先级
P0,P1,P2。
3.评估
产品可行性、技术可行性、投入资源、开发周期预估。
4.状态
需求确认、需求评审、产品设计、技术设计、技术开发、测试、部署上线。
5.变更情况
变更提出人、是否有技术瓶颈、产品方案是否变更，技术方案是否变更。
知道需求库里需要哪些要素之后，接下来，就要进行需求库的绘制，
需求库的绘制，可以使用Excel表格或者石墨文档来完成。
03需求取舍、优先级判断原则
文章一开始，我就提到，日常工作中，各种渠道，各个相关角色会反馈给产品经理一堆需求。
面对一堆需求，需求该不该做，需求的优先级该怎么去排列，这时，就我们就需要有一些方法或者是原则来支撑我们对需求取舍、需求优先级判断。
先聊第一个问题，需求取舍。
需求到底该不该做？
根据我的经验来看，可以有几个标准来综合判断：
1.战略方针
也可以叫产品的价值主张，知道了产品的价值主张，就能大概的知道产品的边界在哪？
属于价值主张范围内的需求，可以考虑做；不属于价值主张范围内的需求，则不应该做。
2.用户价值、商业价值组合思考
如果需求对用户价值，对公司也有商业价值，那就该做；
如果对用户有价值，对公司没有商业价值，那也可以考虑做，可能需求优先级就要排在后面；
如果对用户没有价值，不管对公司是否有商业价值，都不应该做。
3.若无必要，则不需要过度设计
我们开发软件是为了支持业务的需要，支持业务需要时可以是线上+线下来完成，如果是及其低频、线下处理比线上处理还要方便的业务需求，这时可以化繁为简，没必要线上来做。
接着聊第二个问题，需求优先级排序。
首先，对需求类型进行分类，我对所有的Ｂ端需求分为3大类:
这3类需求，
第一个最重要，排第一；
第二个，第二重要，排第二；
第三个，第三重要，排第三。
我之前在哈佛商业评论期刊上看到一篇文章，具体文章标题我已经忘了，文章中给出了Ｂ端企业顾客需求的几个维度，如下图：
这张图里面的基本价值和功能价值就是我说的业务闭环型需求；便利价值就是我说的便利性需求；个性价值和理想性价值就是我说的个性化需求。
这里我举个实际的例子。
比如，小明是某个给景区提供营销推广、SCRM的Saas服务商的一个产品经理，这家公司是一家初创企业，在做门票系统时，有以下几个需求：
添加门票编辑门票查看门票删除门票分组批量管理门票面向用户的详情页，需要有多种样式可以选择这6个需求中的1、2、3、4对应着我上面讲的闭环型需求，优先级是排第一的；
第5个需求对应着我上面提出的便利性需求，优先级排第二；
第6个需求对应着我上面提出的个性化需求，优先级排第三。
这三类需求中，不同类别中，也会存在很多需求，如何进行前后排列？
可以从以下几个维度来综合考虑：
需求强烈程度；功能的使用频次；实现成本；团队情况；企业生命周期阶段。这里还是接着举例。
比如，文章中提到的，给景区提供营销推广、SCRM的Saas系统，其中有一个需求是：
扫码授权系统可以和景区服务号绑定，这个需求首先肯定属于闭环型需求，排在第一位的，没有这个需求功能，产品闭环不了。
在第一个类别中，这个需求优先级应该如何排列呢？
我们来综合考虑一下：
需求强烈程度，程度是比较高的；功能的使用频次，频次是比较低的，一次授权，终身使用；实现成本，产品设计、技术开发上比较耗时；团队情况，初创团队，产品、技术人员较少；企业生命周期阶段，属于初期，主要要进行产品价值的验证阶段。综合评估完，短期来讲，每增加一个景区，技术手动操作，授权服务号绑定系统（这个比较简单，耗时较小），只要能解决系统绑定服务号问题就行，不一定要完整的解决方案。
完整的解决方案排在后期再去做，因此这个需求的优先级是排在后面的。
以上讲了一些方法来支撑我们对需求取舍、需求优先级判断，
不过老实来讲，需求优先级判断这事其实是没有标准答案的，
没有一种方法可以将需求划分到足够小的颗粒度来进行需求优先级判断，只要能够大概的区分出来就好。
最后，关于Ｂ端产品如何做好需求管理的问题就讲到这里了。
愿你有所收获，知道如何动态、系统的管理需求。
#专栏作家#
人人都是产品经理专栏作家。某互联网创业公司合伙人兼产品总监，多个项目“从0到1”项目负责人，擅长战略、运营、产品的整体规划及落地执行。
本文原创发布于人人都是产品经理，未经允许，禁止转载。
题图来自Unsplash,基于CC0协议。