20011怎样从容应对客户需求反复.docVIP

客户为什么总是反反复复？ 在一个管理咨询或者服务的项目进行的过程中，咨询顾问总是希望与客户在最短的时间内就达成共识，但偏偏事与愿违，咨询顾问有时候苦恼：“客户怎么好象是反反复复、粘粘乎乎的”，比如，开始提需求的时候和顾问表达了三点意见，顾问开始做方案以后又告诉顾问两点详细说明，看到顾问的方案以后，客户好象受了启发，一下子又冒出了五点六点的需求要顾问实现。 所以，我们在这里想谈一个问题：客户为什么总是反反复复？ 还是借助系统工程的原理来分析。 系统工程的经典理论认为，系统分析过程的典型行为可以概括为下图所示的逻辑结构。 图1 系统分析过程的逻辑结构 它包括5个行动环节：（1）阐明问题；（2）谋划备选方案；（3）预测未来环境；（4）建模和估计后果；（5）比较备选方案。 整个过程可以归纳成三个阶段： ? 阐明问题阶段：其工作结果是提出目标，确定评价指标和约束条件； ? 分析研究阶段：提出各种备选方案并预计一旦实施后可能产生的后果； ? 评价比较阶段：将各方案的评价比较结果提供给决策者，作判断抉择的依据。 下面一句话就能呼应我们开始提出的“反复”问题了：“一项系统工作的分析过程中，每个行动环节一次即顺利完成的可能性是很小的，需要在反馈信息的基础上反复进行”（注意图中的几种必要的信息反馈回路，您如果感兴趣的话，可以结合图中的每一个箭头思考一下，这个箭头对应于一个管理咨询或者IT服务项目中的什么）。 所以呢，出现这样的情况就不奇怪了：决策者在弄清方案的后果以前，往往难以有把握地提出某项目标；在发现某些后果后有可能增加约束条件，筛选备选方案，调整方案的政策参数等。 因此，系统分析过程中的一个重要因素就是分析人员和决策者之间的沟通与对话。不断对话其实意味着决策者考虑了问题的各个方案，自我感觉亲自参与了分析过程，容易接纳分析结论，不至于因为出乎意料而拒绝。 因此，反复是正常的，关键在于，如何在反复中推进项目的良性发展。 如何应对客户的需求反复 在软件项目的研发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。我在自己的软件项目管理职业过程中，几乎天天面对用户的需求变更，切身感受到，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，用户的耐性渐渐消逝，研发人员的士气也越来越低落，最后所有的人都在等待一个结果：项目最好马上结束。所幸，在不断的学习和实践中，我总结了几点比较有效的方法，在软件研发阶段能够较好地解决这方面的问题。 1．需求分析阶段采用原型方法明确用户需求。在软件项目的需求分析阶段，有大量需求信息需要收集、筛选、加工，这是需求管理的开始。客户和研发两方面的人员对需求的理解呈现“大体上共识多，细节上差异多”的特点。即使通过反复沟通，最终在时间表限制之内也能拿出一份“用户需求说明书”，但是以实践经验，用户需求的描述永远是“不够清晰”、“不够明确”的。这主要是因为在这个阶段，所谓的产品都在大家的大脑中构思，正如100个人读《射雕英雄传》，就有100个郭靖的形象一样，每个人的想法都是大致轮廓相同，而细节差异很大。在此阶段，原型开发是一个较好的辅助手段，它将存在于大家头脑中的虚境实实在在地表达出来，一个界面，几个控件，外观形式固定了，功能描述明确了，这就是研发部门对用户的需求理解。此时与用户再次沟通，用户基本上可以说出来：“这是我想要的”，或者“不，这不是我想要的，我要的是……”。一般情况下，原型之后的需求沟通就实际得多，双方的理解迅速向一个折衷方案靠拢，一个可以指导研发过程的需求说明书正式诞生了。 2．需求分析之后的研发过程采用严格的需求变更管理流程。一旦需求分析阶段结束，此后如果用户要求有新的需求加入交付的软件系统中，需要走需求变更管理流程。这个流程必须在软件项目成立之初与用户约定好，一般的软件企业内部有需求变更的管理流程，可以向用户解释这种管理的必要性，直至与用户就此问题达成共识为止。不必担心用户不会接受，有过多次成功研发软件项目经验的需求变更管理流程，有着它不容置疑的合理性，这正是软件企业的经验和价值所在，用户最终会理解和同意的。需求变更管理流程各家企业有各家的做法，借用CMM的需求管理KPA来讲，需要两级需求变更管理委员会（以下简称CCB）来处理，即产品CCB和项目CCB。产品CCB处理涉及到产品一级的需求变化，主要体现在需要多个职能部门，多个软件项目，以及与其他产品线的协调等问题；项目CCB处理本项目内部的需求变更，如不同小组之间的协调，接口变化等等。每一个需求都要经过CCB的审批，决定这个需求的各种属性描述是否合适，如时间紧迫性，采用的技术是否有风险，对系