说出你是怎么进行项目需求管理（原创）090911

我们知道每个项目都有它固定的范围。产品类项目，项目立项时，项目经理首先要搞定的就是《项目前景范围》；合同类项目，标书、合同就是蓝本，约束着项目的范围和目标。但做项目难就难在怎么在有限的资源、时间内完成既定的项目范围目标，而且还要保持好的项目质量，让项目发起人或是客户满意。所以说，项目唯一不变的就是变化，这个变化当然也就包括项目范围。也就牵涉到项目经理在项目管控中如何管控好项目需求，控制好项目的范围。

接下来，我就自己在做项目中需求管理方面一点体会和各位分享一下。

对于产品类项目，项目发起人，一般是你的老大，根据本部门产品战略考虑，发起项目。这个项目可能是原有产品的大手术，也有可能是一个全新的战略产品项目。正规一点的公司，可能有一个产品组，项目立项了，指派项目经理，几个产品经理负责到产品以后投入市场的目标客户那里进行拉网式的需求调研，回来后整理评审，形成初步的《项目前景范围》，然后项目经理以此为蓝本，确立项目范围。招兵买马成立项目组，内部立项走流程（看似还很复杂），建立项目范围基线，就忙开了。产品经理开始写概要设计，测试组开始写测试用例，开发组摩拳擦掌开始详细设计、数据库设计、写代码、评审代码……。如果新产品在新框架下进行，还得架构师对项目组进行培训，那就更麻烦。项目牵涉其中是项目资源协调以及项目进度管控，这个是关键。至于范围可能是很明确的，变动也小，最起码第一个版本是可见并且相当固定的（产品采用的是微软的MSF版本迭代方式）。对于这样的项目，我的理解是需求范围不是项目经理管控的关键，关键反而是进度和资源（资源往往不固定，让步于合同类项目，毕竟面对客户的项目是公司生存的根本，部门要首先保障合同类项目的客户满意度）。

对于合同类项目，面对真实的客户（用户），最终使用系统的用户可不管投标书、合同之范围，他从使用系统方便、实用的角度会给你找很多麻烦。作为项目经理，如果你的项目没有给你配备专门的PDM，那你只有亲自和用户PK了啊！各个项目经理可能采取的原则不一样，但目标只有一个就是控制项目范围。

首先，应该在用户内部建立一个提出和确认需求的机制。我们知道一旦系统在很多单位中使用开后，每个终端用户，也就是我们的上帝，会结合他自身的业务特点从不同的角度提出很多他认为非优化不可的需求。项目开始一段时间后，你如果组织用户使用回访的话你就会深刻体会到我说的这句话，就同一功能点，各个单位提出的修改意见可能是相互对立的。你如何面对这样混乱的局面？只有在用户内部建立一个提出和确认需求的机制。我们知道对于该项目用户内部肯定有几个说话算数的，专业术语就是关键涉众，项目经理要有敏锐的洞察力找到这几个人（好像管理关键涉众的期望是项目经理必修课），建立需求过滤确认机制，具体每个项目经理可能操作手法不一样。任何人都可以提出需求，这是用户的权利，但有专门的人来过滤筛选。这个人在这个项目中要有影响力或是大领导授权的，也很懂业务，他能判断什么是合理的需求什么是不合理的想当然。这一步我称之为需求管控的“第一层筛”。如果效果好的话，基本能解决前面提到的混乱局面。

其次，要建立需求管理的流程，这个流程通过项目经理（或是PDM）将用户和项目组内部链接起来。项目经理将收集到的已经和关键用户确认的需求纳入需求管理库，然后回来组织项目组开会评审，开发、测试、部署、项目经理，如果有产品经理的话都要参加，一条一条的过，过完之后最少要明确以下几点，一、需求描述是否简单明了并且可理解；二、从目前技术的角度是否可实现，如果没有解决方案，如何跟用户反馈（我们叫用户教育，也有同行说“忽悠”）；三、实现的方法以及工作量；四、谁来实现；五、什么时候提交测试，什么时候生产环境部署。这些信息都纳入需求管理库方便后期跟踪。剩下的可怜的项目经理就要和用户博弈了，将评审结果反馈给那个确认需求的关键涉众，对于不能实现或是不好实现的，你就要以一颗真诚的心来打动这个人。一旦用户认可这些方案后，以专门的《需求确认表》形式给用户签字画押。项目经理排计划，开始版本迭代。

最后，看似复杂的流程有几个好处，一、合理的管理了用户的需求；二、将需求反复的可能性降到了最低；三、用户和项目组在需求管理方面都知道如何去做好自己该做的。

另外，在管控项目需求时，千万不要给用户造成一味回避需求的印象，用户很反感。毕竟我们的口号是：不是不响应用户的任何需求，而是响应合理的、能提高客户应用价值的需求。说到这我不得不认真负责任的说上一句，其实我们对待用户的需求是真诚的，我们会站在用户的角度去考虑，去提升用户的应用价值，但在面对强势的用户时，有时也很无奈。但如果不加选择、不加控制的去管理一个项目的需求，你会发现你和你的团队正处一个遥遥无期看不到希望的项目中。至于项目的成本控制、时间控制也都将惨不忍睹。