刚刚看到有个哥们儿讲他的客户让他很郁闷,我有点想法,整理如下:

首先,我觉得开发人员遇到这样的郁闷是因为控制需求变更功夫没有做足。原因有几点:
1.涉及需求变更的东西不应该由最终使用的用户和一线开发人员来沟通,这样的沟通费时费力而且不具有权威性。
2.开发人员直接向客户汇报的工作量往往比实际工作量要低,而且低的比较多。原因很简单:客户问开发人员一个功能是否困难的时候,一般技术人员往往只考虑了单项功能的复杂度,而可能对这个需求变更对整个系统的工作量估计不足(比如美工的工作量、该功能引发的管理功能的工作量、测试工作量等等)。
这种情况会对项目产生多个负面影响:a.向客户提供一个低于实际值的工作量,导致客户期望高,而实际无法按时完成导致客户失望大,降低用户满意度。b.因为客户从开发人员口中听到的工作量总是比从项目经理口中听到的工作量低,造成客户对项目组内部不一致,沟通不足的感觉。c.因为客户从开发人员口中听到的工作量总是比从项目经理口中听到的工作量低,引诱客户喜欢直接向开发人员提出需求变更,造成恶性循环,直接导致了项目组没法按时拿到奖金,士气下降。

所以对于客户提出的需求变更,一般技术人员最好的处理方式是:委婉的告诉客户,这个问题需要项目经理来评估。哪怕用户用挑衅、教训的语气和你讲这个功能如何简单,如何如何就可以实现,你都不能告诉他是否可以接受这个变更,更不能说实现需要多长时间。
拒绝了客户之后并不是大功告成,你最好能够早于客户通知自己的项目经理,客户想进行怎样的需求变更,你自己对工作量的评估是怎么样的。这样可以给项目经理一个准备时间,来完善的考虑需求变更的影响。

对于项目经理,尤其是从开发一线转向做项目经理的兄弟,应该主动的从项目全局来考虑一个变更的影响,而不是单纯从技术角度考虑。最好能按照公司的规范和制度以及项目实际情况为自己积累一份check list,以免在考虑需求变更时遗漏一些事项。作为开发方更要强化对于需求变更的控制。
控制需求变更最理想的办法当然是由客户方、开发方的项目经理和需求顾问共同组织CCB(变更控制委员会)
,文档化所有需求变更,双方签字然后归档需求变更。不过这样比较难以实现。但是最起码的要求是,必须由客户方项目经理(也就是甲方最终用户需要把需求变更汇总报告给甲方项目经理)向开发方项目经理提出需求变更,开发方项目经理评估工作量,并文档化需求变更,在与客户方负责人充分沟通后,使用正式方式将沟通结果(最好是打印出来给甲方签字,最起码是要求回执的电子邮件)通知客户。必要的时候需要业务人员协助,比如要求签署附加合同或者新开一个项目等等。

从我做项目几年的经验来看,蛮不讲理的客户不是没有,但是是极少数,大多数客户,尤其是客户方项目经理都是通情达理的人。所以,只要你言之有理,对方都有可能接纳。

Feedback

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-05 19:45 by itspy
所以对于客户提出的需求变更,一般技术人员最好的处理方式是:委婉的告诉客户,这个问题需要项目经理来评估。哪怕用户用挑衅、教训的语气和你讲这个功能如何简单,如何如何就可以实现,你都不能告诉他是否可以接受这个变更,更不能说实现需要多长时间。
拒绝了客户之后并不是大功告成,你最好能够早于客户通知自己的项目经理,客户想进行怎样的需求变更,你自己对工作量的评估是怎么样的。这样可以给项目经理一个准备时间,来完善的考虑需求变更的影响。


