[转] 项目管理---项目经理如何应对客户的需求变更?

项目管理---项目经理如何应对客户的需求变更?

目录(?)[+]

相信做软件开发的我们,大家都有这样的体会,当我们辛辛苦苦的熬了几个月的通宵、加班后,终于完成了客户提出的V1.0功能需求,当我们大家准备按部就班的进行系统上线时,客户、企业用户突然改变了需求,不想这么做了,提出了新的需求,新的变动,这样对于我们整个团队来说,正如晴天霹雷,很恐怖的事情啊,因为有时候,用户只是简单的一句话,但是对于系统的调整来说工作量是非常大的。

需求变更,本应是客户的权力,但也是实施顾问的为难之处。如果确需变更,当然要满足客户需要。问题是不能让变更权力滥用,把一些无关痛痒的变更宠惯养成堂而皇之的变更。记得在做各个事业单位系统的时候,对于客户提出的变更,无论大小都给予解决,客户对此是非常满意,然而,项目进度却拖的很长,项目一再延期,这样导致开发小组中的部分成员有些不耐烦了,来一点需求,修改一点,这样确实很烦人的啊.

但是如何我们对客户的要求一概不理,自顾自地按照最初的需求和计划实施,最终很可能由于没有用户的参与,使得系统与用户的需求相差甚远,导致验收通不过,公司的利益受损,对于客户来说,达不到需求的满足也浪费了投资事实上,客户不满意,则项目就不算成功,实施顾问辛勤劳动最后就只能落得个"没有功劳,只有苦劳"的份。

但按前一种"谦虚型"做法,完全顺着客户的意见走,客户满意度就一定会高吗?其实也不一定。由于需求变更会带来工作量的大量增加,甚至可能会出现大量的无效劳动。而且,频繁变动的需求也会导致实施质量下降,留下许多隐患。因此,一味的迁就用户将会使进度一拖再拖,实施方案一改再改,变更越来越多,士气越来越疲,公司越来越不满意,用户越来越急。到最后,实施顾问会发现这个项目已经成为了一个"不可能完成的任务"。

需求变更为什么总是做不完呢?

现实中的软件开发就是这样,新开发的软件不可能一次性全部都提出来,可能客户自己都不知道自己想要开发软件是什么样子,只是简单的实现他自己的功能,咱们做出来的V1.0使他们逐步的有意识的帮助他们理清这个软件的样子。

需求变更的表现形式是多方面的,如客户临时改变想法、客户的习惯、项目预算增加或减少、国家政策的改变、客户对功能需求改变等。

我们要正确的认识客户的这种需求变更,应以对等的心态来面对!

需求变更引发的一系列问题:

 1:需求模糊了

在我们开发软件的过程中,对客户的工作环境、流程的不熟悉,对业务了解的不深刻以及政府部门的项目经常受国家的政策的变动而影响等等,我们拿不准客户真正想做什么了?来回的变动使我们有些迷茫。

2:系统的灵活性差

满足客户的工作习惯、新功能的拓展、算法的灵活性、细节的增删改查,极大的反应了系统的灵活性太差啦,后期的维护基本上都是超过开发时间的两三倍时间。

3:开发周期延长

需求的变更,使得开发周期延长给开发小组人员一种意识类似进入了开发周期"无期徒刑",大家毕竟每个人的事情任务也很多,需求的变更,导致了开发周期的加长,修改这个、又改那个,修改这个对其他部分的影响变动很大,系统各个部分的耦合性太大了。

没有阶段性成功的标志,每天在加班加班中进展的度过,应该项目经理给一周应有一个总结性的会议,展示一下大家自己的成果,也算是给自己的奖励吧。

4:开发人员心态变化

大家不淡定了,着急了,慌了,不想干了、个人心情会影响到整个团队、团队的士气低下,大家开不足马力来工作了,这样势必会影响整体开发的进度。

5:自身定位不足

我们不是一个人在干一件事,是整个团队再做,不是自己那一部分完成了,就完事大吉了,组员之间要互相交流,沟通好相互交互的部分,为了我们的项目顺利达标完成!

问题---总括

面对用户需求的频繁变化,我们hold不住了,不能正确的面对,老是觉得客户的变更是不对的……

当然我们要静下心来证实一点:客户的需求变更是对的,满足其工作需求、现实中的系统需求不可能一次性的全部提出,因此我们要以对等的心态来面对客户的需求。

应对方案

1:架构方面

重思设计理念、架构的使用、系统设计要灵活。

2:文档跟进

(1)合同签订马虎,没有真正明白客户需求

