软件项目将死的27个征兆

有时候我们会突然发现自己的项目正在走向注定的死亡。下面这些迹象可以让你提早发现项目失败的趋势。

在数月内三次更改项目名称。
项目经理决定，与其写一个国际化的单一版本还不如针对某个国家写一个完全独立的版本。
需求定义发布于开发工作开展 4 个月后。
新聘请的R&D主管纸上谈兵地表示，该项目将比计划提前 6 个月完成，并且自吹自擂地保证无需经过版本测试就可以直接发布给客户。
如果你是 web 开发人员，你用 HTML 文档打开客户发过来的压缩文件，其网站脚本是需要集成到 web 应用程序中去的。但是你打开 HTML 文档，得到的竟然是 Microsoft Word 文件，以 HTML 格式保存的 Microsoft Word 文件。
你发现公司之所以聘请你做顾问，是为了当两个竞争部门在关于使用哪种技术平台的问题上发生争执时，让你去做调解工作的。
备忘录上面说，你需要在一个 16 位的平台上开发一个 64 位的应用程序。
开发人员不理解 spec 文档，反正在做开发工作了就行；QA 团队不知道如何测试，反正乱搞一通就算测试过了。
关于项目预算，如果你发现超过一半的费用是花在网页设计师创建主页的 ps 模型上——而不去考虑这种设计方案是否可行。或者你注意到成千上万行内容将放在主页上。
用户或者客户要求添加新的功能，而不是集中注意力解决 bug 修复和性能增强的问题。
有一个软件开发最佳实践的列表，然而你一条都没有使用。
项目平台由 Windows 变为 MS-DOS。
项目经理要求你写一个关于用户要求的比较，但是却没有咨询任何潜在用户。
将笔记存到文件中而不是相互发送，这些笔记成了即将到来的失败的借口。
状态报告被视为是在违抗命令。
新的 CIO 用他老东家那里的外行人替换了这里所有了解组织架构知识的人。
这是一个很大的项目，代号冰山。或者为了能顺利成功，经过再三研究，项目命名为了凤凰。不过真的很难说服自己这项目真的能够凤凰涅槃——浴火重生。
即使是免费版本，客户也深表不满。
关键任务项目（掌握了 80％的公司收入）的 PM 需要经过三个月的接触才能确定技术首选，同时还要一次性培训四个全新的开发人员。而此项目的最后期限则只给了三个月。
你认识到在管理上必须坚持：在第一次代码冻结后必须审查接口定义，然后放入版本控制。
更换了 PM 并将项目从这个城市挪到了另一个城市。
QA 团队被告知，“我们只分配到三个星期的测试时间”，或者，“日期已经定死了，我们必须在截止时间之前完成所有功能”。
项目经理决定尝试敏捷方法“以节省时间”。
手机和互联网的影响：如果你在 New York 聘请了一位新的 PM，然后去参加了为期三天的 Frankfurt 地区的封闭式 CIO 会议，那么你回来她绝对会直接变成咆哮帝：因为她发过去的 email 你通通没有回复（实际上你并不知道），也不知道她新的项目规划。
管理层决定花一百万美元去建设两万元的项目。
首席开发人员告诉你，保存所有数据库更新的完整历史记录是应用程序的要求，但是他还没有来得及（其实是：不知道如何）去设计一个数据模型。于是他决定等以后再说。
业务领导/项目投资人假惺惺地说，“只要有创意什么支持都有。”再看前面：刚刚裁掉了 20％的员工，以及将已经回收的硬件又拿出来使用，然后告诉你这是项目新的托管环境。