变更管理

flash

对于软件开发项目中，需求频繁的变更，各位大虾是如何管理？

rabing

还有，在工程管理中，也经常出现的问。困惑中。

扬子

很好的问题, 个人浅见是:

1. 事先与客户的沟通( 需求分析 ) 没做好;
2. 工作范围界定, 合同约束 ---- 要改得付钱 !
3. 引导客户在下一期工程里面处理变更..

当然, 国内甲方乙方的地位是大爷与孙子, 不尊重合同, 这样的环境下上面的想法也很难实施.

marsoon

其实变更是很正常的，但是频繁的变更一定有它不正常的一面。

这里存在扬子兄说的“事先与客户的沟通( 需求分析 ) 没做好”；但是往往存在着另外的可能，比如商务，这一点我想tulip比我更有发言权了，呵呵。

想说的是如何应对：
1 正常的变更有变更处理流程，这一点应该在项目初期有所约定；
2 非正常而且非商务因素的：
  a 逾期，自有合同约束，当然，维护期是跑不了了，；－）
  b 在合同范围内，引导客户进行需求的累计（往往客户都不知道自己的需求是什么，引导他们寻找真正的需求，对自己对客户都很有意义），然后进行变更确认书的确认；如果项目存在时间上的限制（比如马上就要验收了），看看是否可以采用扬子的办法，引导客户到下一阶段完成。

其实，在项目拿到的初期，作为项目经理，除了技术性因素之外，很多其他因素也应该早早进行合理运用的。

tulip

呵呵，既然大虾都发言啦，偶这小鱼儿也来凑凑份子吧！

变更在项目中不可避免，但是频繁的变更在中国的甲方大爷市场的情况下，总是让我们这些乙方苦不堪言。

客户的需求永远都在变，客户的需求没有一个度永远无法满足
不管怎样，还是要理清导致变频繁更的根本因素是什么？
1、投标中为了拿下项目，相关人员向客户许下很高的系统功能承诺；
2、应标中，为了符合客户的要求，在技术协议中承诺一切都可以做到；
3、中标后，技术协议没有明确描述乙方能够做到的功能，含糊不清，没有界定；
4、实施中的需求调研分析，没有摸清客户的需求；
5、实施中，对客户变更需求的引导不理想，甚至失败；
6、因为商务的因素，导致项目的需求不断变化，乙方也不断修改满足客户；
7、最可怕的就是所谓市场的占有因素，导致项目的被动，频繁的被动接受变更。

分析清楚频繁变更的原因，思量解决的最佳措施，以便达到扬子说的：
1、工作范围界定, 合同约束 ---- 要改得付钱 !
2、引导客户在下一期工程里面处理变更..

至于应对频繁变更的方法，marsoon已经有了建议
这里只想补充一下：
1、不管商务情况如何，前期的技术协议一定要明确描述乙方可以做到的功能；
2、凡是与客户沟通确认的变更要严格按照文档备案流程操作；
3、随时和技术协议核对，客户的变更是否在协议范围内；
4、有了资料，客户不合理变更提出或是次数过多时，可以就此和客户交涉，讨论追加费用还是不作如此变更还是引导此变更移至二期工程；
5、既然有商务因素导致频繁变更，也可以利用商务因素减少频繁的变更，就看项目经理如何利用资源；
6、实施中对客户的需求引导非常重要，要求现场实施人员发挥相应作用；
6、很多项目经理实在项目准备实施时参与进来，基本以技术性人员为主，应该对于项目的整体情况和相关资源尽量多了解，利用多方资源早早进行合理运用。

说千言道万语，项目的技术文档和商务资源的合理运用非常重要
如果能相应做到，可能
1、追加投资
2、变更导入二期项目
就会逐渐变成一种可能
既然我们是在中国的国情下的项目，那就按照中国的国情来操作吧..[em08]

呵呵，感觉有很都细节的问题都可以尽量减少变更，偶们一起在项目中慢慢体会吧
沟通管理和人力资源的管理可以起到辅助作用[em08]

个人感受，希望大家一起讨论[em07]

marsoon

提到甲方，顺便说几句。
应该说甲方大爷的现象虽然在中国屡见不鲜，但是也应该看到甲方在项目中越来越成熟的一面，比如酝酿项目阶段，甲方越来越务实，这体现在甲方咨询市场的蓬勃发展。

相信随着企业自发性行为的增加、外在市场环境和甲乙双方的成熟，频繁变更这种问题会得到根本的解决的。

疯风

个人意见:需求频繁变更的原因有:
1、甲方的随意性。甲方在立项时根本就没有明确自己的目标和具体要求，随着项目的深入，甲方考虑的时间与考虑面在量上都会有大幅度的提升，需求细化后也会导致变动机率增加。今天想到一点，明天想到一点，也的确是好的改进方案但实施过程就没有这么轻松了。
2、甲方主管的能力。甲方主管在项目实施过程中，为了显示自己高人一筹的能力，往往会提出一些超过预期约定的要求。
3、甲方的工作习惯。日久思变思的是一个局部的变化。如果在短期内他所熟悉的体系产品变革，会不自觉产生抵制感，希望能按照他所熟悉的流程、工作方式，或者是工作界面去修改。
4、甲方主管醉翁之意不在酒。
5、市场与技术脱节。为了各自的利益，市场与技术自然会形成两个不同的阵营。普遍见到的是，市场部会承诺实现客户所有要求，技术部则在考虑修改的资源投入。以软件为例，修改时间越长，功能愈能符合客户需求，同时也表示技术部工作愈没效率。
6、双方在没有明确地需求分析的情况下就上马项目。
7、项目执行过程中对可变因素的控制力度差，或没有预期到可变因素的发生。
8、目标界定错误
其他的一时还没想到。

对于这些引起变更的因素，控制的方法各位虾客虾女已经说得很多，不才在此也多废话几句：
1、明确目标，知道自己能做什么，要做什么。
2、明确目标实施步骤，分析其可能出现的变素，并据此确定相关对策
3、项目规划时让甲方充分参与，项目执行过程中有选择地允许甲方参与
4、全程文档管理
5、明确的目标界定
6、懂得在适当的时候说不
7、人情管理与公共关系管理。比较适合国情。

欢迎指正。