软件项目客户迟迟不肯验收怎么办?

“我们决定下个月28号进行验收”,客户很轻松地在不经意之间和我说了这句让我朝思暮想的话,这句话使历时三个月的验收日期终于定下来了。回顾这三个月,我可是费了不少心力。日期虽然定了,但是和合同规定的日期足足晚了三个月。

  我所负责的这个软件开发项目开始做得还算比较顺利,测试工作也早早已经完成。但客户迟迟不肯验收,原因是客户卡在一个小问题上,说此问题查清后再验收。这个小问题在大多数情况下是不会出现的,只有在特殊的操作下才会出现。由于一直无法找到重现此Bug的规律,故这个小问题一直没有很好的解决彻底,结果使到项目验收一次又一次被搁置。再这么拖下去,我真不知如何给公司交待了。

  为什么客户迟迟不肯进行验收?

  一般来说,当软件开发项目到了具备验收的各项条件之后,开发团队就会着手准备验收阶段的工作。但如果这时发生客户不愿意验收的话,这是一个让开发团队很头痛和很普遍的问题。原因是多方面的,主要有如下几种情况:

  (1)开发团队没有摆正心态:这只是小问题吗?

  一个软件项目完成测试和修正后,但卡在一个小问题上客户不肯验收,这就是平时我们经常说的“小问题,大学问”。也许,许多开发人员不明白:不就是一个小小的问题吗?为什么要小题大作?实际上这样的想法是因为许多开发团队只会站在自我利益为第一位。因此,当出现有小问题时,认为多一事不如少一事,主要需求和功能能完成就行了。

  因此,作为开发团队要摆正自己的位置和心态,不是说只要完成了合同中规定的内容,完成了合同书规定的工作,并且按合同测试了就可以验收了。表面上看是客户仅仅由于他们发现的一些小小的BUG,小题大作不肯验收。实际上,当客户不同意在此时验收时,他们的判断往往不是招标书、合同、技术协议、需求规格说明书等文档。而是开发团队不能给客户足够的信心,客户不满意开发团队对BUG的处理态度,客户认为这不是小问题,所以不肯验收。

  (2)没有抓住领导意图,客户满意度不够

  我们在软件开发验收过程中得到很多的经验教训,最常见的问题是在开发过程中没有抓住客户的关键负责人或重要领导的意图,没有了解客户看重的是什么。而等到开发团队提出要验收的时候,客户又总是觉得这也不满意那也不满意,总之是不愿意验收。主要原因是开发过程中与客户的关系没有提升,没有使客户真正的满意。例如,对客户反馈问题时服务不到位,当要求客户验收时才再发现问题仍未得到及时解决,就会让客户心存担忧,或让客户失去信任。

  (3)开发流程不规范,验收标准没有达成一致

  在项目开始的时候没有和客户在验收标准达成一致,导致客户总是拿项目的小问题说事。实际上,验收标准是很重要的,这需要与客户进行详细的沟通,明确验收前需要完成的工作。验收标准中不光要有需要完成的工作内容和任务,还需要有一个相对固定的工期,使双方都能朝着这个方向去努力,防止无限制的拖延。

  (4)没有处理好问题跟踪记录

  由于许多开发合同上规定的只是一个大概的框架,再加上在开发之前没有与用户进行比较具体的交流和讨论,没有清晰的了解清楚客户心目中的产品究竟是什么样子。结果是双方对需求都有不同的理解,例如某些需求并不是客户真正想要的,而很多潜在的需求在项目初期却没有提出来。再由于在开发过程中,没有写好备忘录和问题跟踪记录,时间一长,双方也就忘记了很多承诺和约定,到了验收的时候就可能重新翻出来。这种事情是最让开发团队头痛的,明明说可以先不做的内容最终验收的时候又成了必要条件。这样最后要验收时,大家就非常容易卡在一些理解差异的问题上了。

  (5)客户因资金原因推迟验收

  有时,客户迟迟不肯验收或故意推迟验收,有可能客户是以推迟验收而推迟结算和要支付的款项。对于有这种想法的客户是最让开发团队为难的了。动用法律吧,担心破坏了长久建立的关系;不动用法律吧,还真有这么不客气的客户。

  什么是软件开发项目验收?

  (1)什么是软件开发验收?

  项目验收,也称范围核实或移交。它是核查项目计划规定范围内各项工作或活动是否已经全部完成,可交付成果是否令人满意,并将核查结果记录在验收文件中的一系列活动。软件开发项目验收是每个开发团队乃至每个开发人员都想要的结果,因为一旦验收通过就可以收验收结算款了,项目也可以告一段落。验收作为开发项目的最后一个环节,不但是对软件开发质量和软件的可交付性起到“一锤定音”的作用,而且它关系到开发团队能否收到结算款和实现利润的标志之一。

  (2)项目验收的标准和要点

  项目验收看似简单,但在操作上却是极其复杂和重要的工作,因为项目验收无固定统一的标准。一般来说,项目验收的标准包括:项目合同书、国际惯例、国际标准、行业标准、国家和企业的相关政策、法规。因此,开发团队对项目验收的标准情况了解越多,后期项目验收的难度和风险就越小。因此,细读项目验收的标准例如合同书是第一步,必须要先弄清楚这个是什么项目,项目合同中有那些客户关注的问题。这样才能在验收前,有针对性准备好项目验收工作。

