回顾项目失败原因

      我们30多号人加班加点，全力奋战在一线，加了差不多4个月的班，但是我们还是没有把项目做好。之前我写过工期逼近,释放压力 ，那是我们才刚刚开始加班，我就很担心我们的项目。项目经理多次请求老板给我们更多的时间，中间延期了好几次，最终经过高层的研究决定，我们经理也做出了痛苦的决定，在次延期我们的项目，听说要到明年才上线了。我们那么多同事的努力，心血就这样得不到认可，部门花费整个公司那么多的人力物力财力，但没有按时按质的完成项目，我想其他部门的同事肯定在说我们的坏话了--一个部门养了那么多人，什么事情都做不好，什么也搞不定。
经理问我觉得项目失败在哪呢？让我回顾一下整个过程，我想想有如下的几点问题：
      1）在前期我们的项目估算、分析做的不够细致完善。有一种大跃进的感觉，比较激进。有很多东西没有考虑进来；时间当然会估算的不准确了。
      2）需求分析做的不够深入，不全面。有很多东西挖掘的不够深入，很多用户会有不同的观点，那么要仔细的揣摩他们的意见，并综合整理，做出合适的DEMO给他们，并一起分析讨论。因为我们是在公司现有的系统上优化流程，优化系统，整合系统。所以用户在原来的系统上提出的一些需求，经理都把他们推到二期才上。
     3）沟通效率不够好。在前期的业务分析只有业务分析员参与，开发员都是在进行项目开发时才参与进来，这样我觉的应该在前期就应该分析员和开发员一起对系统进行分析讨论，业务分析员并没有系统开发的经验，所以很多东西分析处理并不是最优的。用户与分析员，分析员与开发员，测试员和开发员，这样传递的沟通讨论，我觉得效率不好，分析的不够透彻。
     4）在项目进行中引入新人。他们都是刚刚毕业的同学。他们只有一些理论的知识，并没有开发经验。在项目进行中，还得不停的给他们讲解需求，开发同事还得不停的给他们分析这个代码应该怎么写，甚至还得给他们揷屁股，浪费了大家非常多的时间，这当然不能怪他们，这也是给他们学习锻炼的好机会。当然这大家的帮助指导下还是帮我们做了不少事情。
     5）团队积极性不高，工作效率不好。在加班、正常工作时间都有同事在QQ、游戏中、浏览网页等等做一些与工作无关的事情。怎样提高大家的积极性和工作氛围？我们应该让大家看到他们的希望发展所在，不能就是做一天和尚撞一天钟呀。团队应该多一些机会在一起沟通交流，分享和交流思想。
     6）每一个开发同事（或者核心的开发员）应该熟悉整个系统、各个模块之间的联系。由于需求的分析的不够透彻，导致开发同事不能够理解，为什么要这样或那样改来改去，导致他们有抵触心理，也导致工作效率不够好。或者测试同事之间也会测试案例的冲突，开发员同事之间有时也不能够理解，有些时候其他同事是只要稍作修改，就能帮其他同事就能节省很多事情。
    7）团队成员的不稳定性。由于项目的多次延期，造成大家心情的不爽。有些同事可能不能理解，所以另谋高就了。这样又要由其他同事接替他的工作，本来每个人都忙，时间又紧，真的是雪上加霜呀。又要维护他写的代码，很是头痛。
    8）团队的技术水平参差不齐。有些同事不太习惯写TEST，所以对自己写的代码没有信心。也是天马行空，没有多的时间去思考，只顾把任务完成，代码写的不够好，维护比较困难，性能也是一大难题。
    9）要把项目做的更好，满足到用户的需求。不然用户测试时就对我们失去信心了。

    10）太多的加班。在加班的初期大家还是挺有干劲的，工作效率也挺高的。可第一次延期了，第二次又延期了，第三次再次延期了，俗说：“一鼓作气，再而衰，三而竭”，到最后大家都比较憔悴，都病到好几个了，个个面黄肌瘦的，熊猫眼。
     很多东西不是我们可以觉定的，我只能尽自己最大的能力，去影响带动其他同事。真心的希望大家能给我更多的建议，谢谢！

 

