变更太疯狂，还是你项目管理的道行不够？

案例二：
        

       小陈是一个移动化软件开发项目的项目经理，他现在目前的项目状况是：

• 客户对未来的软件产品需求不是太清楚，希望小陈能够给出一些设计方案可供选择，但是每次提供的设计方案，客户代表都觉得不满意，但是会根据小陈的设计方案提出非常多有别于过去想法的新需求。
• 小陈在一次汇报会议上讲解了一套最新得到客户代表默许的设计方案，但是客户方的领导当即就表示出该设计方案不满意，要求重做。
• 项目组的成员也对小陈感到不满，认为付出了工作量，但是客户不认可的原因是因为小陈沟通做的不好，客户提出的一些“镀金”功能可以不必理会。

       这时，公司领导询问小陈项目状态，小陈应该如何处理？

分析：

      这是一个真实的项目案例，项目经理在项目中吃尽了苦头，左右为难，但是不知道如何破解这种尴尬的局面，也许处理这种困境不同的人有不同的处理方法，没有一个答案是最佳。分享一下当时处理这个项目案例时的分析和解决措施。

     小陈经理使用原型法去开发挖掘客户的需求，本身这个方式没有错。但是客户方的代表并不代表客户，客户由很多部门，很多人员组成，所以小陈的需求调研工作并不是让客户方代表满意。代表也许今天考虑到了A部门的要求，但是过两天听到了B部门的诉求，又改变了想法。这其实是一件按下葫芦浮起瓢的工作，继续就事论事的讨论方案就是吃力不讨好。

     所以传统经典的拟定需求调研计划，老老实实的去各个客户部门，不同的渠道获取需求才是上策，移动化的软件开发有个很定制化的内容，就是你要考虑很多工作场景，所以一个客户代表并不能列举全这些场景，所以要发动客户方的人员都参与需求的分析与整理。

     第二个问题是需求经常变，往往是项目目标存在不确定性，这个时候要做好项目的目标管理，所以多要和客户方的领导进行沟通。建议半个月正式汇报一次。

     第三个问题是需要尽量争取到客户方支持项目的人员在客户领导那里给出中肯的评价。这也是我们说的干系人要管理好。小陈没有和客户方的人员建立这种沟通机制。

    第四个问题，小陈应该把每次调研的情况好好的跟自己项目的人员进行沟通，多听取项目组人员对需求的分析，清楚的知道哪些需求是必须做的，哪些需求是可做可不做的，不然会消耗成员大量的精力。

   第五个问题，小陈没有做一份正式的需求确认的签字单，没有做好对项目范围的保护。

   根据上述5个问题，给小陈的建议是：

1.对客户的领导进行需求调研，搞清楚项目的目标。然后分析一下目前的方案是否满足项目的目标。

2.让客户方的代表组织项目参与或者受益的部门展开需求调研工作，形成完整的需求清单，然后将方案一项一项进行确认。

3.让项目组的成员一起参与给客户做方案介绍的工作，让方案汇报工作透明化，让大家多提改善意见。

4.对需求进行优先级排序，不是很必须的需求拉到一个改善型清单中。

5.做好需求的签字确认工作。

6.定期对客户方的领导进行项目进展情况的汇报。

       这是网上一个小哥哥总结的：

1. 接受变更不抵触
2. 需求前期充分讨论
3. 提前打预防针，说明变更成本高，项目延期等风险。
4. 达成共识形成书面文档，各方确认
5. 有明确的需求变更流程
6. 项目反馈和庆祝