如何做需求管理？这8个tips你需要知道（怎么做需求管理）

项目管理中的三大难点，分别是需求管理、风险管理和干系人管理。其中就提到，需求管理，是项目管理过程中的一大难点。作为项目经理，能做好这三个方面的管理，项目管理的水平也就达到了一定的高度。

那为什么需求管理是项目管理中的一大难点呢？我先看看这些场景是不是都很熟悉：

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等一并确认过的需求，才会被提到需求管理工具中来。这也是我们项目制定的最基本的原则之一。

5、需求开发

需求确认之后，进入开发阶段。从需求评审到最后验收，是一个闭环流程。详见下图：

需要特别说明的是，需求在开发阶段，需求评审、需求可行性论证、需求的方案设计、技术方案评估，都需要开发和美术的leader一起参与评审，并对结果负责。在需求评审的时候，产品、开发、美术和测试相关的人员都需要参加。

需求的源头确认了，那么在需求进入开发阶段的源头，也需要多次核对并确认。正所谓磨刀不误砍柴工，千万不要认为这个时间花了，还不如提前接入写几行代码。一旦出现被催进度，尽快启动开发的时候，项目经理一定要顶得住压力，把前面的准备工作做足。

以一个需求为例来说，我们看的是整个需求的完整开发周期，也就是从需求评审->需求开发->需求验收->需求测试->需求完结。

需求开发的源头就是需求方案的设计，详细工作量的评估，需要层层把关，对结果负责。试想，如果为了省这个几天的时间，结果导致需求开发完成之后，出现一堆bug，最后验收效果不好，测试过程坎坷，看着前面省了一点时间，但其实整个需求的开发周期都拉长了。

在软件质量里面有一句话：质量是设计出来的。测试人员是质量最后的“守门员”，不要把所有的质量问题都留在最后测试环节。

所以技术方案，详细工作量评估（WBS）这些准备的越充足，一方面是有利于跟进执行；更重要的是有利于保证验收环节和测试环节的顺利。

为了确保验收的效率和测试的顺利，在整个需求开发流程里面，我们还额外新增了自测用例的评审，开发某个需求自测联调结束之后，开发人员需要跑10%-20%的自测用例，通过率需要达到90%及以上，才能正式转产品验收。

当产品验收的体验问题输出之后，需要快速拉起开发、产品、测试一起对齐，落实体验优化，在体验单解决完90%及以上之后，才会正式转测试。

6、搭建可视化

需求管理的过程需要透明化，可视化。市面上已经有很多好的工具。项目经理需要善于借助工具来搭建搭建可视化，建立需求自动化运转流程。

一个好的工具，可以让我们在对需求管理时事半功倍。我们用的TAPD工具非常的强大。

因为每个公司的项目管理工具可能不一样，所以这里不做细述。但用工具需要是为了更好地去提升效率。

通过工具，让整个项目管理过程更加的可视化，透明化。项目经理要详尽一切办法，让能够可视化的都尽量可视化。这也是项目经理的核心价值之一。

至于工具的使用，需求单状态的流转，从宣讲开始，逐步的培养团队养成这样的习惯，这些并不是难事。

同时，建立相应的规则，加以约束，避免部分成员不遵守。对于还有部分经常性不遵守的成员，则在项目管理过程中重点关注，以引导和教育为主。

7、应对变更

世界著名作家、大思想家斯宾塞.约翰逊曾经说过“世界上唯一不变的，是变化本身”。

作为项目经理，我们在带项目的过程中，需要有一个认知：市场驱动型的项目，变是永恒。面对变化，项目经理需要拥抱变化，宜疏不宜堵。

不否认的是，很多项目经理怕项目过程中出现变更，甚至想方设法制定各种流程，试图来控制变更。

从我自身的角度来说，我认为这都是不成熟项目经理做的事情，或者是初级项目经理会做的事情。

而一位合格的项目经理，成熟的项目经理，是需要懂得怎么去拥抱变化，有效地引导和控制变更，做好预期管理。

怎么来更好地应对变化呢？这里要分几种情况来看：

1）项目的范围蔓延和镀金

这是项目经理需要重点关注的，范围蔓延和镀金也是项目推进过程中变化的一种情况。当出现范围蔓延或镀金的时候，会慢慢蚕食项目的资源，或者原本产品需求没有的，额外新增了一些功能，使得原本的计划不断地偏移，团队各种加班赶进度，抱怨声音不断。

这种情况我认为是需要控制的。项目经理需要高度的敏感，一旦识别项目范围蔓延或出现镀金的情况，要及时地进行管控，确保项目在正常的框架内运行。因为资源是一点点被蚕食，可能会不知不觉中进行，当量积累到一定程度的时候，可能会对原有计划有很大的影响。

2）项目执行过程中出现的需求变更

一个项目计划已经按照既定的要求制定好了，并在有序的进行执行中。在做着做着的过程中，发现一些需求的细节需要补充，或者在自测用例评审的时候，发现需要增补一些功能点。

这种情况在实际执行过程中是非常常见的，项目经理不要急着去阻止这些需求，成熟的做法是和团队一起沟通对齐这些新增需求需要花费的时间，然后评估需求的影响面和必要性（或者敏捷谈到的价值）。有了这些数据之后，再去和管理层沟通，给出相应的方案，最终让管理层和团队一起来决策是否需要走变更流程。

