需求管理是产品设计流程中非常重要的一环。但很多人只知道需求分析，不知道如何做需求管理，本文来解决下这个问题。

首先需要理解管理到底是什么。管理是为了达成目标，对有限资源进行协调和配置的过程。对B端产品来说，目标是某方面的业务效率提升，从而间接影响用户体验。能协调的资源就是有限的开发人力，还可能涉及需求实现后产生的运营人力。那需求管理就是要在有限资源的前提下，判断做什么、怎么做、什么时候做、做完以后的效果怎么样

一、做什么

既然资源有限，对需求就要有筛选，到底要不要做。日常需求或者部门内项目评估的基础原则是需求的投入产出比（ROI），低投入高产出的需求价值最高，通常不多见，低投入低产出、高投入高产出是最常见的，高投入低产出也相对少，通常是决策失误。另外如果是管理层制定的公司级项目，需求是自上而下的，这种需求凌驾于ROI之上。这种项目本身是根据公司战略规划出来，最终价值产出高度依赖一把手的商业敏感度，在这个前提下，每个子业务很难量化ROI，更多的是在方案层面如何用最少成本支持到这个项目。

ROI不光是开发成本，如果是从0-1做的一个新流程，功能上线后要人工介入运营的，那这部分运营人力也是投入，计算方式是死的，把什么因子算进去是活的。如果考虑不全面，很有可能需求评估的价值上会产生很大区别，导致最初以为很有价值的需求上线运营以后，被需求方诟病。所以在评估需求价值的时候是要有投入产出意识的，这时候不需要很准确的算出一个数值，而是要站在全局考虑一个需求上线前后，哪些地方会有影响，每个地方影响是正向还是负向的，影响有多大。

二、怎么做

筛完后的需求就要考虑解决方案了，做方案是基础，推动落地才是升阶。方案合理性最重要：可以满足主流程需要、有业务价值、技术实现可行、说服上下游协同、有开发资源排期，这几个方面在实际工作中往往都不会同时具备，需要产品经理不断介入推动达成，必要时也要调整方案

三、什么时候做

时机的选择依赖业务节奏，对B端产品来说，通常迭代节点与业务节奏保持大概同步。集成类项目需要死守，大家都在跑，如果目标没完成，走路的那个人就要背锅；小范围的部门内自闭环的需求，如果因为开发临时做了紧急项目，那就没有死守的必要，可以跟业务协商推迟上线。总之在节奏层面上有张有弛，收放自如。

四、做完以后的效果怎么样

现在很多复盘是针对问题或者失败案例，养成习惯的人对每件事都会复盘，做的好坏都是有原因的。效果好就要思考是哪些地方做对了，避过了哪些坑幸亏当时没做，效果差就要思考哪些地方做的不对，用什么方式做更好。任何思考除了考虑内外部环境，如果是外部原因导致的差，那也没要甩锅，人还是要为自己做的事情负责，就像失业不能总怪大环境，对外部环境变动感知弱，自己做了误判，做了错误的决策和行动，就要为结果买单。

总结：需求管理在横向上是自始至终的，事前评估，事后复盘；在纵向步骤中需要考虑周全，张弛有度。