在项目验收的时候,对于项目中可能存在的一些问题,不要让客户想等系统没有一点问题或保证以后没有问题的情况下才验收。如果客户这样想开发团队就麻烦了,微软那么牛,做的操作系统还天天打补丁。开发团队要让客户明白,所谓验收,就是依照合同需求和能够满足企业的需求,结果和预期结果一致就应该算通过了,而且还容许有一些小错误留在验收后改正。

  一般来说,现场长时间验收检查不太可行。因此,在验收前准备阶段,项目负责人应主动、积极的与客户密切沟通,及时、准确地收集和理解验收条件。特别是客户对即将验收项目的真实、初步意见和评价,最好是在验收前就沟通好和形成书面正式的《项目评价报告》。如还留有一些可能影响或暂时不影响项目整体验收通过的细节、小问题、变更或异议、分歧等,应与客户协商解决处理好,做到事先沟通、达成共识。强调已经基本上完成项目内容,满足合同要求。

  如何顺利地让客户进入验收状态?

  如何才能顺利地让客户进行验收是一直困挠开发团队的一个难题,为了避免项目验收遥遥无期的局面,建议加强以下几方面工作。

  (1)及时解决问题,端正处理BUG的态度

  既然发现软件存在问题,就应该尽力去解决,这是开发团队的责任。客户不肯验收,主要是害怕承担责任,毕竟还有问题没有解决嘛。如果换做我,我也不会给你验收的。因此,要想让客户方验收,首先要做好合同的明确规定和服务承诺。并以此为依据,让客户放心,让客户方验收。在开发过程中给客户感觉是不是用心的做事是很重要的,否则的话后期验收就会有点困难了。

  在项目过程中,需要注意平时承诺的积累,比如要做到讲诚信、讲原则。主要是三条:做不到的事情千万别随意承诺、承诺的事情一定要努力做到、每次做到的事情都要进步一点点。按这三条做事,即使在与与客户沟通中有这样或那样的不愉快和矛盾,客户也会慢慢接受,也会用更多积极性眼光看存在的BUG问题。当然,项目中如果有关键瑕疵,也是客户忌讳的,开发团队一定要理解这些瑕疵并解决好。

  (2)平衡和识别项目干系人需求

  在项目验收阶段前,要尽量识别和关注所有项目干系人的需求和态度,并时刻给客户灌输只要完成那几项工作就代表项目可以验收了。当客户不肯验收时,要与客户展开深入的交流,明确客户为什么不愿意验收。有时客户的问题只是借口,所以要根据客户的表现判断出这个背后的问题所在。当找到问题后,协调相关的资源来解决。有时和客户直接把问题摊开沟通,或许是比较好的解决方法。

  总之,开发团队应要对项目利害关系者进行关注,和关注他们关注的内容,或者他们担忧的内容。作为开发团队要做到尽量做好所能控制的事情,另外一些很难由开发团队控制的事情则需要借用一些其它的力量去完成。比如关注项目利害关系者的一些秘密需求是否得到了满足,或请高层领导运用一些商业手段来促成项目的验收等。

  (3)重视阶段性成果验收,提高客户感知度

  其实,软件开发项目验收远非是仅仅对系统的测试和检验这样简单,它是开发团队和客户在开发过程中双方合作博弈的结果。因此,在项目开发过程之中,与客户的沟通和绩效汇报是非常重要的。客户之所以迟迟不验收项目,简单的说是因为客户对开发团队做的项目不满意。

  一般来说,满意=感知-期望。因此,客户不满意是因为客户的感知度非常低,而期望很高。换句话说,是由于开发团队对项目需求没有定义好,或者没有分析好,或在定义需求的时候没有考虑到客户的感知和期望,导致现在的项目验收困难。所以,一方面量化和降低客户的期望值,另一方面尽量提高客户的感知度是非常重要的。方法可以是对于每一个阶段性的成果,尽量让客户可以参与并且验收,目的是为了尽可能来提高客户的感知度。

  (4)清晰处理好客户反馈问题的跟踪状态

  在一个项目开发周期中,每次客户的反馈问题都需要认真做好跟踪记录。下次工作要根据前次备忘录的双方约定或客户的反馈问题继续进行,保障项目在双沟通的基础上不断前进,并用备忘录约束双方的行为。

  建议在收集项目出现的各种问题时,采用问题跟踪记录表的形式,这样可以一目了然地显示出曾经收集到的各种问题、目前的解决情况、以及还有什么问题没有解决,或准备什么时候解决。这样客户和开发团队就都会对目前的情况非常了解,通过不断地解决出现的问题,来收敛可能出现的问题。当存在的问题越来越少时,也就表示项目开发已经在接近验收的标准了,也可使客户在需要验收的时候不能再找各种各样的借口来拖延验收。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-26 02:46:15

