向失败学习，谈谈我们做的一个失败的项目及带来的收获，欢迎交流
有句话，失败是最好的老师，的确，失败的学费有时是昂贵的，但带给我们体验也是刻骨铭心的，我们能做的就是尽量避免在同一个地方跌倒两次。个人的一个方式就是通过总结，反思，分析原因， 找出症结.，弄不清症结所在，当相同的境况出现时，可能还会重蹈覆辙 ，
下面描述自己曾经所做的一个失败的项目
1.项目类型： j2ee
2.团队： 单枪匹马
3.用时： 4个月
4.个人经验度： 第一次从事j2ee开发，
项目运作情况: 项目做好后，给老板演示，发现一个核心的业务逻辑理解偏差，如要修正，代价是新系统几乎要全部推导，该系统就这样将就用了一年，中间用户又提出了很多的问题，建议，最后随着其它系统的建立，由于系统之间的交互，问题系统像一个瘤子，到了必须铲除的地步，不得已，又花了近3个月的时间重新建设，后来想想，那个项目的确存在很多的问题：
1.虽然平时也老听说编成不单单是写代码，可潜意识中还是把代码作为一个太重的分量来对待，草草做需求，草草做设计； 导致需求没做好，带给自己的直接是对系统的一个切身的体会（不再是口头上的啦），系统不光是写代码，需求，人性化等都很重要喔
2.为什么我做的那个项目到最后才被发现有问题呢，除了老板自身原因外（老板硬件出身，软件方面全权交给了俺），和我的经验不是很多，和老板沟通不够都有关系，但最重要的是要建立一套可行的软件开发管理机制。
3.为什么出现了问题，要修正起来几几乎要推到整个系统，归根究底还是设计的不好，扩展行不够，没有很好的领悟面向对象思想。 鼠标坏了，我们无需更换键盘，硬件如此，原件也是如此，那就是要面向接口设计
4.。。。
当然以上有些东西要想做好光认识到还是不够的，需要技能的提升，经验的积累
朋友们，很想听听你们曾经做过的不是很满意的一个项目，你认为是什么原因造成的呢，欢迎提供，交流，一同学习，毕竟，共性的东西才是真正值得我们注意的
[解决办法]
up
[解决办法]
[解决办法]
无论项目如何，你都是最大的赢家。我感觉这不是个失败的项目，而应该是个非常非常成功的项目！
[解决办法]
[解决办法]
当然以上有些东西要想做好光认识到还是不够的，需要技能的提升，经验的积累 。这句话 我顶
觉得项目不成功的一个原因是：缺乏经验或者说是缺乏一个有经验的人的指导。
做过项目与没有做过相比，其实距离很远。人家做过了，里面的一些要注意的细节（可能最终导致严重bug），就会一清二楚。对于没有做过的人，或许他的编程能力、设计能力并不差，但是没做过就是没做过，有些问题是你必须经历了失败的痛苦之后才会明白的。
[解决办法]
那确实，失败是成功老妈,加油
[解决办法]
up,所以需求是相当相当重要的！谢谢分享！
[解决办法]
楼主犯了三大错误 第一：需求不明确，这会给后面的开发带来很多麻烦，不仅给自己对客户来说也是很麻烦的，项目开始之前都要有一套完整的需求文档。
第二：沟通不好，这点是很重要的，沟通不好，需求从何而来！
第三：没有利用接口, 利用接口，降低耦合性，不至于到最后要不系统全部推倒重做！
这是我的一些观点，希望会对楼主有所帮助~~~~
[解决办法]
缺乏和客户沟通，做项目之前最好是和了解客户需要什么。这样我们才能满足客户的需求，
程序员需要的是共同合作的精神和沟通能力，光编程是不行的，要不，我们编了个三五年下来都只是和计算机说话，人话都不会说了
呵呵，加油啊，IT 行业的同伴们 ！
[解决办法]
只有做过了、失败过了 才知道怎么做是正确的 楼主加油~~
我项目做了三年多 从里面也学了很多 从设计到实施 软件不只是程序 还有许多文档以及相关的业务背景
如果要把一个项目做好 真的是很锻炼人的！
[解决办法]
我已经给别人开发过几个小项目啦，每次感觉提交第一个版本的时间不会超过十天，但是，到后来的更改可能要持续上2个月+。因为也是单枪匹马独立开发，技术上存在很多问题，导致功能上很多的缺陷。现在 是感觉很想回公司去工作啊，一个人，压力太大啦。
[解决办法]
诶，感觉工程文档很重要啊，文档做好了用什么语言开发是较次要了
[解决办法]
"但最重要的是要建立一套可行的软件开发管理机制。 "
楼主总结的不错，收下了
推荐一本书：java设计模式
[解决办法]
最近看到楼主不少关于java的帖，呵呵，此贴俺也来说两句
对于软件工程的流程，我觉得有些时候我们没办法去按常理走下去，比我我所在的环境，基本就我一个负责开发的，周边参与项目的同事都不懂软件，为此我在实际的沟通和操控大局时也出了n多问题，比如文档进度不统一、沟通语言易被误解，为此我也曾想过开个小会，仔细分一下工，完整的走完需求分析、概要设计、详细设计、编码测试等等流程，但基本不可能。公司的规模和客户的性质基本决定了我没法把时间花在文档上，和需求的完全确定上。甚至出现了东西都做好了，客户都没看到一眼这种情况。有些时候真的很无奈，要对一个需求相当模糊的东西进行设计编码，而且作为开发人员还要分心去和所有同事沟通，还要考虑样式的设计与图片的制作（这个问题是因为美工经验差，图片做的不佳，而且完全不会html）。结果呢？？呵呵，我为了能团结大家共同完成目标而成了老好人，成了大家的垃圾桶、、、所有的抱怨和质疑基本都是直接劈头盖脸的直接来，而实际产品还好客户没要求大的改动。实际的效率也很糟糕，经常有无谓的讨论和完全可以避免的程序上的返工。
头疼啊，小公司大多这样，需求分析整理+编码+进度控制+测试+文档+沟通权衡，多职责系于一身、、、、、而且流程不是乱的要死就是压根不按流程走
[解决办法]
[解决办法]
有点小小的意外,已习惯在失败中成长;
才默然发觉失败也是一种收获;
我也总结下:
先从最基础的说起:觉得有些非常简单的代码,如果稍微不注意,多打,少打或打错了一个代码
尤其是那种反射,连接数据的字符串,是在双印号里写的,开发工具根本就不会提示你,
还有就是利用开发工具的时候追求速度,导错了包.
感觉编程的大部分时间是在代码的调试上,后来发现
:"慢其实就是快",也不至于特别慢,项目中缺少沟通能力,喜欢单枪匹马,一味的猛敲代码,这不是好事;
记得以前作项目的时候,由于设计需求的设计不是很好,修改是经常的事,再到后来,修改的没有
什么可读性,再加上没有写注释的习惯,可笑的是,代码需求是达到了,但自己都有点看不懂.
后来发觉:一些代码虽然能写出来,但可重用性啊,可扩展性啊都不是很好,才有学习设计模式思想
的意识,难怪项目经验这么值钱;
至于上面的朋友说的,按流程走,个人认为:能力达到了一定的程度,不按流程走牛逼,其实还是有流程意识的;
要想做一名优秀的程序员,过硬的技术是基础,并代有突出的沟通和协作能力...
什么项目经理->项目主管->部门经理->公司CEO->还是自己当老板也好指日可待,呵呵.
[解决办法]
我做的XX案子，公司内部的某XX。
1.因为没有成本预算，所以客户需求变更极快
2.项目组没有此类案子的经验，没有进行深层的技术预研，后面吃了很大的苦头
3.后期项目组人员变动频繁，最后。。。
4.。。。项目死了
总结：
1.一定要文档化流程化客户的需求。
2.做好变更的追踪。
3.要提前进行技术预研，虽然一切反动派都是纸老虎，但精神原子弹还是常常失效。
4.开发的相关文档一定要准备好。
5.对手下人一定要好一点。
6.不赚钱的买卖把客户看成婊子就对了，用警察扫黄的语气来做需求。
[解决办法]
在这里打击一下楼主和三楼的同学吧。
楼主列出的1,2,3,4可以看出，楼主还是没有把问题搞清楚。
我觉得楼主最根本的一个问题：用户反馈周期太长，导致最后做出来的系统离用户的要求大相径庭。
对于一个行业，要是行业经验欠缺或者编程经验欠缺，怎么可能有详尽的需求、设计文档。要做到详尽，成本要有多高？而且某些需求连客户自己可能还没有想清楚，要通过实践去摸索那些模糊的需求。请问：在这种情况下，你的详尽有什么用呢？
软件开发可以大至分为：分析、编程、测试、集成。我们要做得不是用一年时间去完成这几个阶段。而要反复的不断的完成这个几阶段，这在敏捷开发里面叫做迭代。对于一个小功能点，简单分析需求，做简单设计，编码、测试，集成。对于模块或者子系统，在开发完之后就要给老板或者客户演示，尽早得到他们的反馈，再修改，再反馈，再修改。。。。。而不是等到整个一个系统完了之后，才演示。那个时候，菜都凉了。
再者，采用简单设计的原则，用不到的功能或者自己认为可能用到的功能坚决不加，不要为了用接口而用接口，不要为了用设计模式而用设计模式。
[解决办法]
[解决办法]
1.了解你自己真的想做的是什么，整理一下那些功能 （需求分析啦）
2.根据整理的功能利用ER图的方法来设计数据库（有时候不能完全按照了，为了性能）
3.选择一个好的数据访问层。当然，这里参考些代码，利用sqlhelper来做是最好的
4.做界面，拖进去gridview，listview，repeater之类的空间，把他们datasource设置成你的sqlhelper取回的数据，就ok。这里不太好说，因为有maseterpage，basepage，还有sqldataprovider之类的东西，最好参考一下基础书籍，照着弄弄。
嘿嘿，自己也是初学者，慢慢摸索，关键是每天都做出点东西，立足实际，每天给自己自信，慢慢就会牛的。
我觉得LZ 第一次能自己独立完成一个项目，确实就是一个收获，随着时间的增长，经验的积累，你的前途不可估量哦 ，慢慢来，想一步登天是不行的