(2)调研时没有深入理解客户需求

(3)没有明确的需求变更管理流程确认客户是否接受变更的代价

3:对需求变更的主动管理

(1) :成立变更控制委员会CCB

(2) :严格执行

(3) :互换角度,为公司利益着想

4:零星变更,集中处理

(1) :对于零星变更,集中研究、批量处理

(2) :严格执行

(3) :互换角度,为公司利益着想

5:敏捷开发

使用敏捷开发的思想作为指导来应对客户的变更,这个需要大家实施体会……

措施实施的过程当中应当注意的问题

(1)合同签订马虎,没有真正明白客户需求

签订合同时缺乏对客户需求认真对待,导致需求描述不清,为后期的实施工作带来困惑。为使客户能够快速的签订合同,往往草率决定和片面同意客户提出的需求。当客户提出新的需求时,往往是销售顾问一看"应该"只是一个小小的修改,没有太大的影响,所以直接答应能变更。

该问题的关键是合同签署的太烂,没有把需求明确再签合同,而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚,后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围,可以为以后各项实施工作的开展奠定深厚的基础。

(2)调研时没有深入理解客户需求

不熟悉可以的真正的工作环境、工作流程,在需求调研分析阶段,项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进行。更严重的是,实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案,没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导一拍脑袋提出新的需求时,实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分,双方对需求的理解就会产生差异,就会导致移交进销存系统时才使问题暴露出来,客户只能频繁的提出需求变更。

 (3)没有明确的需求变更管理流程

没有明确的需求变更管理流程,就会使需求变更变得泛滥。并不是所有的变更都要修改,也不是所有变更都要立刻修改,需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。

界面风格问题,就可以先不修改,或者规划一下修改的时间待到以后进行优化。另外,对于核心模块的修改没有严格把关流程,有些小需求看起来工作量不大,但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。

更好的约束客户

(1)合同制(虽说没有法律效益,但是在一定程度上可以约束客户),咱们以后要让客户知道需求变更的代价;在和客户接触时应该挑明态度,特别是要让他们清楚需求随意变更所带来的代价和风险。如果客户认为代价太大,那么开发人 员就没有必要及时修改,按原来的进度走,但仍要记录变更,待下一版本在修改。
 (2)确认客户是否接受变更的代价
  (3)每月变更记录上报双方领导

最后,实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案,可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权,逐步让不合理的随意频繁变更,成为客户不好意思开口的尴尬事件,尽快形成正常的项目执行氛围和良好的工作习惯,也为可能受到变更所带来的责任问题留下伏笔。

拓展思想反思

(1)与客户交流要耐心,学会如何来维持客户。

(2)心态的成长、客户交流的能力、技术的娴熟,最主要的心态、客户沟通的能力才是我们最需要锻炼的,珍惜这样的机会吧、项目开发、项目的维护、客户交流的机会处处我们再得到锻炼。

项目管理是作为项目经理必备的素质,通过这样的机会,好好学习,为以后的工作中搭好桥梁的作用、快速成长!,接下来会逐步的学习一些项目管理的知识和大家分享!

http://blog.csdn.net/lishehe/article/details/22036893

时间: 04-13

[转] 项目管理---项目经理如何应对客户的需求变更?的相关文章

《小团队项目管理》第三问 --- 如何看待客户的需求变更?

作为一名码农,在项目开发过程中经常会涉及到项目的需求变更,变更的理由也是多种多样,总结而来分为外部和内部,从外部讲,例如:为了顺应某行业新的工作操作规范,甲方要求现有项目在工作流程环节上进行局部功能的变更:从内部讲,通过对市场环境的不间断调研和数据分析,公司产品在同类产品竞争中处于不利地位,市场份额日渐缩小,那么我们的产品设计人员会积极行动起来对产品的整个定位和新业务展开新的思考以寻求更加稳健的创新突破口,这就会对项目产生一定的需求变更. 此图是从CSDN社区截取下的,我相信很多看到这个问题的筒

摆平客户的需求变更之表单扩展属性

客户永远是对的!客户的需求永远是多变的! 需求说明文档写得再详细,说改还得改,程序猿永远这么苦逼. 为了应对客户多变的需求,今天先说说表单的扩展属性.目的是在不修改代码,不重新发布程序的情况下完成表单的扩展. 先下下图: 从这个界面上可以定义如何对表单上进行扩展,在表单上增加一个什么控件,大小.内容.验证都可以的. DEMO地址:http://121.40.148.178:8080/ . 用户名:guest,密码:123456 是的,如果是下拉框的话还能绑定数据源,选择就可以完成,绑定了数据字典

