那为什么需求管理是项目管理中的一大难点呢？我先看看这些场景是不是都很熟悉：
1）产品提的期望是A ，结果做出来演示的是B，实际出现很大的偏差，从期望到真正可落地的需求千差万别；
2）比如老板和产品负责人对需求的理解不一致，经常出现已经定好的目标，产品负责人要变更，但老板觉得没必要，项目经理受夹板气；
3）老板经常性的插入需求，导致变更率居高不下，需求变更流程形同虚设；
4）需求落地执行的过程中，一切都看上去挺顺利的，都在按计划执行，结果到验收阶段，各种问题频出：不是功能的缺失，就是进度的延迟，功能看着像是做完了，但各种小问题一堆；
5）多方不断地插入需求，但时间又不允许增加，还要求按原计划完成，导致团队怨声载道，满意度很低。
以上这些场景，是不是都不陌生。事实上，可能远不止这些问题。
那么就我们项目管理日常的一些场景来分析，需求管理的难点在于：
1）需求管理本身，因为项目的特点是渐进明晰，不确定性是贯穿整个周期，而需求是源头，一旦源头有问题，对整个项目全流程都有很大的影响；
2）需求管理“背后”，需求输出、实现、交付、完成，都是由人来参与的，有人参与的地方，人的复杂性，就使得整个链路都不会太简单。比如对需求方期望的真正理解、对老板变更预期的理解、对团队执行过程中的跟进与监控、还有团队执行的满意度。
但作为一名项目经理，我们日常项目管理中，非常重要的一项工作，就是需求管理。如何做好需求管理，非常考验项目经理能力。
今天，来系统地谈一下，我是怎么做需求管理的。
1、了解背景
一位合格的项目经理，在负责一个项目之初时，需要花大量的时间了解清楚项目的背景。我认为这是非常重要的前提。换句话说，如果项目经理对自己所负责的项目背景都不了解，就别提对业务有所了解和理解了。
何谓项目的背景，简单来说，就是这是一款什么样的项目？是什么类型的项目？市场上是否已经有类似的竞品？和竞品相比，项目的优势和亮点体现在哪里？项目的主要干系人有哪些？项目发起人，项目核心管理层的预期是什么？
除了这些以外，还有必要了解清楚，我们为什么要做这个项目？做这个项目能带来的价值是什么？
再更深入一点的，这个项目主要要针对的是哪些用户？这些目标用户，我们的项目是否可以满足他们的期望和诉求？我们项目将围绕怎样的目标来展开，以便满足这些用户的期望和诉求。
为什么要了解项目的背景，其实目的很简单：当了解项目的背景之后，会有助于真正理解业务。也就是说，项目经理是要真正理解业务的。
2、明确目标
当了解了项目背景之后，接着就要进一步明确项目的目标，从项目阶段来说可分为：短期目标、中期目标和远期目标。从产品本身来说，项目目标分为：最直接的目标、业务目标和战略目标。
不论项目内部自己怎么划分，这个不是重点，重点是项目经理需要明确项目目标。总不能一接到项目，就直接带着团队开干吧。
之所以要特别强调明确目标，是因为在实际落地执行过程中，我们很多项目经理往往会忽略这个目标的确定。
我们项目经理的首要事项就是带领团队去实现项目目标，如果目标都不清晰，怎么做好项目管理，更别提具体到需求管理的细节了。
以最直接的目标为例，其实就是弄清楚时间、成本（人力）、范围和质量这四要素。要做这个项目，预计是在什么时间，投入多少人力资源，做多少需求，达到怎样的质量标准，这是必须项，也是项目确定目标非常具象化的。比如我们常常会去界定，项目在某个时间节点上线。这就是最直接的目标。
而业务目标是更深一层次的目标，也就是投资项目的价值是什么，或者说做这个项目的价值是什么？
项目经理在了解项目背景的时候，通常都需要清楚地知道业务目标。执行过程中是以最直接的目标为依托，但真正是以业务目标为导向。因为要达成业务目标，是需要通过一个个已经规划的版本来达成的。
3、界定范围
在目标明确之后，要落地每一个版本，就必然要界定清楚每个版本的范围。这个范围通常可以按照敏捷的MoSCoW法则来定：must（一定有） 、should（应该有）、could or would not（可有可没有）。
MoSCoW法则只是确定范围的一个方法。在确定范围之前，还有一个步骤，就是对目标进行分解。目标分解之后，再针对每个小目标进行范围的界定，这样执行才可以比较有效地落到。
以一个为期一年的项目为例：
1）项目最直接的目标是，一年后要上线测试；
2）为期一年的项目，说长不长，说短也不短。界定范围时，得先有一个整体的需求框架，这个是整个项目的大范围。梳理需求框架的目的不言而喻，就是我们要做一款产品，会涉及到哪些系统功能。这和scrum里面提的梳理产品待办事项列表是一个意思来的。比如下图表格所呈现的模式，把整个一年要做的需求都界定清楚。
这个梳理出来之后，可以让团队对整体的功能需求有一个全貌。当然最重要的目的之一还是为了对整体版本进行规划来的。
3）有了整体的需求框架之后，就可以开始进行版本的整体规划。在做整体规划的时候，项目经理不能完全的去拍个脑袋做一份规划，应该需要和产品负责人进行深入的沟通和交流，确保彼此的理解一致。比如我们最初始的节奏是以两个月为一个版本周期和节奏进行规划。
4）有了版本规划之后，就可以进一步地进行范围的界定了。以beta1为例，要做11个功能系统。这11个功能系统，也会进一步明确，哪些是必须要保证的，哪些是应该有的，哪些是可有可不有的。
可能会有朋友疑惑，为什么进行了版本的规划，还需要去进行需求优先级的划分。这里面主要的原因在于团队的资源有限，进行需求优先级的划分是更有利于需求的落地执行。同时，项目在研发过程中，是一定要预留buff的，以便可以应对各种突发情况。
4、确认需求
范围确定之后，接下来就是确定需求。确定需求这一步，往往是决定需求管理做好与不好的关键步骤。而确定需求，恰恰也是项目经理最容易忽略的地方。
需求管理，最根本在于对需求源头的管理，只有源头抓好了，后面的每个环节才会更顺。所以，具体到每个需求在正式开始落地之前，一定要经过确认。怎么来确认？
敏捷提倡我们小步快跑，快速迭代，但并不代表着对需求的质量输出没有要求。确认需求，提高需求的输出质量，可以借鉴如下：
1）每个需求的输出，是需要在产品内部（游戏的产品叫做策划）经过层层把关的，具体的流程是这样的：
需求模块撰写人->领域负责人审核->领域群评审->主策划评审->制作人和策划团队一起评审->输出需求提交项目经理安排。
2）需求输出之后，需要进行交互的设计，交互是产品需求和开发的一个桥梁。在需求确认之后，还需要进一步明确交互设计。交互的用途在于，把需求以可视化的方式呈现出来，也有利于开发人员进行详细的评估。
互联网或游戏项目，需求的产出都是来自于内部产品经理，项目经理只需制定好相应的流程和规则，处理起来也都还好。
但对于一些甲方和乙方类的项目，很多时候客户提出的不一定是需求，可能是某一个期望。这种情况下，从期望到真正落地的需求，项目经理是需要花费更多的时间来对齐确认的。
这一类的项目，项目经理更加需要了解项目的背景和目标，有了信息的基础，当客户讲他们的诉求时，往往也能更容易抓住核心观点，逐步进行拆解和分解，最终输出可落地的需求。
所以，需求是一定需要经过确认的，而且对于我们项目来说，只有经过产品团队内部确认过的需求，包括项目总监，leader等一并确认过的需求，才会被提到需求管理工具中来。这也是我们项目制定的最基本的原则之一。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
