失败的经验

04-01-08 iceant
失败的项目经历

做项目的总有成功和失败,成功了需要总结,失败的更需要总结。

以下要说的一个 Case 是我经历过的一个失败的项目,写出来,大家指点一下。

首先介绍一下背景,这个项目的客户是企业内部顾客,应用的范围是为用户收集第三方的

意见与建议提供一个渠道和工具,并给 Manager 层的领导提供必要的信息视图,以方便直观地

掌握问题的种类和问题的数量。

项目在启动以前,用户曾打过我谈,说他们在别的分公司看到了一套系统,非常

适合他们应用,希望能移植过来,并希望越快搭建越好。考虑到用户对该系统需求的紧迫性,

我们做了初步评估行动:

[] 与分公司熟悉系统的人进行初步了解,弄清楚系统的设计背景以及应用情况,得知

本地客户需要的系统是一个大系统中的一部分。另,该系统是out sourcing 开发的

没有开发人员的支持,现任的管理员对系统的了解程度有限。

[] 向分公司同事要帐号,希望进一步了解系统的功能,同时与客户联系,尝试与客户一起来了解系统

以方便客户确认,是否该系统就是用户需要的系统,功能是否能满足。得到的回复是客户已经用过

这套系统。因为有客户的确认,于是直接进入系统引入安装阶段

[] 了解了系统的软硬件需求,向分公司要来系统Copy,试安装:

存在以下安装问题:

{} 没有数据库初始化脚本,只有数据库设计文档,与分公司同事交涉,未果,

只好根据设计文档自己写出数据库初始化脚本

{} 数据库脚本运行成功,但是运行系统发现缺少视图,向分公司同事要其它的视图以及 table 的脚本

因为有异地沟通存在,和其它项目的同时进行,时间到此已经过去大约一周

{} 数据库准备完成,让用户熟悉系统,提更改需求

初步收到更改需求,因为我们对系统并不熟悉,尝试获得分公司同事的援助,将更改需求

发到分公司同事处,请他帮忙确认系统修改的可行性。这里我们主要担心的是系统的更改

会不会比重新做一个系统还要复杂?

这样的更改需求,实际上就是对原有系统的需求变更,在对原系统以及业务流程不了解的情况下,

做系统变更的风险很大

分公司同事认为不会影响到系统的流程,在多次沟通后,分公司同事还针对每个修改点粗略地标注好了

需要修改的文件和注意事项。这里要说明的是,该同事对该系统其实也并不是很熟悉。这是后话

有分公司同事的确认和一份比较详尽的修改说明,我们开始修改工作,项目进行到正式实施阶段。初

步认为修改只需要两到三天时间。此时时间距离客户找我们第一次谈已经过了两周左右。

但是很不幸,系统修改过以后,发现有一个功能不能正常工作,而该功能是这个系统的核心。

于是开始尝试熟悉系统,做 deep dig 的工作,时间过得很快,一个星期又过去了,最后确认

该系统的可移植性很差,很多 hard code 存在,一些修改后以为正常的地方都有隐患存在。

开始意识到,需要了解系统的业务流程,尽管是拿过来的系统,也需要一份客户的需求说明书。

时间流失太多,马上着手与客户沟通,希望能尽快地坐下来一起谈谈需求。考虑到客户不态愿

意写需求书的特性,自己根据原有系统,编写了一份初步的需求说明书,请客户确认,但是

得到的答复是我们要的就是原有的系统,你照着改就可以了。当我再想细一步向客户确认系统

角色的种类时,得到出人意外的答案,客户说他其实只用过该系统很少一部分功能,对系统

中的很多东西都不熟悉。所以并不知道原系统定的那些角色有什么用。

于是问题开始升级,向 Manager 求助,要求 Manager 出面一起与客户沟通,试图说服客户

从谈需求开始走软件开发流程。强烈建议从客户需求出发,以满足客户需求为核心目标来构建系统。

在讨论过程中遇到一些困难,客户认为,原有的系统运行过了很多一段时间,所以比较稳定

功能也会比较完善,从头开始谈需求没有这个必要。但是对于我们来说,没有需求就成了盲人

没有目标,我们怎么知道要去做什么? 最后达成一致意见,与客户部门的 Manager 协商,

争取客户部门的 Manager 同意从头做起。

但是事情出现很大的变化,最后,客户部门的 Manager 自己动手写了一个小工具来帮助他们完成

相应的工作。

客户宁愿牺牲自己的时间,也不愿意坐下来谈需求。客户其实知道自己的需求,但是却处在混沌状态

,我们没能很好的引导客户,让客户将需求描述出来,这一点我觉得很失败。

zybing
2004-01-08 23:29
说的太对了。最近我也失败了一个项目,也不能说是最近,原来以为3个月就可以搞定,做了快1年了。中途客户方换了一个项目负责人,和对方前任项目经理达成共识的内容许多没有成文,造成对方换了一个人来负责项目后,将以前的大部分达成共识的内容都给改变了。有些即使是成文了,但成文的如果有2意性,或者不够明确的,到时候都会来挑刺,工作量一下子加重了很多。这下在公司上下不是人,领导怪这么长时间还没做好,下面的人说怎么改来改去还是改这些内容,越做越没意思。做项目需求一定要谈明确,而且一定要成文,成文的内容也要明确,不要向我一样某些地方有二异性造成被动。还有最重要的一点:需求成文后,要对方负责人签字,这点不可遗漏。