项目经理的能力培养

http://pm.csai.cn/manager/200902260957051467.htm 概述 摘要:本文重实际项目建设出发,论述项目经理在项目建设过程,应该注视哪些方面的能力和技巧.2006年,我参与青岛是应急联动指挥系统的建设.作为项目经理,我总结和体会了一套项目经理管理经验和技巧.主要体现在以下几个方面: 一.项目经理要有较强的观察分析能力,能够透过现象看本质,规划出执行步骤和措施: 二.项目经理需要有较强的经算能力,能够掌握具体任务的成本.工期及进度: 三.项目经理需要思路清晰表

软件行业项目经理主要的职责是什么?(转)

项目经理职责:1. 基本职责就是确保项目目标的实现,领导项目团队准时.优质地完成全部工作.2. 与客户沟通,了解项目的整体需求.并与客户保持一定的联系,即时反馈阶段性的成果,和即时更改客户提出的合理需求.3. 制定项目开发计划文档,量化任务,并合理分配给相应的人员.4. 跟踪项目的进度,协调项目组成员之间的合作.5. 监督产生项目进展各阶段的文档,并与QA即时沟通,保证文档的完整和规范.6. 开发过程中的需求变更,项目经理需要跟客户了解需求,在无法判断新的需求对项目的整理影响程度的情况下,需同项

如何控制项目需求变更管理

Trufun UML2建模工具.Trufun Bacon  需求管理工具. Trufun ALM全生命周期产品.Trufun 研发云管理工具等 按照现代项目管理的概念,一个项目的生命周期分为启动.实施.收尾三个过程.需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程.为了将项目变更的影响降低到最小,就需要采用综合变更控制方法.综合变更控制主要内容有找出影响项目变更的因素.判断项目变更范围是否已经发生等. 进行综合变更控制的主要依据是项目计划.变更请求和提供了项目

项目经理与客户沟通的宜与忌

原文引自:http://www.leadge.com/djnews/news//2006112093827-3.htm 我们知道,项目经理有75%到90%的时间用于沟通,可见沟通在项目管理中的重要性.然而,项目经理的沟通工作中,与客户的沟通尤为关键,因为它在很大程度上决定了项目的成败. 本文从作者的经验出发,总结和分析了与客户沟通的五宜和五忌:宜谦虚礼让,忌“据理力争”.宜换位思考,忌刻意说服.宜留有缓冲,忌当场回绝.宜主题明确,忌海阔天空.宜当面沟通,忌背后议论.期望这五宜五忌能为项目经理在与

需求管理之项目经理与客户沟通的宜与忌

     摘要: 我们知道,项目经理有75%到90%的时间用于沟通,可见沟通在项目管理中的重要性.然而,项目经理的沟通工作中,与客户的沟通尤为关键,因为它在很大程度上决定了项目的成败.    本文从作者的经验出发,总结和分析了与客户沟通的五宜和五忌:宜谦虚礼让,忌"据理力争".宜换位思考,忌刻意说服.宜留有缓冲,忌当场回绝.宜主题明确,忌海阔天空.宜当面沟通,忌背后议论.期望这五宜五忌能为项目经理在与客户的沟通过程中带来帮助.   一. 宜谦虚礼让,忌"据理力争"

项目经理分享深圳证券交易所IT项目管理的成熟经验

深圳证券交易所(以下简称深交所)的IT工程部门每年均有上百个项目需要开展.不同的项目对应的是不同的项目经理,而每个项目经理的技能和经验又有差异. 如何让项目经理们能够更好.更快.更节省地执行和完成项目,是困扰深交所各层领导的难题.最近10年,深交所一直在探索.尝试.改进,最终形成了一套适合自身的完善的项目管理体系和机制. 作为全程负责深交所项目管理系统项目的PM,笔者与这套系统的"人机和谐共处"已经将近8年,本着交流分享精神,笔者希望将深交所在IT项目管理方面的成功经验与大家分享探讨,

从备考PMP到与项目经理同呼吸

前言 PMP是什么梗? 项目管理专业人士资格认证.它是由美国项目管理协会(Project Management Institute(PMI)发起的,严格评估项目管理人员知识技能是否具有高品质的资格认证考试.其目的是为了给项目管理人员提供统一的行业标准.目前,美国项目管理协会建立的认证考试有:PMP(项目管理师)和CAPM(项目管理助理师)已在全世界190多个国家和地区设立了认证考试机构. 可能有一部分程序员伙伴不了解PMP是什么?但应该没有撸码的不知道项目经理这个称谓吧?记得在学校时,老师给我们