管理需求激增

需求变更与需求管理是IT项目中的重要一部分。在项目初期，需求不是很明确时，特别是在需求转化为设计的过程中，需求变更更多的是表现为需求的快速增长。这些增加出来的需求如果得不到很好的控制，将会严重的影响项目的计划，安排，甚至偏离项目的原始目标。

 

另外一个场景，现在流行的Agile项目管理方案，需求是递增的，虽然是在一定的product backlog中产生出来，但是在每个sprint，product owner、scrum master 以及team如果没有很好的管理需求，项目进展过程中，新的想法不断产生，这将会产生快速的需求增长。这样的结果是release plan 不断地调整，功能不断地增加，系统越来越复杂，但是最终交付的产品却不断地拖延。这样的结果是违背了Agile的初衷的。我遇到的很多国内的所谓agile项目，客户很喜欢使用agile的原因之一就是可以不断地提出需求。感觉是占了便宜，其实最终导致项目失败。

 

下面就对“需求激增”这一需求变更的应对、管理提出一些建议：

 

1.      随意增加需求的根本愿意是对项目范围的模糊理解，以及对项目范围的忽视。所以还是老生常谈，将项目范围明确下来，以正式的方式给项目团队，所有的stakeholder介绍清楚，形成文档。同时着重强调：项目范围是一把指导项目的尚方宝剑。需要得到尊重与遵守。

 

还要强调需求管理的方式，流程。同时让所有stakeholder了解不合理需求管理所带来的负面后果。

 

2.      怎样处理新增的需求？业务分析师，项目管理者要首先分析这个需求是不是在我们之前已经明确的范围内。比如说：新的功能，新的用例，新的报表，新的步骤，这些都是很明显的超出项目范围的需求。但是我们需要知道的是还有一些隐性的需求也需要考虑，所谓的隐性需求是指那些没有包含在产品里的需求。比如说培训，交接文档。当客户突然提出与之前承诺的不同形式的培训计划，文档形式，虽然这样的需求不影响交付物，但也是需要控制的新增需求。

 

3.      令人难以拒绝的新需求。有些新的需求是十分有道理的，而且有一定的好处。这样的新需求特别难以拒绝。

 

对于这样的需求，我们仍需要坚持项目范围控制原则。如果新功能很明显是在下一次发布的范围内，那么团队需要解决这个问题。如果它显然是不在范围内，那么团队就不需要解决它了。但是我们也不能完全拒绝这样的需求，必要的对新需求进行分析，要考虑的是扩展当前版本范围的提议是否会显著地提高该版本的成功，如果是则可以将这个新功能放到以后的版本中。

 

 

处理需求变更的具体步骤方法我们就不用多说了，应对新的需求有一定的策略。把握这些策略对管理新增变更有很好的帮助，下面就介绍一下这些基本策略：

 

l  在当前的版本中，可以推迟一些较低优先级或需要时间较少的功能，从而流出一些时间为新的需求使用（如果新的需求是必须的、迫在眉睫的）。

l  获得额外的开发人员来处理额外的工作。

l  获得额外的资金，也许是为了支付加班费，外包一些工作，或者利用生产力工具。

l  扩展当前版本的时间表以适应新增的功能。

l  提高交付速度，但在质量上妥协，你需要在以后上进行修补。