软件项目客户迟迟不肯验收怎么办?的相关文章

如何和软件项目客户打交道

项目经理需要干的3件事--控制.调配和缓冲. 控制:控制客户与突发事件. 调配:调配 时间.资源.需求之间的三角关系. 缓冲:分解压力,在需求方和工程师之间充当沟通桥梁(这两种人虽然都会说中国话,但在对方听起来基本是两种语言.) 如果你不能学会控制客户,处理好甲方和乙方之间的关系,其实任何项目都有可能变成垃圾项目.  几个首先的原则:  不要忽悠甲方.无论是为了拿下项目还是获得更多预算.这样做好比为了立战功,对朝廷说我有5W雄兵,派我去吧.实际你只有2W人,结果到了战场一看敌军10W人,到时你就

使用IBM RTC管理软件项目工程中的日常开发任务

IBM Rational Team Concert(RTC)作为软件协同开发工具,被逐渐应用在大型项目的生产过程中,维系着规模庞大的项目组织团队,有条不紊地管理每一项开发任务,从而为创造高质量的软件产品打下坚实基础. RTC 提供了贯穿整个http://www.aliyun.com/zixun/aggregation/17799.html">开发过程的集成环境,包括:需求定义.迭代计划.源码控制.自动构建.缺陷跟踪.变更管理以及统计报表等功能.本文将通过三个层次,自下而上地详细阐述如何使用

去年一个百万级的小软件项目经验分享,20来个功能模块,项目不太好做有些棘手

转自http://www.cnblogs.com/jirigala/archive/2010/04/10/1709223.html  别人总觉得是在显吧,干脆把这个项目认为是小项目了,不知道把这个项目是小了,别人会不会又觉得又显吧了?说大也不行.说小也不行,也的确没招了.   我想主要把项目里遇到的问题分享给大家一起探讨,也并不是为了什么显吧什么的,希望大家用一个正确的心态阅读此文章,希望有更多的朋友把更大软件项目的经验分享给大家,让大家知道一下,大型软件项目里都会遇到什么问题,如何解决才好,我

