| 【相关分析】（27个分析） |
|
|
时间：2011-07-09
题目：项目需求变更较多如何控制
分析：其实像案例中描述的系统，需求方面已经不存在很大的问题，所以才会导致"细微的变动"。
这些细节上的变化，也许仅仅是一些用户习惯等等，而提出变更请求的用户，也未必能代表其他用户的意见，需要让他们内部先充分讨论，让用户领导确认，明确成本，避免往复修改。
再者，用户和客户的概念也是不一样的，只要不是客户，用户提到，可以再做做工作嘛~~~~~
|
|
|
时间：2011-07-09
题目：利用人的惰性解决问题，以大欺小的解决问题
分析：1、小的细节的修改是无止境的，换一个人整个操作的习惯都是不一样，所以肯定不能以修改为目的这样改下去。
2、项目经理的职责要发挥出来，不要把实施人员挡在前面，他们的发火其实侧面反映了项目经理的不作为。
3、掌握客户关键人，例如部门的经理、副经理，他们的切身需求才能对你的修改有个定论，说服他们上线后细节方面会慢慢调整。
4、定期向客户大领导做汇报，让其对项目的进度了解，对上线造成阻碍的因素有所知晓。他们对项目的进度相比也是比较迫切的，届时会对其所属员工有所施压。（注意要潜移默化的影响他们的BOSS，不要以打小报告的方式，否则后面的工作必定遭到下面员工的抵制）
5、施压之下再对相应的需求做一些必要的改动，增加操作人员、业务相关对软件和实施公司的信任度。
6、需求提交的工作转嫁给客户，让他们把自己的想法详细的写下来，此项工作看起来虽小，但是很关键。客户常常因为怕麻烦，就将就了软件，懒的去提了，这样他们自己不提了，习惯了软件的操作就没有什么问题了。
|
|
|
时间：2011-06-22
题目：多沟通
分析：增加变更需求的控制，多与用户沟通，确保每次需求的确定
|
|
|
时间：2011-02-14
题目：问题不大
分析：需求做的不错。
工作量再小都要进行记录和确认，防止影响基线需求。
这种情况在政府行业尤为多件。
|
|
|
时间：2011-01-28
题目：细微的变动
分析：其实像案例中描述的系统，需求方面已经不存在很大的问题，所以才会导致"细微的变动"。
这些细节上的变化，也许仅仅是一些用户习惯等等，而提出变更请求的用户，也未必能代表其他用户的意见，需要让他们内部先充分讨论，让用户领导确认，明确成本，避免往复修改。
再者，用户和客户的概念也是不一样的，只要不是客户，用户提到，可以再做做工作嘛~~~~~
|
|
|
时间：2010-03-30
题目：变更控制要有技巧
分析：其实像案例中描述的系统，需求方面已经不存在很大的问题，所以才会导致"细微的变动"。
这些细节上的变化，也许仅仅是一些用户习惯等等，而提出变更请求的用户，也未必能代表其他用户的意见，需要让他们内部先充分讨论，让用户领导确认，明确成本，避免往复修改。
再者，用户和客户的概念也是不一样的，只要不是客户，用户提到，可以再做做工作嘛~~~~~
|
|
|
时间：2010-03-23
题目：制定变更流程
分析：可能的原因：
1、需求调研分析不到位。客户不会无缘无故变动，要么是之前没有做到位，要么就是政策发生了变化，目前来看应该是前者；
2、没有变更流程。任何的变更都应该有流程，没有规矩不成方圆，我相信客户也应该能理解；
3、实施时，同客户交流的不到位。特别是一些细节的问题，交流时尽量全面； 处理方法：
1、建立需求变更流程，变更单表明修改内容，工作量大小，双方签字确认（对于当前这个项目，多次变更后就可以把这个单子拿出来同客户交流，情况好的话可以拿到一些补偿，情况差的也能体现实施方的辛苦工作）；
2、需求交流，尽量能讨论的仔细一些，避免以后现在的情况；
3、在项目开始时就确定关于变更的处理方法，如是项目内做，还是项目外做，允许项目内变更多少工作量等等。
|
|
|
时间：2010-03-16
题目：项目客户需求无止化
分析：我前几年做个政府项目的时候也有同感，在项目中如何控制客户需求的无止化在实践确实很讲究。
|
|
|
时间：2010-03-12
题目：做好需求管理和变更
分析：客户对于需求的变更往往是比较随意的，必须要控制好项目范围，有需求变更一定要记录和确认，得到客户的认可，同时项目实施进度要合理，项目拖延往往是客户需求变更较大的原因之一。
|
|
|
时间：2010-01-24
题目：变更引起的额外成本要获得甲方认可
分析：如果是建筑这一块，一旦有变更要尽早拿到甲方的签证以便结算用，不知道It是否可以这样
|
|
