如何判断软件开发项目败象？

本文介绍了预示着软件开发必然会失败的26个迹象。

尽管我们竭尽全力让每个软件开发项目获得成功，但有些项目还是一开始就注定会失败。下面是表明企业软件开发项目走向死亡之路的26个预警信号――它们都来自活生生的实际案例。

项目名称在短短三个月里就发生了三次变更。

发经理决定最好给英国用户另外编写一个完全不同的软件版本，而不是编写统一的国际化版本。

开发工作启动了四个月之后才开始定义需求。

新聘请的研究开发主管向董事会发出豪言：项目会比计划提前六个月完成99%；并且向董事会保证软件不用通过β版本测试就可以直接交付给客户。

你是一名Web开发人员。你打开ZIP文件，里面所含的HTML文档是客户为你需要与Web应用程序集成的网站脚本而制作的，结果发现客户的HTML文档全部是以HTML格式保存的微软Word文件。

你认识到，这家公司聘请你做顾问是为了调解两个彼此竞争的部门就使用哪个技术平台而产生的分歧。

备忘录里面写到，你将开发使用16位平台的64位应用程序。

开发人员在不了解规格文档的情况下照样进行开发。质量保证（QA）测试小组也在不知道如何测试的情况下照样进行“测试”。

你看到项目预算后，认识到一半以上的预算用在了Web设计人员制作主页的Photoshop模型上――根本没有考虑这种设计是否切实可行；或者没有关注将存在于该主页下面的成千上万页内容。

用户或客户只要求新的功能特性，而不是关注软件错误改正及性能增强。

你发现一份包含16个软件开发最佳实践的列表，却认识到没有一项最佳实践真正得到了采用。

你被要求把项目从Windows操作系统移植到MS-DOS操作系统上。

技术项目经理在没有咨询任何实际潜在用户的情况下就要求你编写一份用户需求列表。

工作人员开始发函件“给文件”，而不是发给对方。这些函件只是借口而已，试图解释为什么发件人与即将发生的（但未被承认的）失败毫无关系。

状态报告没有按时提交上来。

新来的CIO赶走了深入了解企业组织的所有人，统统换成了从他原来那家公司带来的外人。

这是个大项目，名为“冰山项目”（ProjectIceberg）。或者这是公司第三次试图成功完成该项目，项目代号为“凤凰”（Phoenix）。但你还是认为这个项目无法浴火重生。

连得到免费版本的客户也对软件大失所望。

负责关键任务项目（为公司贡献80%的收入）的经理有三个月时间来选择技术，正在同时对四名新招聘的开发人员进行培训。但上头给这名经理下的死命令是三个月后必须完成项目。

你了解到，管理层非得坚持在第一次代码冻结（codefreeze）后，将接口定义部分登记入库到版本控制系统。

上头更换了项目经理，并且把整个项目从一个城市迁到另一个城市。你暗自庆幸：这两个城市幸好在同一个洲。

质量控制团队被告知“我们只有三周的时间来进行测试”（而该项目已经持续了六个月）；或者被告知“日期定死了。我们不得不在这个日期之前开发完成所有这些功能。”

项目经理决定尝试敏捷开发方法，“目的是为了节省时间”。

在以前移动电话和普遍的互联网接入还没有出现的时代，你远赴法兰克福参加行程排得满满当当的区域性CIO会议，三天后回到纽约总部，却遭到三天前刚被公司任命的一名新项目经理的严厉斥责。原因何在？原因是你没有回复对方发来的电子邮件（但你并没有收到），你自然没有更新他的“项目仪表板”（projectdashboard），你对该仪表板一无所知。

管理层决定在一个成本仅为2万美元的项目头上花100万美元。然后，经理们开始同意计算机公司销售人员的说法：100万美元的软件需要购买200万美元的硬件。与此同时，公司秘书购买了一台现成的个人电脑和含有一些新款办公自动化软件的套装光盘。她在午休时间实施了项目（这个项目大概称得上是成功项目）。

首席开发员告诉你维护所有数据库更新的完整历史记录是应用程序的一项需求，但是他还没有时间（或者说不知道如何）为此设计一个数据模型。于是他决定先着手设计Web前端系统，至于数据模型以后再考虑。而这就是所谓的首席开发员。

业务部门领导/项目资助方说：“要有点创意”。这番话是在管理层把项目成员精简20%之后说的。在IT团队取出原本用于重新利用的旧硬件后，说这就是你项目的新的运行环境。（lynn）

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。