讨论如何应对用户需求的变更

[hzcao]

项目经理经常要面对用户需求的变更，如果已经进入了开发阶段，用户突然对需求发生了根本的变化导致整个系统都需要推翻重做。

如果用户提出这样的变更，你如何应对？请各位从实际工作中讨论如何解决此问题，以及此问题带来的风险和危害！

[bizi]

如楼上所讲，先看下“根本的变化”是什么。如果是把项目目标都改变了，那就再起一个项目另收一份钱~~，呵呵
也有可能是部分功能要求需要修改，但你们觉得为了修改这些功能，需要牵扯了项目太多地方。这种情况，冷静再冷静，好好分析，请一些局外人帮忙分析，呵呵，说不定会有一些取巧方法可以避免。

基本上碰到这种情况，只有使用楼上所说的。冷静的进行变更管理。不过不一定能有好结果~~

当然，应付过了这一关，更重要的是后面的事，亡羊补牢。找出出现这种问题的根本原因，考虑以后如何避免，这才是王道

[CQ_Kevin]

变更不是犯了什么失误，所以我个人觉得亡羊补牢这个词不是很恰当，楼上所说的避免，我很早以前做项目的时候也试图尽力去避免过，但是结果基本是徒劳，变更不可能不发生，所以只有面对了，只是经过一些时间项目的锤炼之后，随着自己对需求更全面和深入的理解，发现其实以前很多自己遇到的“变更”其实算不上真正意义上的变更，如果一个需求，能被双方理解和共识，这种情况下一方提出修改意见，这应该是无可厚非的变更，但是很多情况下，我们的需求人员由于技术能力限制，其需求的描述很不准确，而且在客户和用户那里获得的承诺也是很模糊的时候，这种情况下，开发人员所做的东西基本上有很大程度上是开发人员的主观思维结果，这样的东西如果客户或者用户不接受，提出不同的方案，你能说这事“变更”？？？？他们改变了什么他们承诺的东西？？

[kelph]

只接受一定范围内的需求变更。
客户需为大的需求变更所导致的开发周期增长，成本加大负责。

合同中应有所规定。

[CQ_Kevin]

何谓“根本的变化”？？？打个比方，如果将项目的目标确定为开发一个人事关系系统，根本性的变化基本可以认为客户现在不要人事管理系统了，转而要求开发库存管理系统，这就是所谓的根本的变化。
我基本遇到的需求变化都是所谓的“蠕变”，即在项目目标稳定的情况下，对于产品部件的功能和性能等要求作出细微的变化。
对于这样的蠕变，首先完整的记录客户或者用户的变更请求，然后分析和评估该变更对现有工作的影响范围，评价其业务和技术风险，估算变更导致的进度延迟和资金追加，然后召开由客户和用户代表参与的变更评审会议，如果变更通过评审，并且在当前开发计划周期内，就并入开发计划，如果不在当前周期，就排入队列等待适当周期并入开发计划，如果未能通过评审，则将评审结论通知变更请求人，拒绝变更。

当然，这并不是说我所理解的你所说的那种“根本的变化”不会发生，虽然及其罕见，但是也必须要有预案，对于根本性的变化，基本上项目经理层面无法解决，必须通过公司高层和市场人员与对方客户高层进一步明确合同目标的问题，这里不多阐述了。

如果希望做更多的交流，QQ：476355016

[kelph]

恩，变更管理很重要。

[homesos]

楼上的兄弟们所说的都无法解决什么实际问题。

还是都去学习一下需求管理吧，实践后再来讨论吧。

[foreveryday007]

学习中

[Elemer]

需求变更问题从根本上要解决是从需求收集和需求分析上多下功夫。

因为需求变更导致整个系统需要推翻从来只能说是两种可能：需求收集没有做到位，导致只了解到客户的表面需求，没了解到客户深层次的需求；需求分析和系统设计有缺陷，耦合性太强或者是只作表面功夫，没有好好设计系统。

如果发现需要推翻整个系统从来的时候，你只是为你前期工作的不认真负责买单，这时候已经是谈不上需求变更管理的控制了，因为客户变更需求只是从比较小的层面或表面上改变，并不是深层次的改变他们的需求，这时你们只有付出代价和学习教训，没有更好的办法解决。

[jerryxuyu]

用户突然对需求发生了根本的变化导致整个系统都需要推翻重做

先区分好责任 是谁发生了变化 为什么要变化
是否要尊重合同的技术附件

然后再决定是否要进行变化,1 是不变 按既定的办 这个可能直接对立
2 接受变化 但是怎么变要讲清楚
重新制定合同条款 对前期的工作买单

而且变化之后 对乙方的生产 都造成了很大的影响 这些因素等等 都是商务上需要谈判的