一个项目失败的总结

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一个总成本花费100W的失败项目的小小反省

这个项目开始到几个月前基本暂停,总共差不多花费100人月,总成本应该也差不多是100W 吧。

在几个月收获的产品只有一堆中间代码。当然,参与成员对某些技术还是有进步的。

需求,没有远景,没有边界

当项目走了很远的时候,当需求好像无穷无尽的时候。经验丰富的领导总算想起要做一个边界定义了。

如果没有一个边界,需求是做不完的,满天的麻雀,都想要抓,团队的人力物力是非常有限的,对于一个产品来说,市场也是不会等人的,必须要在规定的时间内出来的,才有可能成为一个成功的软件。

需求,脱离用户的需求

当需求只是凭空猜测的需求,自然会让人觉得无穷尽,因为人类想象力总还是比我

不巧的是,也是众多企业的多元化之路一样,软件要想进入一个陌生的行业领域,也是一条艰辛之路。需要的不仅仅是勇气,还需要机遇,所谓东风是也。但是还需要资源作为支持。如果低估了艰辛程度,可能就低估里所需的资源。没有必要的资源,也许你走了90%的路了,你要走不完剩下的路,也许你从沙漠中央走到了离沙漠边界只有数里之遥的边界,没有了那最后的补给,你还是出不了沙漠。任何风吹草动都可能成为压垮你的最后稻草。

没有结束的结束

没有人会承认失败,尤其当没有人要求你这么多的时候。我们的项目也是,我们几乎听不到有人出来说了,我们听到的是延期、暂停、取消等等形容词,但是其实,我们其实应该承认,我们有做了一个失败的项目。

过程,没有过程,没有积累

能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认,这样既能保证我们所理解的需求就是客户所要的,也使得项目末期跟客户验收时有据可依。根据我自己做项目的经验,由于客户一般对计算机不是很了解,和他们交流用我们行业的话,他们根本就不懂,如果用文档也很难把需求写的那么明白,而且文档很多的话,客户都看烦了,很不直观。如果让客户一看就可以看出这个就是他们想要的,我个人认为最好的方式就是做系统原形。系统原形应该在需求分析的时候开发人员在分析师

的指导下完成真实环境中的开发,当然开发只是界面的功能模拟,没有底层代码的实现。这样做的目的有三个好处,一是客户很直观的看到他们的系统是什么样子的以及怎么操作,二是这些开发的成果是可以二次利用的,三是可以更好的激发客户的需求。

在项目中期是发生需求变更是很常见的,这时要做好需求变更管理流程。需求变更表,小的变更自己掌握,客户要求的变更有开发人员和设计人员共同商讨后提交,项目经理预估变更损耗工程时间,在一定阶段一起提交给客户,大的变更直接提交客户,并且要把需

;

二、对客户现有系统分析和研究重视不够,我们开发的系统是客户已有的系统,他们已经用了多年,在使用的过程中他们已形成了自己的习惯。而且他们的老系统也有他存在的优点,也是在使用的过程中逐步完善的,可是我们在开发过程中完全忽略了老系统的存在。

三、签订合同也是非常重要的,具体内容我在上面已说过了。

四、没有《功能规格说明书》,这个是我们项目中最大的失误,致使后来客户的改动让我们很被动。《功能规格说明书》反映了客户提出的所有需求功能,我们也是按照《功能规格说明书》来开发的。后期客户的变化都可以和《功能规格说明书》对比,具体怎么变更按照我们的变更流程来做。经验教训:《功能规格说明书》作为产品需求的最终成果必须具有综合性:必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入需求规格说明那么它将不能作为协议的一部分并且不能在产品

量的保证、计划的安排执行和跟踪、掌握行业知识、人员的管理、技术支持、风险的预测以及数据库的设计等等工作。而在大型软件公司中这些工作至少是有3年以上本专业经验的2人来做,一个项目经理和一个软件架构设计师。一个项目在前期的这些工作就是一个错误的话,后面有再强大的开发团队也是白搭。我们还是一个年轻的团队,很需要这样的人才,需要公司来培养,如果遇到项目,再招人员来担当这样的工作,风险是可想而知的。而且这样

的人员肯定是从项目实战中成长起来的,不是有非软件项目管理经验的人员或者市场人员转过来就可以做好的,更不是从书本或者参加某些培训就可以学到的。

七、一味的追求快速开发,时间进度。在我所去的公司中好多都是想把项目尽快做完,我们公司也是一样,但是我知道不是的。做项目和孕妇怀孕一样,没有捷径可以走的,必须一步一个脚印走。公司往往为了赶进度,省略了某些工作,最终结果是后面付出几倍省了那些时间的代价去弥补,更严重的是前期的工作白做了,用个成语形容就是“投鼠忌器”。

害怕我们的工作量增大,后果是在开发好后,给客户一看说:“这不是我们需要的,我们想要的是这样的”。在代码和数据库设计中时间投入很少,这些工作本来就是比较抽象的,需要不断的研究和推敲才能设计好的,但是我们为了时间进度,很快就出来了,后果是客户的一些小的需求变动,由于我们的设计不好,导致前期的工作白作了。

十、客户意见的一致性,我们在调研的时候过分相信领导,我们做的项目真正的使用者不是领导,而且广大的员工,领导只是看数据的。我们的调研对象主要是最终用户,尤其是在大型项目中,可以说是领导很多,各有各的想法和意见,到底他们谁的是对于错呢,其实这个根本没有对于错。而我们吃亏的一点就是他们的这些领导提出意见的时候都不在一起,他们也没有开会研究过,谁提意见就按照谁的改,后果是我们的重复工作不知道做的多少。这个就是在我们内部也发生。解决方案:在调研和需求改动修改一定要和客户确认好,

相关文档
最新文档