失败的经验

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

我们这儿有客户签名也不行,说改就得改,烦!

9Go 1 2 3 4 ... 9 下一页