回顾项目失败原因

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

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

 

评论

28 楼 wazhyu 2008-09-04  

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

27 楼 whitenegro 2008-09-04  

说到底还是人的原因，我认为就是缺少一个强有力的技术经理和几个经验丰富的程序员

26 楼 albert_qhd 2008-09-03  

1、做项目不能一蹴而就，特别是大项目更是这样。而是应该用迭代的方式，小步快跑。这样的话，大家也会有成就感，对士气非常有好处。
2、评审很重要。定期进行评审，也是一个相互提高、相互了解的过程。
3、进度控制。大家一起进行评估，定出一个可行的计划来。计划出来后，就要严格执行。如果某个人多次无合理理由拖延进行，必须要采取措施，清除出项目组。
4、加班问题。尽管大家都痛恨加班，但加班很多时候确实可以加快进度。但要注意一个度，绝对不能连续加班。比如周六加班了，周日就绝对不能再加班。
5、团队建设。经常一块吃吃饭，喝喝酒，去郊外玩玩，对士气很有好处。

25 楼 wuxiaoq 2008-09-03  

唉，PM做什么去了。。。

24 楼 gurudk 2008-09-03  

hgq0011 写道

zqrain 写道

其中“需求”出现5次，技术出现2次，沟通出现2次

于是可以得出结论：从这3个方面入手找解决办法！

恩，这些是大方向。但细节上要怎么改善呢？过程也很重要的呀。

说多少只是借鉴，如果你是管理者，把这些实施下去才重要，别人代替不了你。

23 楼 zqrain 2008-09-03  

hgq0011 写道

zqrain 写道

其中“需求”出现5次，技术出现2次，沟通出现2次

于是可以得出结论：从这3个方面入手找解决办法！

恩，这些是大方向。但细节上要怎么改善呢？过程也很重要的呀。

解决思路其实很明显（如果你经常上javaeye的话）

需求
  (1) 引进需求管理
  (2) 采用迭代/增量开发(减小需求不明确或需求变更带来的不利影响)，学习软件开发过程方面的best practice

技术
  (1) 建立合理的人力资源梯度，优化人力结构
  (2) 积极提高员工的技术水平

沟通
  (1) 理顺流程（参考需求－(2)），提高沟通质量和效率
  (2) 建立好的团队文化和沟通文化

22 楼 KENSHI99 2008-09-03  

说白了就是项目缺乏规划，没有明确的版本基线，先搞清项目方向和需求，做出整体或部分功能的效果图给客户进行系统演讲，收集意见，然后集合牛人来分析并做系统的DEAMON，把核心流程走通，之后再拿给客户演示，调整完之后可以先上一部分简单的功能，让一些边角人员做一些外围的功能，一步步把系统完善，只有及时把成果或问题反馈并改进，才能减少项目的风险和保证项目的方向正确。
新人的问题，我觉得还是在调研的过程中就应该先弄套规范出来约束一下他们：代码书写格式，命名规范，程序文件存放位置，数据表设计规范，还有一些模板等。
项目只有做到统一有序，才会有激情和成果。

21 楼 hgq0011 2008-09-02  

zqrain 写道

其中“需求”出现5次，技术出现2次，沟通出现2次

于是可以得出结论：从这3个方面入手找解决办法！

恩，这些是大方向。但细节上要怎么改善呢？过程也很重要的呀。

20 楼 hgq0011 2008-09-02  

fight_bird 写道

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

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

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

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

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


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

19 楼 tiannet 2008-09-02  

在软件工程中，
需求分析与设计占据了三分之一甚至更多的时间，
我想很多项目都做不到这一点，因为早已经开始编码了，
这也是很多项目代码变得越来越糟糕的原因，
改动越来越多，做了很多无谓的工作。

18 楼 yinyanbin 2008-09-02  

其实一个项目的开发，真正的编写代码需要的时间比较分析需求的时间是非常的短的。
楼主说的这种情况 其实我也碰到过。只不过我们的项目相比较小了许多。我认为这个问题 根本的原因在于沟通上。
其实就是客户和分析人员在需求上的不确定性。分析人员很重要！不光要有很好的沟通能力还要有很强的专业知识。
（这样的人才不好找。呵呵。）   还有一个可能就是和你沟通的对象有问题。有一个现象在中国当前社会是普遍存在的。就是一个事情 你问10个人 10个人告诉你不一样的答案。最后谁的答案对呢？呵呵 领导的～～  而且还有开发的系统谁用问谁，不用的或者相关的人 没有必要听他们的。
沟通是门学问呀。我工作以后最大的感受～～

17 楼 yzz 2008-09-02  

一个比较成功的项目，首先合理的组织机构，人员设置不当，就会出现权责不明确，互相扯皮的问题，这样沟通就有问题，沟通一有问题，就会出现需求集不明确，大家不知中心和重心在哪里？活就必然干不好。其次，如同渴望有一个稳定的需求集一样需要一个稳定、高效、和谐的团队，稳定指人员流动小，熟悉公司的框架，快速启动，高效指工作效率高，工作质量高，和谐指大家一条心，互相帮助。再有就是合理的工作量分配和合理的报酬机制，用好人，留住人。
以上几条是个人意见，有点偏理想化，也是我在努力的目标，每个公司的情况不一样，每个公司都会有一定的加班，但是加班一定要慎用，而且要少用，用多了有害无益，直接后果就是人心不稳，离职率上升，重新开始下轮，导致恶性循环。

16 楼 zqrain 2008-09-02  

我从楼主的10条描述中抽出了相应的关键字：
1）估算
2）需求
3）沟通(其实是指的需求沟通)
4）新人，技术，需求
5）积极性不高
6）对需求不够熟悉，沟通
7）团队成员的不稳定性
8）团队的技术水平
9）要把项目做的更好，满足到用户的需求
10）太多的加班

其中“需求”出现5次，技术出现2次，沟通出现2次

于是可以得出结论：从这3个方面入手找解决办法！

感觉这个项目经理实在够可以的！呵呵！

15 楼 celine 2008-09-02  

失败之关键因素，说白了就一点：没规矩。

14 楼 zhangxingxingye 2008-09-02  

真的很可惜！计划赶不上变化

13 楼 fight_bird 2008-09-02  

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

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

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

12 楼 hgq0011 2008-09-01  

Lucas Lee 写道

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

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

这个例子非常贴切。原本我们是使用vantage的ERP系统的，可现在它的版本存在小数位双单位的问题，我们只能等它们的下一个版本。那时项目经理已经给老板承诺了。没有办法，经理才觉定我们自行开发，那么要做的东西非常多了，准备基础数据，系统的转移了，新系统的开发了，和分公司系统对接了，，，，所以有很多的问题没有考虑到，又有很多的问题冒出来。所以搞不定了。：（项目经理告诉我，他说在人很急、盲目的时候，人的眼睛就很蒙分不清方向了。当初他就是这样的。

我真的感觉加班确实没有效率。公司现在准备推行精益生产理念，希望能够有所改善。

11 楼 gurudk 2008-09-01  

我也曾经苦恼过，下面是我的总结：

http://gurudk.iteye.com/blog/65411

10 楼 LucasLee 2008-09-01  

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

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

9 楼 hocus 2008-09-01  

cyberblue 写道

只要卖出去了，在市场部看就是成功的   : D

延期项目＝成报昂贵＋资源浪费＝失败项目