如果走变更流程，就重新刷新计划，更新好之后同步全员，按新的计划执行；如果沟通的结论是可以放到后面再安排，则按原计划进行。这里我个人会倾向于开发过程中出现的这类需求细节的调整，尽可能的一次性到位的安排处理。

3）项目执行过程中，有插入新的需求情况

这在很多项目中是非常常见的，插入的需求可能大多来自于老板，领导。老板们的需求自然是要重视的，但如果放任这种情况持续的发生，需求的管理会逐步失控，而且团队的满意度会直线下降，对项目经理的认可度也会大打折扣。

根据我自己的经验，遇到这种情况，偶尔出现一次，管控好预期，应该问题不大。插入的需求或许是业务侧本身的需要，但需求的增加，表明范围的扩大，铁三角中，人和时间都不变的情况下，这个插入的需求必然是会影响已经制定的计划的。这种情况下怎么应对呢？

如果时间和人都不变的情况下，对于插入的需求，可以重新把之前的需求拿出来一起沟通对齐优先级，重新排优先级就好，千万别给老板拍胸脯保证，可以内部消化掉，因为很有可能赶时间完成的需求和预期有很大的偏差，而且团队成员也加班加点，不买账。

如果是时间可以调整，那新增的需求，在当前的人力资源情况下，整体评估完成时间，更新计划，同步老板和团队，按新的计划进行。

如果范围和时间不变，新增的需求可以协调其他人力支持，项目经理也需要更新项目的情况，同步老板和团队。

如果项目经理可以做决策的情况下，以上都可以，但为凸显项目经理的更加专业和稳重，可以将各种方案呈现出来，最终由老板去做选择题，拍板决定使用哪个方案。

对于偶然的情况，以上的策略都是可行的。但如果作为项目经理，你发现已经出现2-3次这种插入需求的情况，甚至未来还会持续的时候。项目经理需要和管理层“约法三章”了，要从源头梳理并重新建立相应的规则，制定插入需求的处理方式。不要认为老板提的需求，项目经理就无条件地去执行。老板也是怕欠人情的，多次提需求，使得项目推进过程出现变化，甚至延期，那就有必要从管理层入手来解决这个频发插入需求的情况。

4）项目目标出现变化

项目目标出现变化，必然会导致项目的范围出现变化。

项目经理要对目标有清晰的理解和认知，要能够根据日常的沟通，尤其是管理层的沟通中，获取有用的信息，以便判断是否对目标有影响。

当然，通常情况下，如果是因为市场的变化，因为政策的变化，使得项目目标要进行调整，这个时候管理层也会主动发起相关的会议，和项目的核心干系人进行沟通对齐。

但切记，管理层的信息对齐只是一个信息的传达，作为项目经理，需要果敢的应对这种突发的变化，要清楚的知道该如何开展下一步的工作。

事实上，本身也不复杂，当目标出现变化时，就又回到了前面第二、三大要点，重新明确目标，界定范围。

因为目标已经变了，再按原来的计划执行下去，做得越多，可能错的也就越多，所以，需要即刻展开范围的梳理和界定，然后重新制定计划。

学习ACP的朋友，这个时候也需要灵活地进行变通，理论知识是说一个迭代内是不允许变更的，但实际项目执行的过程，当出现目标变化，需要果断的叫停一些已经做的需求，哪怕是这个需求即将做完。

在应对变更时，项目经理需要根据实际情况，发挥自己的专业性，对项目重新梳理，尤其是范围，在重新制定计划之后，还需要特别的和管理层对齐预期。

项目的特点是渐进明晰，实际推进项目的过程中，哪怕是风险管理做得再好，也还是会出现一些突发的情况。因此，变更的情况在这里也不能一一枚举。

一位成熟的项目经理，就是当项目出现突发情况时，能够在团队面前处变不惊，并且有思路、有逻辑的展开和推进各项工作。所以，变化是永恒的。拥抱变化，管理好预期，是应对变更的重要原则。

8、产品能力

最后一个要点，产品能力，是说项目经理需要具备一定的产品能力。以互联网项目或游戏项目为例，在负责这一类项目时，可以不懂技术，但我认为是需要具备一定的产品能力，需要真正的懂业务。

当项目经理具备一定的产品能力，能够更充分地理解需求，把握产品意图。因此，项目经理要能够或者多培养自己从产品层面思考，让项目的推进能够更加贴合产品的最终形态，这样更有利于对项目的把控。

在我的认知里面，项目经理绝不仅仅只是排排计划，管管风险，和管理层沟通沟通。项目管理中，需求管理要真正的做得好，项目经理是需要理解业务的，需要花一定的精力下沉到业务线中，要对产品有自己的理解和认知。

具体的产品能力包括但不限于需求的理解和分析能力、产品意识（产品体验和竞品分析）、运营数据分析能力、用户思维等。

当项目经理具备一定的产品能力，真正的懂业务，对业务有自己的理解，在实际推进项目的过程中，也会更加有底气。

在和团队成员沟通对齐目标时，不用担心自己不懂技术而没有共同沟通的频道，一切以目标为出发，就是最好的手段之一。

作者：zhouxu，腾讯IEG研发项目管理，PMP，PRINCE2，专注于分享日常项目管理过程中的点滴，辅以分享职业成长的思考与感悟。著有《谁说菜鸟不能成为项目经理》一书。