iceant
2004-01-09 09:49
我们在做项目时,需求都是有签字的。但是签了字也不意味着用户就真正了解自己的需求。

有时用户认为他说的就已经很详细了,但是对于开发人员来说,这些信息可能只是业务需求,还缺少用户需求和功能需求以及非功能需求等。

对我们来说,目标是经手的项目能够成功。成功的标志是双赢!也就是用户满意,开发人员有成就感。所以,尽管用户签了字,我们也不能说用户签了字,照着做出来,如果不是用户要的,那就用户负责。我们还是要写一份非常详细的文档,再三地向用户确认每一个细节。以免以后因为需求不清,客户埋怨,开发人员白费功夫。

在我失败的这个项目里,当我写出文档给用户一一确认时,用户显得很不耐烦,她认为自己很忙,不愿意参与项目细节的讨论,尽管我一再向她解释不弄清楚这些问题,我们无法开展工作,但也还是难以获得用户的理解。在我们尝试与她们的经理沟通后,他们的经理默默地选择了自己写系统的方案。

不知道谁有处理这样用户的经验?

banq
2004-01-09 15:29
如何真正了解需求?我在实践中发现一个规律:

1.初步接触,需求人员自己设计好简单Use Case,无需给客户看,他们也不一定看懂。这个过程有个结束目标:直至架构师理解Use Case,并能基本确定域对象。

下面分两条腿并行操作:

1.因为有了域对象,通过美工网页设计好相关对象增删改查的界面,让用户有直观认识,在这个过程调整加强域对象的固化和提炼,同时挖掘出流程。

2.有了域对象,使用类似J道数据通用增删改查之类框架,快速开发出有关域对象的增删改查实际功能,并结合界面,供用户使用,由于在前面基础增加了互动功能,可以更加挖掘出深入的用户需求。

最后,结合XP开发方法,不断迭代,不断请用户操作习惯确认。

要注意两点:

1.真正的需求可能很深,用户没有也无法抽象表达,需要通过迭代挖掘。

2.需求也可能会变,系统必须快速跟随变化,这些J2EE系统就体现巨大优势。

agilejava
2004-01-09 15:57
我们这儿有客户签名也不行,说改就得改,烦!

jia2612
2004-01-10 00:06
没关系呀,有了客户签名,而后来又不按签字的需求做事,起码开发人员不那么被动了,这样客户也没借口说三道四了

iceant
2004-01-10 12:29
TO:jia2612

我知道很多开发人员会这样想。

但是我们的目标不太一样,我们的目标不是做到让客户不投述就可以了。

我们的目标是客户满意,开发人员有成就感。

我们需要长期的发展与合作,不能说因为这一次项目失败是因为客户没说清楚需求,或不愿意说需求,就将责任推给客户。没有很好的了解客户需求,没有帮助客户达到他们要求的效果与功能,开发人员白忙了一段时间,我们的工作就是失败了。同时,将责任推给客房的做法,会永远失去客户,这也不是我们想看到的。

我现在的想法是首先做好宣传工作,在明年的工作中,将软件开发过程中需求收集的重要性以及收集的方法通过各种渠道传递到客户那里,希望在浅移默化中给客户灌输软件工程的思想。这样也许能更有利于以后的工作。

missxkl
2004-01-11 14:33
我也来扯上几句,:)

我们的第一原则是:客户就是上帝,客户永远是正确的。

做项目就是这样,不同的用户素质也不同。

不能指望用户都能从开发人员的角度去做,只能让开发人员从客户

的角度去考虑。给不同层次的用户看他们所能看懂的东西进行确认

,就像西餐厅里并不是所有的用户都看得懂英文菜单,给不同的用

户提供不同的菜单,最好加上点菜肴的图片就更棒了。

需求是一个不断变化的过程,感觉如果产品化程度不高的东西,就

不要用什么软件工程的东西来套。

做到开发前考虑尽量周全,包括系统可扩展性,打有准备的仗。

开发的时候边做边确认,边确认边修改。

这样就会避免做完以后,跟用户想象差距太大的情况。

当然形成书面需求,需求没有二义性也是很重要,而且领导的感觉

是最重要。在中国有时候优秀!=成功,只有领导认可=用户认可

=成功。

觉得iceant的想法很好,如果客户那边能有专门的对口人员,时间

再给多一些的话,还是很有机会挽回的。

missxkl
2004-01-11 14:36
补充一下,感觉iceant的这个项目中项目经理有一定的责任

不会就是iceant自己吧,嘿嘿

sprsong
2004-01-12 11:34
我来说两句:

