|
综上所述，用户需求作为整个软件项目中最关键的一个输入，需求变更管理能否做到位自然就成为决定软件项目成败的关键因素之一。对于需求变更，除了从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们的意识和对需求变更的理解，主动做好对需求变更的控制和管理，减少“需求变更之痛”。项目管理者联盟
大家说项目管理者联盟
1、交易所事业部/李斌项目管理论坛
我的核心观点：变更并非坏事，事实上变更反而是必要的。事先将所有需求都定义好，几乎是不可能的。随着开发的进展，用户的思想也在变化，外部的环境变化和业务需要跟进。一个高效的团队要能够灵活应对变化，使其构建的软件可以及时为业务方提供价值。项目管理者联盟
以往众多的项目都发生过变更，变更的原因包括前期理解差异、业务规则变化、业务方想法发生变化、新功能增加、界面交互变化等。我们能做的就是尽量减少变更的发生，并在发生变更时也能很好的处理它。作为开发方，外部变化我们无法改变，我们能做的就是：正确获取需求，并正确的在团队内部传递。在正确获取需求方面，可考虑丰富调研的形式(原型、反讲、演示)，提高需求人员业务领域知识;在正确传递需求方面，可通过力求清晰形象地描述需求(UML建模)、需求反讲、需求验证等手段来实现。对于业务方提出的变更，我们也可以通过以下几点来管理好变更：项目管理者联盟
1)针对提出的需求变更在做出承诺之前经过深思熟虑的评估;项目经理圈子
2)由合适的人员针对提出的变更做出明智的业务决策;项目管理者联盟
3)变更管理活动对受到影响的干系人可见;项目管理者联盟
4)核准的变更会被通知到所有受到影响的项目参与者;pmp.mypm.net
5)项目组以一致且有效的方式处理需求变更。pmp.mypm.net
2、交易所事业部/郑力华项目经理博客
需求的变化在所难免，实际上用现在很流行的词儿"演化"去看，就顺利成章，没有什么会停止演化，除非要被淘汰。这样看来，需求如果还有变化就是一件好事儿，至少这个功能还被需要，还在被调整，从不完善趋近于完善。项目管理者联盟
应对变化的最好方式，就是要时刻保持这样一种“战斗”状态，随时都要准备为变化的需求做出调整。想在众多的日常工作中为某一个需求理出这么一块空间，就像杂乱的桌面上找出一块干净的地方放置新的事物，最好的办法就是让自己的桌面井井有条，让这个桌面随时欢迎新的成员加入进来。而一套好的需求管理办法就像这个整洁桌面的管理者——让变更的需求更加高效的加入到系统中来。pmp.mypm.net
3、交易所事业部/樊朝鹏项目管理者联盟
需求变更给各方带来的麻烦是有目共睹的，需求变更会给项目带来巨大的延期风险、质量风险、成本风险等。当然在项目中，需求变更往往是不可避免的，我们一方面需要尽量减少并控制需求变更的发生，另一方面，在需求变更发生时，我们应对需求变更进行有效的管理，最大可能的降低需求变更带来的风险。项目管理者联盟
为减少并控制需求变更的发生，我们可以从以下几个方面进行努力。转自项目管理者联盟
1)、明确需求范围，定义项目边界，防止需求无限扩大。项目管理者联盟
2)、需求调研要充分，用户往往提出的是表面需求，我们要与用户进行充分沟通，理解其真实需求，否则将会导致不充分的需求不断向下传递，风险不断扩大。转自项目管理者联盟
3)、在充分理解用户需求的基础上，对需求进行分析，给出解决方案并由项目经理、需求人员、开发人员、客户等相关方进行评审，需求人员应从业务角度让开发人员对需求有充分理解，尽量避免开发人员对需求理解不一致带来的偏差，最终由各方签字确认。
4)、在设计和开发过程中，发现的需求不足和模糊之处，要做到早发现、早沟通、早应对，不明确的地方要与客户、开发人员等各方多进行沟通，避免不明确的需求向下延伸。项目经理博客
4、交易所事业部/刘豪杰项目管理者联盟
项目前期对用户进行调研，确定用户需求，并通过需求分析得到产品需求，交付开发。但是在实际项目开展中，总会出现意想不到的需求变更，可能是现有需求的调整，也可能是需求范围的增加。pmp.mypm.net
痛点分析：项目管理者联盟文章
1)、现有需求的变更项目管理论坛
开发人员可能已经完成详细设计并完成开发，需求变更很大概率会造成返工，或者影响整个系统初期建立的数据库结构和框架。项目管理者联盟
|
