新媒易动态
NEWS CENTER
NEWS CENTER
2021-03-28
作为一个产品经理，从开始接手产品工作的那一刻起，就在和各种各样的需求打交道。
打交道的过程中会遇到如下各种问题：
这一系列的问题，通过做好需求管理的一套方法，将会一一得到解决。
这一套方法是什么？
我将从以下3点展开来讲：
关于“需求”相关的问题，我们首先要建立一个基本的认知，那就是：需求全生命周期管理。
需求不是一个零碎、单一环节的存在，它有相应的一套完整管理过程。
这一套完整的全生命周期管理，大概可以分为以下6个关键点：
以上6个关键点，这里我将一一拆开来详细讲讲。
第一个关键点，需求收集。
需求管理的第一步就是收集需求，没有收集到需求，何来后面的全生命周期管理。
收集需求的方法有很多，比如：
关于收集需求具体更详细的理解，可以参考我之前的一篇文章：《Ｂ端产品需求的3个层次，你都了解吗？》。
第二个关键点，需求分析。
通过第一阶段收集到的需求，可能会来自于不同部门、不同角色、不同颗粒度且零散的需求。这时就需要对需求进行分析。
需求分析的目的就是业务分析，也就是：
选择一种以业务为导向的方式将零散的、不同颗粒度的需求串起来，形成一个完整的、内容清晰的框架，指导后续相关的产品设计 、产品开发工作。
做需求分析时，我们可以用业务流程图，业务场景，领域建模，状态图等思考模型来进行需求分析。
具体如何用这些模型来做需求分析，可以参考我之前写过的两篇文章：《Ｂ端产品如何进行业务流程的梳理与绘制？》；《Ｂ端产品如何进行业务全场景的需求梳理？》。
第三个关键点，需求确定。
对分析完成的需求，接下来就要和需求发起者进行确定，这是不是他们想要的需求。
第四个关键点，需求评审。
需求确定以后，接下来需要与技术团队评审需求，需要开发的周期、投入的人力需要多少进行沟通。
第五个关键点，需求推进。
对已经完成确定、完成评审的需求，需要进一步往下进行原型设计、UI设计、技术开发等工作的推进。
如何推进？
需求推进的过程中有哪些关键点需要注意，可以参考我之前的一篇文章：《B端产品如何做好项目管理？》。
第六个关键点，需求变更。
已评审完成的需求，在往后推进落地的过程中，可能会遇到需求变化的情况。
可能是业务方提出的需求变化，也可能是技术在开发过程中遇到了技术挑战，提出了需求变更的请求。
这时通过再次沟通、评估新的产品方案、评估新的技术方案，选择合适方案，往下进行需求落地的推进。
从需求收集到需求变更是一个完整、闭环的需求管理过程。
只有认清需求管理的全生命周期，才能管理好全生命周期中动态的变化，管理好每一个“需求管理”的节点。
一家初创的企业级Saas公司，或者是一家传统企业开始开发软件来解决企业数字化转型问题的公司，刚开始需求没有多少，收集到的需求可能找个文档简单记录一下需求就可以。
随着业务的发展，需求越来越多，面对庞大的需求，这时就需要找一个合适的工具来进行需求管理。
这个工具叫做“需求库”，也有人把它称为“需求池”。
通过需求库的使用，可以把需求按照标准的方式汇集在一起，方便后面对需求的统一管理（可以在需求库里增加需求、修改需求、查看需求，对需求进行归类、优先级排序等等）。
需求库里包含的要素主要有5大类：
1.需求，包括
需求描述，提出人，提出职级，提出时间。
2.优先级
P0,P1,P2。
3.评估
产品可行性、技术可行性、投入资源、开发周期预估。
4.状态
需求确认、需求评审、产品设计、技术设计、技术开发、测试、部署上线。
5.变更情况
变更提出人、是否有技术瓶颈、产品方案是否变更，技术方案是否变更。
知道需求库里需要哪些要素之后，接下来，就要进行需求库的绘制，
需求库的绘制，可以使用Excel表格或者石墨文档来完成。
文章一开始，我就提到，日常工作中，各种渠道，各个相关角色会反馈给产品经理一堆需求。
面对一堆需求，需求该不该做，需求的优先级该怎么去排列，这时，就我们就需要有一些方法或者是原则来支撑我们对需求取舍、需求优先级判断。
先聊第一个问题，需求取舍。
需求到底该不该做？
根据我的经验来看，可以有几个标准来综合判断：
1.战略方针
也可以叫产品的价值主张，知道了产品的价值主张，就能大概的知道产品的边界在哪？
属于价值主张范围内的需求，可以考虑做；不属于价值主张范围内的需求，则不应该做。
2.用户价值、商业价值组合思考
如果需求对用户价值，对公司也有商业价值，那就该做；
如果对用户有价值，对公司没有商业价值，那也可以考虑做，可能需求优先级就要排在后面；
如果对用户没有价值，不管对公司是否有商业价值，都不应该做。
3.若无必要，则不需要过度设计
我们开发软件是为了支持业务的需要，支持业务需要时可以是线上+线下来完成，如果是及其低频、线下处理比线上处理还要方便的业务需求，这时可以化繁为简，没必要线上来做。
接着聊第二个问题，需求优先级排序。