为什么项目总是失败?

做了很长时间的开发，也带过一些项目，有过很多成功和失败的经历。

一些失败的项目不断促使自己思考如何才能把项目做成功，也看了一些关于项目管理和敏捷开发方面的书籍。

自己总结下来，发现项目失败的原因大概是两方面：

1. 缺少方法， 不知道如何应当使用那些方法来保障项目的成功。

这个方面可以通过请教、多看书、不断实践来提高。

2. 还有一个重要原因是人性的弱点，"超越规则"的侥幸心理。

近期报道的中国式的过马路，凸显了国人不遵守规则的心理。因为人总会认为自己是个特例，明知道规则的情况下，总是认为自己能够超越规则而能够成功或者避免惩罚。

这也是软件项目中同样的失败案例不断重现的原因，即使我们有前人总结过的经验教训。

比如:

你明知道这个项目不可能在3个月内完成，但是迫于老板的压力，你会觉得自己能够超越当前开发效率满足这个不切实际的幻想。

下面是我总结的一些团队开发的规范，只是初稿，非常欢迎园友有其它的建议或者补充。

"你我是朋友，各拿一个苹果彼此交换，交换后仍然是各有一个苹果；倘若你有一个思想，我也有一种思想，而朋友间交流思想，那我们每个人就有两种思想了。"

 

项目经理

1. 项目开始前组织培训
使用的工具和技术， 如git, log4net, Resharper, Redmine, NAnt等
项目编码规范
项目使用的框架和设计培训
2. 每日构建
每日构建要能够自动化执行。
覆盖以下内容来保证项目质量:
单元测试的代码覆盖率达到90%，每日构建能够成功通过
所有代码运行过程, log4net可跟踪
通过自动化的验收测试
每天使用NAnt做每日构建，运行单元测试，代码质量检查，代码重复检查，安装包制作和发布
3. 关于测试数据
在项目开始时，着手准备建立和维护一套数据库结构和测试数据，测试数据要达到以下要求：
测试数据应当全员用一套，可以方便的导入和恢复到初始状态
测试的数据库结构和数据要有版本管理
测试数据应当用相对有意义的数据，比如User Name 不能用asdfasdfas这种， 而用Peter, Jim等。
当bug发生时，如果可以通过补充特例的测试数据达到覆盖bug的效果，应当补全这部分测试数据
4. 每日的站会和分享
组织项目成员站会，关注项目block issue
成为站会的组织者而不是领导者，发挥集体成员的主动性来解决问题和分享经验。
分享的内容与重要，大小无关。可能只是发现了一个更好的Api的使用，一个变量命名不好的错误等。
让团队成为一个自主的，自我提高和修正错误的团队。
5. 关于知识分享工具
团队中不断建立的规范、知识、用户需求等，需要有种方式记录和传播。以避免进入新的成员时，只能依靠经验和记忆等不可靠手段来传递的方式。
推荐使用Wiki
6. 关于项目中使用的第三方API或控件
使用第三方API或控件时, 任何对商业使用收费，或者免费但不开源的，都需要得到客户的认可和同意付费
团队需要考虑第三方API或控件的稳定性，和可维护性，避免开源项目暂停或者停止维护等问题
如果是和客户的技术团队合作，即使使用开源和免费的，也需要得到对方的同意。

 

开发人员规范:

添加注释
1. 类注释
类的注释，需要描述类的功能、依赖和如何使用
2. 代码注释
复杂的逻辑应当添加注释
3.使用Region
使用关键字region注释使代码更加整洁
4.全局变量注释
每个全局变量需要写注释
5. 程序流程变化注释
switch, if, while 等条件判断地方必须写注释
6. public方法注释
public的方法体中的代码，需要写好详尽的注释

编码规范
1. 单行代码宽度不能超过150, 单个.cs文件长度不能超过600行. if, while, for, switch等的嵌套必须<=3
2. 少定义委托，多使用Event, Func, Action 和 Predicate
3. 对于public的函数， 不要太长，可以分拆成多个private方法减少代码长度.
4. 变量命名
4.1 控件的名称，不允许是button1, textbox1这种无意义的名字
4.2.使用能读懂的命名(尽量使用全名)
4.3 Event等delegate的命名
Event的命名要体现出事件, 如...Changed, 体现发生了什么，而不是告诉要做什么
bad: publicEventHandler ExtendOrderDetails;这里直接告诉别人做什么
good: public Action<bool> OrderTrackTypeChangedToOther; 这里只是告诉别人发生了什么

单元测试
1.尽量在项目中覆盖单元测试，依据项目不同，团队可以制定自己的标准(如代码覆盖率等)
2.修复bug前，先写单元测试覆盖bug, 然后再fix bug

类
1.单一职责
业务逻辑类中不要包含界面相关代码
切实保证这个类中的代码，和类的名字(定义)一致。
只告知外界本类内部发生的事情，不要直接发指令让外界做什么。例子: 类中的delegate, event, 是用来告诉类内部发生了什么，不要指导外界做什么。
尽量隐藏类内部的实现细节。比如MS的File类，包含操作文件的方法实现，但是外界不需要知道具体如何实现的。

2.类应当尽量依赖其它小的类，依赖的其它的类应该尽量放到构造函数中
假如有一个拧螺丝的功能类，只需要一个扳手就能解决问题，那么不要让这个类依赖于一个工具箱

