软件需求变更一直是软件项目管理之痛，需求变更带来的工期的延长、成本的增加、项目组中成员沮丧情绪的蔓延在很多项目中或多或少的存在，管理需求变更成为了项目的重中之重。

在政府以及国有企业的项目中，需求的蔓延尤为重要。一些项目高层领导签订框架协议后需求还不是很明确的情况就开始动工，尤其是当甲方涉及的项目专业性很强的情况下，乙方仓促上阵，乙方的需求分析人员对业务一知半解就别推上前线，为了应付计划阶段定义的里程碑，很多项目在需求没有澄清之前就仓促进入开发阶段，美其名曰是我们的项目时间很紧没时间做需求，等你搞清楚需求黄花菜都凉，真的是这样吗？我见过几十个这样的项目，最后无不是研发人员无期限的加班不停修改重复的功能模块，项目工期远超预期。无数的实践证明，当前期需求没有澄清之前就仓促进入开发，最后导致的结果只能是项目的延期。

在一部分软件项目中的确存在项目前期甲方不可能澄清项目所有的需求，项目工期紧张，也没有太多的时间预留给产品经理/需求分析师分析清楚整个系统并完成需求文档的编制。面对这种情况，在以往的项目实践中我们的做法是：理清楚整个系统的目标、主要功能及业务流程，先针对一两个核心模块（或者是流程中前面的节点）进行分析形成需求文档，并经客户确认（客户确认非常重要，是需求变更的基线）后先行启动部分模块的开发，以解决工期和需求分析间的关系。

软件项目在执行期间需求不可能不发生变更，这个时候如何管理需求的变更显得尤为重要。在和一切企业的项目经理特别是做政府部门/国有企业项目的项目经理沟通的时候，给我的反馈是甲方要调整需求我们也办法，不调整需求项目就进行不下去了。最后的结果是项目管理中没有需求变更管理这个概念，真的这类性质的项目需求变更不能进行管理吗？个人以为，不尽然。恰恰是这类性质的部门聚集了中国的精英，如果你能说服他们并确实有利于项目的交付，他们不可能不配合，就项目而言，形成甲乙双方的项目团队在某种意义的利益是一致的，都期望项目能顺利交付。基于这个前提，软件需求管理就存在可以操作的空间。

甲方项目负责人（接口人）一般都不是单位的最高领导，在项目中如果让他们签字，天然就存在抵触情绪，这也是在软件项目中需求变更走不下去的原因之一。那么如何做项目这类企业的软件需求变更工作呢?结合以往的项目经验，在项目中我是这样做的：在项目kick-off会议的时候就明确需求变更的流程，需求变更发生时甲乙双方需要尽的义务和责任；每一个微小的需求变更都打印需求变更单让甲方接口人（如果涉及到多业务部门则需要让提出需求变更的人签字确认），并且告知甲方需求变更肯定要签字，这是为了保证项目的按期完工，同时，这个签字不会和商务费用挂钩，商务走另外一条流程；以周为单位，在每周的周报上将本周的需求变更汇总通过周报发给向项目相关人员（一般会包括甲方挂名负责该项目的领导）；每一个月或者累计到一定工作量的时候通过商务走需求变更（如果为固定单价合同，则让公司商务知晓项目变更情况，寻求商务的支持）。

在项目中，如果要求甲方对需求变更签字，相当于有一个正式的确认过程，甲方需求的提出人会认真考虑需求变更的必要性以及需求变更的相关影响，能有效抑制需求的随意变更，并有利于更全面的考虑需求变更带来的其他影响。而当项目需求变更得到控制时，整个项目到验收阶段，需求的变更虽然存在，会减少有几个需求变更前后矛盾的发生。

所以，软件项目首先要有用户对第一份（可以按模块）签字做为需求变更的基线，在项目执行过程中坚持变更签字确认，对需求变更进行统一管理可以有效控制项目的变更为项目按期交付提供有力的保障。