一、问题的提出

用户需求变更，这是每一名项目实施人员感到头痛的事情。对于那种需求变更较少的情况，会增加我们的项目工作量，对项目进度造成一定的延误；对于大量的需求变更，或颠覆性的需求变更，会把项目拖入“绝境”中，项目人员疲惫不堪，用户不满意，最终导致项目无法验收。需求如果管理或控制不好，实际对甲乙双方来讲会造成“两败俱伤”的局面，因为，并不是所有的需求都是可行的，如果不进行科学的评估和合理的规划，那些“危险”的需求会将项目引向“泥潭”，导致双方无法“自拔”，使项目陷入极其被动的局面。

二、原因分析

1．项目合同或协议范围界定模糊

在签订项目合同或技术协议时，没有把实施范围或项目内容描述清楚，为了通过竞争拿到合同，对于用户的很多要求都进行承诺。导致实施过程中用户任意提出各种需求。

2．需求调研不明确和不详细

在项目初期，项目实施方需要进行需求调研。如果需求调研的对象选择有问题，会给调研内容造成较大的偏差。如项目实施方选择对业务了解不全面的人进行调研，他（她）所提供的需求信息就会不全面，为需求分析提供了不完整或存在偏差的信息，导致后续的设计和开发结果无法满足用户需求。另外，有的情况下为了赶进度，草草进行调研，不对用户的业务需求进行详细的分析，同样会影响后面的设计和开发的质量。

3．对用户需求的理解存在偏差

在项目实施过程中，实施人员对用户所提出的需求并没有完全理解，想当然进行了分析和设计，结果开发出来的功能并不是用户所真正需要的，与用户的想法存在差异性，导致需求变更。

4．用户没有完全了解和掌握系统

在有些情况下，由于用户没有完全理解和掌握系统的各项功能和配置，认为系统缺少某些业务支撑，要求项目人员进行需求变更。

5．缺乏流程控制和管理

在项目实施中，由于没有指定有效的需求变更流程，用户一有想法就对实施人员提出变更，甚至有的需求进行反复变更，大大降低了实施效率和影响工作进度。

三、如何解决

1．明确需求，认真分析

在项目签订时，要和用户方明确“做什么，不做什么”，需求明确了，实施范围就确定了。即使实施过程中出现了需求变更，项目组可根据其工作量、技术难度、现场实际情况来灵活掌握，争取了主动权。

另外，在需求调研阶段，要让项目组有经验的业务顾问进行详细的调研工作，从业务角度对用户的需求进行分析，并编写详细的《需求规格说明书》，文档经过内部和用户方评审通过后，再进行后续的工作。这样，开发出来的功能才不会与用户产生较大的差异，从而避免一些不必要的需求变更。

2．规范需求变更流程

在项目启动初期，项目实施方需要与用户方就需求变更进行流程的制定。这是控制需求变更的有效管理手段，制定需求变更审批流程并不代表不让用户提出需求变更，而是让需求变更按照规范的流程进行管理，让需求更加有效、合理，真正达到改善的效果。

在制定需求变更审批流程中，可把用户方的信息部门作为流程的主要控制环节，如果用户方缺乏信息部门或部门组织不健全，可让项目管理部门作为主要控制环节。这样，就避免了最终用户与实施人员的点对点的需求交互，而是通过主管部门和各环节的审批来进行需求的变更。如果需求变更影响较大，要通过专家组进行可行性和风险的评估。

3．及时沟通

对于用户所提出的需求变更，项目实施方必须要了解用户的真实想法，以及真正想要的是什么。任何“强势”态度和“一味迁就”的做法都是不可取的，因为有时用户方看到的只是表面问题，项目实施方要从需求问题的实质去考虑，既要根据系统本身情况，又要结合用户业务层面，客观地分析用户的需求变更，使用户得到充分的理解。

4．加大培训力度

系统在上线前，要对用户进行大量的培训，让他们充分地了解和掌握系统的每个功能，对于系统二次开发和灵活配置的功能，要对用户进行多次的训练和实践，让用户得到熟练的应用。有些需求变更是可以通过系统配置来实现的，或由用户方的运维人员来完成。

5．降低用户期望值

对于用户的有些需求，项目实施方有时需要明确告诉用户哪些能做，哪些不能做。对于有些需求，要完成是很困难的，要让用户知道，不是所有的需求都可以轻而易举地实现。让用户的期望值有所降低，有些工作可以分期、分阶段去实现，在有限的条件下不可能任何的需求都能实现，要让用户明白这个道理。

四、综述

对用户的需求进行有效的控制和规范的管理，与用户达成共识，是保障项目按计划进行和顺利验收的重要手段。

• 上一篇：需求开发与管理过程
• 下一篇：需求变更控制流程