|
成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念—“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。项目管理者联盟
能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累， 即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。项目管理者联盟
事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。项目管理者联盟
需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤:提出变更->变更评估->实施变更。图1简要地描述了一般需求变更的处理流程。项目管理者联盟
CMM提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。项目管理者联盟
实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候再引入相应的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。项目管理者联盟
打破模糊的、暧昧的、没有文档化的需求是一种伟大的挑战，但是制订坚持遵守的承诺并实践它，则是个更加巨大的挑战。项目管理者联盟
8、控制需求渐变需要注意的问题bbs.mypm.net
◆需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。项目管理者联盟
◆小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程， 认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。项目管理者联盟
◆精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。项目管理者联盟
◆注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点问题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。转自项目管理者联盟
◆ 需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。项目管理者联盟 training.mypm.net
|