同意!

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-05 21:05 by 冷面阎罗
对啊,我也遇到这样的情况,我们是客户领导说一样,实际用的说的又是一样,上次作一个东西,还没作完就改了7.8此

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-05 21:44 by iceboundrock
@冷面阎罗
遇到这样的,就要给他变更造成阻力,不能让他随意变更。
如果客户给项目造成很多困扰,而项目项目经理搞不定,可以向业务人员反馈。一般来说,业务与客户的私人关系肯定好过项目经理和客户的私人关系。他们有他们的渠道来和客户沟通。
如果业务不管,可以继续向高层反馈,毕竟项目拖久了,公司也是受害者。

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 10:49 by 冷面阎罗
@iceboundrock
是啊,我们也想这样啊,不过客户有个大领导一下令,我们这边又不得不该,该了后下面的实用者又打电话说这不好那不好,主要是领导想着完美却没有想实用,最后的结果就是苦了我们这些程序员了.

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 11:42 by iceboundrock
@冷面阎罗
如果客户提的需求你觉得有问题,你最好把你的想法整理清楚之后去和项目经理谈,让他去说服用户,或者向更高层的领导汇报。把利害关系分析清楚,我想没有那个公司想赔钱的。是吧。
但是,如果你一边觉得有问题,一边又不说话只是埋头苦干,那只有哑巴吃黄莲了。程序员除了技术,沟通也是非常重要的,尤其到了项目后期,沟通的重要性远远高于技术。

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 13:08 by 心内求法
可以采用这样的做法:在项目启动时期,把需求变更流程作为一个重要文档与客户沟通(客户需求变更整理-正式文档提交-项目经理意见及工作量评估-公司审批(当涉及比较大的工作量的时候)-变更回复-变更执行)
先制定这么一个流程,双方认可
然后在实际变更发生的时候严格按照这个流程处理。

相关内容可参考:
软件不软:需求变更与代码质量:http://www.blogjava.net/wanghaikuo/archive/2006/11/29/84355.aspx

项目时间——你会讨价还价吗?:http://www.blogjava.net/wanghaikuo/archive/2006/11/02/78698.aspx

欢迎展开这方面的讨论,让软件行业逐渐规范起来,呵呵

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 15:16 by iceboundrock
@心内求法
从理论上,这样是很完美的。但是很难坚持下去,因为一般来说国内的软件项目,客户和开发方根本就不平等。所以只有开发方多做一些工作了,经常与客户沟通,摆事实讲道理,呵呵。

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 15:19 by 心内求法
@iceboundrock
是啊,还需要我等多多努力,任重道远啊:)

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 15:33 by 冷面阎罗
@心内求法
同志啊,国内项目接触客户比较多,这也是一种锻炼.交流的艺术

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 17:39 by iceboundrock
@冷面阎罗
没错的,项目经理与客户沟通是门艺术。
与客户经常沟通的效果往往胜过合同条款(如果到了非得拿出合同说事的程度,项目基本上就完蛋了)。总之,客户的目标就是尽量少花钱多办事。而开发方的目标就是能不改就不改(降低成本啊),即使非得要改,也要说的让客户觉得欠了你很大一个人情似的(为下一次他们再提出需求变更做好准备)。中间具体怎么沟通达到双赢,就看个人的本事了。

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更  回复  更多评论   

2006-12-06 17:57 by 心内求法
@冷面阎罗
提高沟通是必需的,但是做事情也要“有章法”“讲套路”,在这样的前提下能够更有效的沟通,避免扯皮。对吧。另外,俺也是在国内呀,呵呵

# re: 如何对付令人郁闷的客户 之 如何处理客户提出的需求变更[未登录]  回复  更多评论   

2007-06-23 04:47 by robin
需求变更必须经过项目经理或指定人,不能直接由客户要求程序员修改,我想这是最基础的。
用户签证确认也是可以实施的,一般用户都会配合。

只有注册用户登录后才能发表评论。


网站导航:
 

posts - 10, comments - 15, trackbacks - 0, articles - 0

Copyright © iceboundrock