软件项目管理变更请求

 

  不被控制的变更会使项目陷人混乱、不能按进度执行或软件质量低劣。需求管理就是要按照标准的流程来控制需求的变化，使需求在受控的状态下发生变化，而不是随意变化。只有在开发中控制变更，才能保证项目按计划实现项目目标。因此，应仔细评估已建议的变更;挑选合适的人选对变更作出决定;变更应及时通知所有涉及的人员;要按-定的程序来采纳需求变更。

  1.控制需求渐变的策略
 

  需求中的变化一般不是突发的、革命性的变化，最常见的是项目需求的渐变问题。这种渐变很可能是客户与开发方都没有意识到的，当达到一定程度时，双方才幕然回首，发现已经物是人非，换了一番天地。控制需求渐变需要注意以下几点。

 

  ●需求一定要与投人有显然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始无论是软件开发方还是出资方都要明确这条:需求变化，软件开发的投入也要变化。

 

  ●需求的变更要经过出资者的认可，需求的变更引起投人的变化，所以要通过出资者的认可或客户方真正有决策权的人员的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

 

  ●小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为这样降低了开发效率，浪费了时间。正是由于这种观念才使需求的渐变不可控，最终导致项目的失败。

 

  ●精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求细化了，它就不会变化了。
 

 

 

  2.变更控制过程

 

  按照现代项目管理的概念，需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。变更控制的动机是:如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制如果需求变更带来的坏处大，于好处， 那么拒绝变更。当然， 好处与环处并不是主观的，而是通过客观的分析与评价面得出来的。

 

  (1)项目启动阶段的变更预防

 

  对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说，《需求规格说明书》中定义的范围越清晰，用户跟项目经理扯皮的情况就越少。如果需求没做好，《需求规格说明书》里的范围含糊不清，漏洞百出，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这样做的目的是使双方都严格遵循合同的约束，有利于保证项目目标的实现。

 

  (2)项目实施阶段的变更控制

 

  成功项目和失败项目的区别往往在于项目的整个过程是否是可控的。项目经理应该树立一个理念一“ 需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。为了将项目变更的影响降到最小，需要采用综合变更控制方法。综合变更控制主要包括找出影响项目变更的因素、判断项目变更范围是否已经发生等。进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况的绩效报告。

 

  (3)项目收尾阶段的总结控制

 

  能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。

 

  一个好的变更控制过程给项目的风险承担者提供了正式的建议需求变更机制。通过这此处理过程，项目经理可以在信息充分的条件下作出决策，这些决策通过控制产品生存期成本来增加客户和业务价值。通过变更控制过程来跟踪已建议变更的状态，确保不会丟失或忽略已建议的变更。变更控制过程并不是给变更设置障碍，相反，它是- 个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更产生的负面影响减到最小。

 

  以上就是软件需求变更-管理变更请求全文，希望对大家有所帮助！