3.减少依赖于类, 应当更多的依赖于接口
把上面的扳手类抽象成一个接口，让拧螺丝的功能类依赖于接口

4.尽量少的使用全局变量
全局变量需要写好注释，解释全局变量的作用
全局变量不要在类中的私有方法中使用

评论

15 楼 justrun1983 2014-05-19  

能加上文章的出处吗？
这个是我博客园上2013年3月31号的原创文章的。

http://www.cnblogs.com/JustRun1983/archive/2013/03/31/2988213.html

14 楼 yang4187668 2013-04-03  

项目成功或失败并没有什么固定的标准，大概每个人标准都不太一样。假如失败，我认为PM至少占80%的责任。

实际开发中，开发人员内部讨论各种方案的取舍，少数服从多数原则或者PM认定原则，项目继续，项目后期，我们往往发现少数人的意见多为正确的，少数人提出的种种可能会出现的问题一一应验，但是多数情况并不影响项目的上线与验收。

13 楼 dwbin 2013-04-03  

如果楼主按照自己罗列的来做，我愿意1赔100赌你下个项目还是输，程序开发不是垒砖头，也不是销售，最主要的是要使用人的创造力，真正懂的的人会因时制宜，因地制宜，因人而异。流程只是用来保证主线的。
还有就是人的活力才是最重要的，所以领导或者PM一定要懂得活跃团队的气氛，然后把一些出力不出功的人去掉，把总是提很多不在正题上的意见的人去掉，然后剩下的人给予最大的自由的发挥的空间，项目很难失败的吧？

12 楼 hardPass 2013-04-02  

damoqiongqiu 写道

虽然项目失败的原因多种多样，但是我发现，这些因素里面总是会出现下面这一条：
领导太二逼

话糙理不糙

11 楼 v_sunshine 2013-04-02  

damoqiongqiu 写道

虽然项目失败的原因多种多样，但是我发现，这些因素里面总是会出现下面这一条：
领导太二逼

虽然咱不太喜欢在背后说人啥，但是，就目前而言，俺只想对目前的领导说：您要是二的程度轻一点，也不至于这么豪华一团队给您弄的分崩离析！放眼部门看看，除了最元老的那个团队，还有哪个团队有被您一手糟蹋了的这个团队更牛B的？

10 楼 guooo 2013-04-02  

damoqiongqiu 写道

虽然项目失败的原因多种多样，但是我发现，这些因素里面总是会出现下面这一条：
领导太二逼

这个问题很致命的

9 楼 damoqiongqiu 2013-04-02  

虽然项目失败的原因多种多样，但是我发现，这些因素里面总是会出现下面这一条：
领导太二逼

8 楼 zhang_xzhi_xjtu 2013-04-02  

其实，一个项目成功的标准是什么，也是一个值得思考的问题。
不能只是在开发或PM的角度去想这个问题。

7 楼 woaiwofengkuang 2013-04-02  

只能说太理想化了。

6 楼 cloudzb 2013-04-01  

可以借鉴学习。不过具体的项目还是需要具体的实施的。

5 楼 wengui_chen 2013-04-01  

很多定制项目直到签订合同后，客户具体需求可能都是模糊的一个概念，在开发阶段不断的推倒重来，不知觉中项目周期就给延长啦。可能很多人可能会提出我们在合同阶段就应该明确项目的具体需求，开发严格按合同内容进行，但悲剧的现实是甲方永远是强势的一方，只能是作为乙方的我们作出妥协，要么项目就根本无法继续开展。
个人觉得关键还在于我们行业整体的弱势造成，永远是我们迁就客户，掏钱才是上帝。

4 楼 haohao-xuexi02 2013-04-01  

freezingsky 写道

根据亲身经历的项目，有如下体验：
1.很多项目都是定制型的项目，不少都是企业的内部系统。
2.问题的关键不在于所使用的技术，和技术的使用水平如何。
3.项目的失败大多是由于需求方要么连自己想要什么都不知道，要么，需求方的方案变得太快，最终大家折衷，各自收钱不办事。
4.项目时间太赶，一年的东西，三个月连需求带设计出来了，然后推倒反复如此，大家最后觉得无语了，但钱又花了，只能破衣服破穿。

是啊，项目最后都破衣服破缝了。。。。凑合验收。。

3 楼 freezingsky 2013-04-01  

根据亲身经历的项目，有如下体验：
1.很多项目都是定制型的项目，不少都是企业的内部系统。
2.问题的关键不在于所使用的技术，和技术的使用水平如何。
3.项目的失败大多是由于需求方要么连自己想要什么都不知道，要么，需求方的方案变得太快，最终大家折衷，各自收钱不办事。
4.项目时间太赶，一年的东西，三个月连需求带设计出来了，然后推倒反复如此，大家最后觉得无语了，但钱又花了，只能破衣服破穿。

2 楼 liuxuejin 2013-04-01  

主要的原因：老大想越快越好 。一年的项目 老板想3个月。人员不变。哪有不失败的。

1 楼 mib168 2013-04-01  

总结一套系统的方法不错，不过不同团队人员的因素多样化，灵活运动确实很难，人的性格迥异呀 呵呵