只要有软件项目,世界就会想知道为什么他们经常失败.
我想知道是否有一个列表或类似的东西,显示今天有多少软件项目失败.如果在过去的20 - 30年间进行比较会很好.
您还可以添加软件项目失败的主要原因.我的是"要求很差甚至不存在." 其中还包括"无(真实)客户/用户参与".
编辑:几乎不可能清楚地定义术语"失败".假设失败意味着:该项目超出预算和时间的10%以上.在我看来,10%+/ - 是一个很好的报价/招标范围.
编辑:直到现在(2月11日)似乎大多数海报都认为项目失败基本上是项目管理的失败(无论失败意味着什么).但恕我直言,大多数开发人员对这种情况不满意.也许是因为当项目不成功时,经理不会受到惩罚,而是懒惰,无能的开发团队？
当我阅读帖子时,我也可以听到开发者方和管理方之间存在很大的"差距".期望(也许也是要求)似乎是如此不同,一个项目最终不能成功(随着时间/预算;用户不满意;并非所有第一prio功能都实现;太多错误,因为开发人员被迫在太短的时间内实施...)
我问自己:我们怎样才能改善它？或者我们是否有可能改进它？每个人似乎对现在的方式都不满意.我们能缩小这两个世界之间的差距吗？我们(开发商)是否应该继续罢工并争取"高质量的反应"和"基于现实/迭代的时间表"？
编辑: Ralph Westphal和Stefan Lieser创建了一个名为" Clean-Code-Developer "的新"社区" .该小组的目标是为软件工程带来更多的专业性.如果开发人员具有一定程度或数年的经验,您可以独立参与此运动.
清洁代码开发人员每天都像SOLID一样遵循原则.专业开发人员是他自己工作的最大评论者.他有一个内部价值体系,可以帮助他改善并变得更好.
请查看: 清洁代码开发人员
编辑:我们公司目前正在做一个名为"应用程序开发和维护基准测试"的事情.这是IBM提供的一项服务,用于获取外部人员对您的软件工程过程质量等的反馈.当我们得到结果时,我会告诉您更多相关信息.
管理不善.
项目不是基于项目的某些基础功能的成功或失败,而是基于它们是否满足用户的需求.(它们可能完全失败,在这种情况下,对可能的事情存在严重错误.)主要是在评估项目的可行性和成本效益比,确定目标,软件项目往往失败或成功.
处理事实和事物的人(如程序员)与处理其他人(如销售类型和经理)的人之间存在脱节.对于程序员来说,事实是事实,必须加以处理.对于销售人员而言,事实是其他人的想法,并且是可变的.
有形和无形事实之间也存在差异.没有人认为如果他们真的有动力,工人可以在一个月内修建一座大桥; 他们可以看到所有钢筋混凝土和其他必须移动并固定到位的东西.软件不那么有形,缺乏物理限制:虽然理论上在一个月内建立桥梁甚至没有可能,但可以想象一个团队可以在一个月内创建一个大型项目,因为他们必须做的"全部"第一次让一切正常.实际上每天可以输入数千行代码; 只是它们可以按原样使用的几率非常接近零并不重要.顶级开发人员的实际生产力实际上在字数上非常不起眼,
因此,那些习惯于灵活事实的人并没有强大的物理限制来提醒他们事情只能推到目前为止,不了解编程实际需要什么,也没有好好感受到实际可行的生产力.此外,他们知道如何在谈判中找到自己的方式,远远超过普通开发人员,因此在谈判他们倾向于在现实世界中承担的可能性更多时,他们会得到更多.
与此同时,软件开发本质上是模糊的,因为生产实物产品是微不足道的.一旦开发完成,我就可以快速而廉价地制作软件副本.软件开发是设计工作,纯粹而简单.通过诸如编译器和向导以及代码生成之类的东西,无情地消除了与制造相对应的任何事物.面对想要不可能的经理的开发人员发现很难说不可能实际上是不可能的,因为没有办法说这实际上是不可能的.鉴于事实不足以让人感到灵活,具有强大谈判技巧和决心的人通常会得到他或她想要的答案.
鉴于这种脱节,人们可能会问,应该由谁来弥合它.在我看来,答案很明确.了解不同人的想法的责任属于专门与他人打交道的人.协调不同类型人员的责任属于协调这些事情的人.因此,经理.
了解软件开发和开发人员,并能与其他经理打交道的经理人会做得很好,他们的项目通常会成功.世界上还有太多的其他类型.
这不是一个直接的答案,但我发现虚拟案例档案是一个引人入胜的案例研究,研究一个由政府支持的大型资金充足的项目如何能够成功.
您还可以添加软件项目失败的主要原因.
另一篇IEEE Spectrum Online文章" 为什么软件失败 "检查了这个问题.它总结了以下主要观点:
不切实际或不明确的项目目标
对所需资源的估计不准确
系统要求定义不明确
报告项目状况不佳
未管理的风险
客户,开发人员和用户之间的沟通不畅
使用不成熟的技术
无法处理项目的复杂性
邋development的开发实践
项目管理不善
利益相关者政治
商业压力
计划不好.
霍夫施塔特定律
即使考虑到霍夫施塔特定律,它也总是比你预期的要长.
老实说,我认为这是因为大多数程序员并不擅长他们的工作(我并不仅仅意味着只是编写代码).stackoverflow上的人可能是例外.我不知道你们其他人,但作为一名顾问/合同程序员,我曾在很多地方或周围工作,平庸或差的程序员与好的程序员的比例约为10比1.
我的优势之一一直是准确估算,然后准时交付,在预算内或预算不足 - 我总是希望在成本和准时下达到10%.然后我想告诉我的客户,因为我做的事情比预期的少了$$,你想加入哪些"额外"？
即使是功能完善且迟到和/或超出预算的产品,也会被许多业务经理视为失败.程序员通常只关注他们所做工作的技术方面,而不考虑成本或截止日期.你真的需要做好这三件事才能被认为是成功的项目.还有很多其他程序员可以毫无疑问地在我周围编写代码,但对于为项目付费的人来说,这已经不够了.
管理不善.
SW项目通过让开发人员针对感知问题开始.随着项目的进展,业务需求趋于明确.在截止日期前加入新功能.投入更多开发人员.原始项目成员退出或被解雇.到目前为止,太多的时间,金钱和资源投入到项目中,因此无法取消.截止日期过后,尽管成品明显缺乏,但该项目已宣告完成并取得成功.
来想想吧 - 我看到一个SW项目失败了......
这是因为似乎没有人再阅读了.项目失败的每一个原因都经过一次又一次的分析.您只需要阅读三本书就可以了解80%的项目失败的原因:
截止日期:关于项目管理的小说(Tom Demarco,1997年出版)这是一个很棒的介绍,非常有趣.Peopleware:富有成效的项目和团队(Tom Demarco,1987年出版)The Mythical Man-Month:Essays on Software Engineering(Fred Brooks,1975年出版)
我们作为一个职业似乎每隔3 - 5年就会忘记一切(参见"集中计算效率低下;让客户处理它"与云计算相比).
京公网安备 11010802040832号 | 京ICP备19059560号-6 