（转）需求变动管理

  最近一直在想需求变动控制的事，资料也查了很多，但是查来查去，内容都差很少，无非是需求变动是必定要控制的，而且要通过申请、审批、执行、确认等流程， 几乎全部的资料给出的都是这样的内容，更多的，除了后面的流程以外，甚至连为何要作控制都没说明。下面说说个人理解。由于所管理的项目几乎都是以合同为 基础的外部客户项目，因此讨论内容仅限于此类项目中，由客户提出的需求变动的管理。

        为何要作需求变动的管理？

        进行需求变动管理的主要缘由有两个，一个是防止范围蔓延引发的进度、成本、质量上，甚至严重时致使项目全面失败的问题；另外一个是为之后留下筹码，之后要求 追加费用也好，或者让客户看到咱们送给他们的人情也好，总之是为了使之后与客户相关的工做更顺畅。除了这两个缘由以外，固然还有一些不是特别重要的缘由， 好比使需求、设计、开发、测试之间对变动的理解一直等等。

        需求变动管理的流程

        需求变动管理的流程，在绝大多数的资料中，第一步都是提出变动申请。事实上，在此以前，还有至少一件事要作，就是与客户一块儿，约定变动管理的流程，最好在 合同中约定，至少也要在启动会上约定。而变动申请的提出，也应该按照约定的流程来，不是由客户的任何一个角色直接提给项目组中的任何角色，而是客户处提出 的全部需求变动，都归总到客户处的需求变动负责人处，由负责人判断哪些须要做为需求变动提出，哪些不须要提出，须要提出的需求变动，由负责人提交给项目经 理。

        项目经理收到需求变动申请以后，要作的第一件事，不是审批，而是详细了解需求变动提出的来龙去脉和客户想经过需求变动解决什么问题，了解清楚这些以后，首 先尽量寻找系统外解决问题的办法，若实在找不到，或者系统外解决办法可行性过低时，再进行变动工做量的评估和影响的分析，分析完以后，才能进行变动的审 批。在全部的审批人中，销售人员起到很重要的做用，由于销售要给出变动所需费用的来源，并要给出承诺，不然变动没办法继续。其余审批人则根据本身的角色和 职责进行审批便可。

        审批完成以后，是执行环节。对绝大多数的变动，均可以不用立刻执行变动动做，能够几个变动做为一批一块儿执行，一方面能够下降频繁变动对项目工做的影响，另外一方面对一些客户一时兴起变过来过不久又变回去的变动能够起到拦截做用。

        再以后是确认，需求变动以后的原型，须要在修改完以后就确认，而最终变动结果，则在系统验收时，统一确认。

 

此博客来自：http://blog.csdn.net/violet200211/article/details/8612189

虽然针对需求是如何变动的没有说具体的流程，配置管理是怎么管理的，可是以为文章只是给出一个大题的思路很是好。