评论

48 楼 tibetjungle 2008-09-21  

huangtut 写道

5）团队积极性不高，工作效率不好。在加班、正常工作时间都有同事在QQ、游戏中、浏览网页等等做一些与工作无关的事情。怎样提高大家的积极性和工作氛围？我们应该让大家看到他们的希望发展所在，不能就是做一天和尚撞一天钟呀。团队应该多一些机会在一起沟通交流，分享和交流思想。



计划做到每天的会不会更好？如果每天的计划都能完成，那按时完成的可能性就高了。

这样精确的进度控制是很难做到的，个人觉得能把任务以周为单位安排就很不错了。当然，工期短的项目除外。

47 楼 风雪涟漪 2008-09-17  

30多人的 人员分工能不能说一下。参考参考啊

46 楼 hyysguyang 2008-09-17  

关键在质量，质量高了，效率也跟着上来了。
千军易取一将难求。
工作上严于律己，绝不能宽以待人

记得以前一个很厉害的老大，嘿嘿，每个人提交的代码都必须经过他的手。
当心，你昨天写的代码被Rollback，你重写吧。

如果你是精英，请影响并带动你周边的也和你一样成为精英。

45 楼 qlhl2000 2008-09-16  

我们也有过被其他部门看不起的时候，我们也有项目延期的时候，但是我们会像你一样的总结失败，所以我们现在过得相对舒服；项目的诸多环节，我认为需求和交付比较关键，因为我们是开发人员，设计是我们的专长，需求准确的出台之后，如何实现不是问题；然后是交付，这是一个标准的技术活，第一让客户回想当初的需求，其次让客户知道我们是按照当初的需求做的，关键是要让客户接受这个成型的产品。

44 楼 stack3256 2008-09-14  

其实问题出在用人
贵在精 不在多

43 楼 jasongreen 2008-09-13  

我们30多号人加班加点,暴雪开发魔兽世界好像也没上“30多号人"

42 楼 liano 2008-09-12  

很多项目失败的原因都很相似，如果是工作流程上的问题，试试SCRUM。
如果是人员方面的问题，哈哈，people work。
首先最根本的是交换，老百姓为什么给老板干活，那是因为能得到工资，作为员工来说，除了￥之外还有别的东西，那就要看公司有没有吸引力了。
另外， 一些小的心理学技巧有点时候也会起作用， 但不会起到根本作用。

41 楼 pipilu 2008-09-11  

业务分析员是应该和项目经理、核心开发人员一起讨论需求。
光业务分析员分析是不太好。他可能认为什么都是重要需求，什么都应该在第一期做出来，问题是：你们能一下都做出来么？应该有项目经理和架构师去约束一下，剔出优先级高的需求，优先级低的还不确定的需求，就先放一放，先不拿结论。

总之，感觉没有分好层次，第一期应该少做一些东西，应该专注于数据，流程放后（如果是MIS）。或者专注于基本处理流程，相关的配置、管理放后（如果是后台服务程序）。
第二期再把复杂的业务功能加上。
多分几期让大家能有成就感，而且也安全（相信大部分客户是可以理解的）。
另外就是设计，设计好接口，新人只做很简单的功能的实现的部分，这样相信他们还是能做的。

40 楼 cuiyi.crazy 2008-09-11  

项目不延期基本不叫项目，因为在现有的resouce和工期内能完成的计划本来就很少的（舍得在开发部门上投入的公司除外）

39 楼 rockjava 2008-09-10  

项目失败是什么概念，是做出来的没人要了，还是压根就没做出来啊？

38 楼 200015207 2008-09-09  

理解 理解

37 楼 mreay 2008-09-09  

一直在想。类似这样的项目是否应分解为若干个小项目或若干个阶段。