软件项目需求管理复杂性分析

在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能 ,优化性能,提高用户友好性的要求.在软件项目管理过程中,项目经理经常面对用户的需求变更.如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加.质量下降及项目交付日期推后.这决定了项目组必须拥有需求管理策略. 一.需求管理复杂性分析 软件需求是整

未雨绸缪 软件项目策划成功的要点

古人云"万事预则立,不预则废",项目要成功必须做好计划.软件项目策划是项目管理过程中最基本的一个过程,软件项目策划的方法是软件项目经理必须掌握的.在实际的项目策划过程中,必须掌握以下的9个基本要点...... (1)掌握好项目策划的时机 软件项目策划过程的输出是文档化的http://www.aliyun.com/zixun/aggregation/10495.html">项目计划书,在项目的不同阶段都需要进行项目策划,只不过在不同时机项目策划的目的不同,花费的工作量也不

资本迟迟不肯进场 光伏还要怎么玩?

光伏行业的冰火两重天景象已经持续多年:一边是光伏应用市场的火爆,另一边是资本迟迟不肯进场. 这个由大量民营企业托起的行业,因为其重资产属性,从一开始就表现出对资本的强烈饥渴.然而,因为大银行机构的傲慢与偏见,他们仍然钟情于包括"五大四小"在内的央企巨无霸和地方国企,对于民营光伏则表现出观望.踌躇和不信任.世界第一的光伏装机大国,却因为资本的举棋不定,无法成为真正的光伏强国. 资本的杠杆效应.市场的快反机制,并没有在这个光明的行业得到淋漓发挥.银行傲慢与偏见的背后折射出怎样的经济与社会成

CMM可重复级在特殊软件项目中的应用

引言 由 SEI 在 1991 年 8 月发布的软件能力成熟度模型( SW-CMM ),用来评估软件企业的 成熟度级别,使软件企业了解自己的优势和不足之处,从而持续地改进企业的软件开发过程,提高管理水 平,降低管理成本,保证软件开发效率和软件质量. 然而, CMM 是针对大型项目和企业制定的. 小项目和中小企业由于受到相应条件的限制,如组织结构.角色和关系.过程模式定义等,生搬硬套 CMM 框架只能给自己带来沉重的负担.可取的做法是把 CMM 作为一个参考,从 CMM 评估体系中汲取适合于自 身

2012年最可怕的软件项目事故汇总

数十亿美元就这样打了水漂--今年多个软件项目遭遇失利,此类事故已经引起管理者的高度重视. 诚然,很多企业在软件项目的推进过程中获得了成功,也将供应商所承诺的新特性与新功能顺利传递给终端用户:更低的运营成本.更简洁的管理流程以及各类足以取悦消费者的要素. 但遗憾的是,仍然有一些项目以失败告终:投入巨资的客户只能面对"断瓦残垣"而欲哭无泪,并被卷入危害事业进展.有损合作关系的漫长诉讼当中. 而从积极的角度来看,我们能够将这些过往的事故当作前车之鉴,无论是供应商还是项目客户都能够从中吸取经验

关于软件项目后期Fix bug的意义之我见

众所周知:基本上所有的软件项目到后期必不可少的是fix bug,一个软件在交付客户后或交给测试人员测试时都存在一些程序员意想不到的问题.现在有一些成熟的bug跟踪系统,譬如:bugzero,bugzilla, redmine等等. 解bug是很头痛的问题,一般是以下原因引起的: (1)设计上的缺陷: (2)写代码时考虑不周全: (3)测试人员无中生有: (4)所依赖的插件,框架本身的缺陷. 第一种情况:最棘手,需要修改程序架构,费时又费力,但是不改又不行总不能要客户该需求,按照你的程序来吧.没办