1、 在一个项目里边最重要的是需求分析。需求分析的正确与充要的决定了这个项目的成败。系统构架的优劣、技术含量的多少只是决定了这个项目开发需要的时间和软件的健壮性,开发的软件客户绝对可以使用,顶多开发的慢点,移植和扩展比较弱,但是不会影响成败。项目的管理也共同决定了开发的周期和成本。

2、 按照软件工程上讲,一个项目的开始必须要对客户的工作进行业务建模,相当于大学里的数学建模竞赛里做的工作,对客户的争个业务流程进行分析,建立一套“输入”-“公式”-“输出”的模型。我见过的国内比较成功的一个项目,软件开发公司聘请专业咨询公司作业务建模和需求分析,需求完成后技术人员一次开发成功。

3、 在这个过程中,可能会发现客户业务逻辑不甚合理的地方。或者向客户提出改善业务流程的建议(这也是部分客户希望通过我们系统完成的工作),或者在保证系统正确逻辑的前提下对客户的不合理流程进行兼容设计,这样一旦客户发现业务的不合理,打算需求变更的情况下可以有有备无患。

4、 “Iceant”的回复说的很好:“对我们来说,目标是经手的项目能够成功。成功的标志是双赢!也就是用户满意,开发人员有成就感。所以,尽管用户签了字,我们也不能说‘用户签了字,照着做出来,如果不是用户要的,那就用户负责’。”

不能把客户当做我们的敌人,作项目就象打仗,出了问题互相追究责任。也不能抱着应付了事的态度,按照需求书上的内容随便拼凑一些功能给客户了事。最好的态度就是假设自己就是客户,做出的系统就应该让自己在该岗位上工作的时候最方便最顺手。每做一个功能就假设自己就是该功能的用户,看看自己怎么使用最方便,不能怕麻烦就不完善某些功能,我们手头懒一懒,客户就可能要多点几万次鼠标/每月;我们一个粗心大意,客户就可能要加班熬夜。

5、 Banq(板桥里人)是java编程和项目实施在国内的最高成就者,他给出了项目实施的一个可行方案:……

6、 目前公司现行的项目有这样一种情况存在:产品经理在打单和做设计的时候说的天花乱坠,单子打下来后产品经理功成身退;项目经理在项目实施的时候则很少遵守产品经理的设计文档,按照自己对需求的片面了解实现一通。产品经理不考虑实施,项目经理不重视需求。因此如果让产品经理对项目的设计和实施进行全全负责,项目有一个重需求的人负责,这样打单的时候产品经理会知道有些可以答应,有些不可以答应。在项目实施的时候也可以对客户的需求也有了足够重视。

lironghai
2004-01-13 18:09
用户就是上帝,上帝会把你累死的!!在需求分析阶段这句话没错,但是到了需求分析完成之后,就大错特错了。在软件开发过程中执行是很大的一个问题,往往客户并不会按照原先业务分析中的东西去实现,这就是问题。其中有很多次的反复过程,最关键的客户方能有一个领导阶层的人可以保证你的客户可以很好的旅行需求中所定下的一些东西。

hymmyh
2004-01-25 12:58
项目成功的关键因素

客户的参与度 19%

高层管理者的承诺 16%

需求的澄清 15%

听ibm项目经理的演讲中所说.

happlyin
2004-02-02 10:43
首先我们要明白:

客户需求变化是一定的。

我们要尽可能去满足客户的需求。

确定了上面的两点后,我们要做的就是:

首先要求开发人员理解需求变化是不可避免的,不要反感,反对这种现象。

再就是向客户和领导尽量争取更多的时间来应对需求。

采取好的开发过程,例如敏捷软件开发过程等,来包容这样的变化。

聘请一个在需求领域有项目经验的,而且又具有很好的设计思想的人。

我认为这样的问题,跟前期的需求分析没有太大的关系。因为在前期,需求本身就不完整,即使是完整的,到客户见到成品后,也会更改需求。

zybing
2004-02-02 11:16
我说需要客户签名并不是代表将客户放在对立面,把客户当成敌人。

现在的项目经理最难当。客户不断更改需求,公司又要让你快速结束项目。

虽然说为客户考虑可以节省很多时间,但客户的想法,客户的需求始终处于不断变化中,而且做下来的程序在使用中客户也会有新的想法,或者调整使用方式,或者进行功能的扩展。如果完全都按照客户的想法实施,或者完全替客户考虑,一个用户分析系统可以做成庞大的CRM系统。

让客户签名的作用是在一开始需求讨论的时候对需求的范围作限制,否则以后客户无限制的扩充需求项目无法收尾(如无白纸黑字的签名有100%的客户会不承认当初的定义),或者某些地方做需求的扩充作为交换省去某些不必要得需求,为项目早日结束作伏笔。

pathfinder
2004-02-02 17:30
我去年底参加了某大型高速OA系统的二级管理处需求分析,总结了一个小小的经验,与机关打交道时,我们完成的需求分析一定要有个标准,也就是统一的标准,所有有争议的细节,包括客户的使用习惯,都必须适当改变,理由很多:比如这是无纸化办公,信息时代啦,在于表达,一切以此标准为准则,前期工作量很大。

猜你喜欢
3Go 1 2 3 下一页