36 楼 tv9 2008-09-08  

做软件的，没看完《人月神话》的，不要做管理，还没看的，赶快去看，新出版的《梦断代码》也可以，看完你才去做你的管理。

35 楼 aidiyuxin 2008-09-08  

哎没办法啊，国内的软件体制不完善
有很多客户都不知道要作什么软件，软件该完成什么，甚至都不知道什么是软件
就拍拍脑袋，想凑个it的热闹
所以导致很多工程延期
坑害了很多人阿

34 楼 thinkintime 2008-09-08  

Lucas Lee 写道

加班根本上就是错误的方法。
加班就相当于短跑，如果你跑个1、2百米，那一开始把所有的力气都使上没问题，要是你跑个4百米、1千米甚至是马拉松，那一开始用所有力气就是个笨蛋--当然，当我们小的时候（小学）第一次跑400米也常犯这样的错误，也就相当于刚毕业的学生做项目就知道(主动或被动)加班来赶进度一样。

进度是赶不出来的，只要项目周期长于1周。
就像跑长跑，你不能明显的一会慢一会快的赶。

赞同！本人觉得这几个方面较重要前期需要分析能否到位如原型设计，系统的设计架构及规范是否到位

33 楼 joyfun 2008-09-06  

没有进度计划表吗?一次 两次 三次?

32 楼 fight_bird 2008-09-06  

hgq0011 写道

fight_bird 写道

两个关键问题：
1、客户经理何在？或者叫专职的需求分析员，30人的项目岂能没有客户经理这样的角色？让开发人员直接去调研需求的做法适合小项目，对于大项目，这样作坊式的做法导致的后果就是需求乱糟糟，开发低效率，尽做炒冷饭的无用功。

2、项目管理体系何在？30人的项目没有一个项目组外的监理人吗？一旦出现问题的苗头就应该有监理人及时监控。对于一定规模的项目，依赖项目经理或项目组内部进行全程管理是很不专业的，是作坊式的，大项目更需要依赖整个公司的资源。

我的看法：你们公司的项目管理体制不适应大项目，说得难听一点，管理的思路还停留在作坊式的层次。

1)我们有专职的业务分析员，且他们以前从事过相关行业工作，对业务需求非常的熟悉。我只是在想，如果业务分析员＋系统分析员＋最终用户＋重要人员一起参与分析，这样会不会更好？以前系统分析（开发员）没有直接参与分析。只有系统整体的模型出来了，开发员才参与进来。

2）我们有类似项目监理人，他们掌管整个公司的运作。这个就没有那么专业了。他会经常询问项目的进展情况。


您说的对，我们公司管理确实有问题。“管理的思路还停留在作坊式的层次”，最近公司正在推行精益生产方式，和ISO2000，这些希望能对整个公司有所帮助。

没看出这种的业务分析员有多大作用，你们这个业务分析员和合格的客户经理有本质区别，这个角色需要商务能力和技术经验的良好结合，只懂业务的人拿出的所谓需求就是功能描述而已，这不叫“需求分析”。

31 楼 foible 2008-09-06  

tuti 写道

套到每个延期项目上，估计都适用。

这句话实在！

30 楼 hgq0011 2008-09-05  

wazhyu 写道

我们小公司加班不给加班费。。。

我们加班也不给加班费的，只能调休。

29 楼 土匪一份子 2008-09-05  

Lucas Lee 写道

加班根本上就是错误的方法。
加班就相当于短跑，如果你跑个1、2百米，那一开始把所有的力气都使上没问题，要是你跑个4百米、1千米甚至是马拉松，那一开始用所有力气就是个笨蛋--当然，当我们小的时候（小学）第一次跑400米也常犯这样的错误，也就相当于刚毕业的学生做项目就知道(主动或被动)加班来赶进度一样。

进度是赶不出来的，只要项目周期长于1周。
就像跑长跑，你不能明显的一会慢一会快的赶。

特别是加班不给加班费   时间长了迟早会出问题的。