在一个项目上注定要发生厄运的警告信号是什么？[关闭]

不管使用哪种语言，行业或经验如何，从事失败的项目都是大多数程序员的共同点之一。

这些项目可以是很棒的学习经历，令人心碎的灾难（或两者都有！），并且可能由于多种原因而发生：

• 高层管理者的心变
• 技能不足/资源不足的团队
• 开发周期中优秀竞争对手的出现
• 管理上/下

一旦完成了几个这样的项目，就可以在早期阶段准确地确定一个项目注定要失败的时候吗？

对我来说，一个重要的迹象是，外部的最后期限是一个艰难而又快速的时期，同时又包含了功能的蔓延。我已经看到计划周密的项目，一旦后期的功能请求开始加入并添加到最终的“交付成果”中，按计划进行的项目就会异常偏离正常。这些请求的提议者赢得了Columbo的绰号，因为很少有人离开会议室而只要求“再做一件事”。

您要注意的那些警告信号会引起即将来临的厄运的警钟？

英勇编码

到深夜编码，长时间工作和加班很多，这肯定是发生问题的迹象。此外，我的经验是，如果您看到有人在项目的任何时候都工作到很晚，那只会变得更糟。他可能只是为了使他的一项功能恢复原状而这样做，他可能会成功。但是，这样的牛仔编码几乎总是由于计划失败而导致的，不可避免地会很快导致更多的失败。因此，您在项目中看到的越早，最终情况就越糟。

当程序员开始赢得争论“代码太可怕了，我们需要从头开始。” 在任何成熟的应用程序上。

您可能认为您可以更好地构建它，或者更全面地了解问题，但实际上您没有。哦，还有那些丑陋的补丁？它们是对现实世界中的问题的修复，您可能会在重写中重新引入这些问题。

另外，有一天您将不得不向项目经理解释为什么在6个月的工作后，刚开始时您几乎拥有应用程序所具有的功能的80％和bug的150％。

作为问题解决者的新工具。

当人们开始计划使用不熟悉的工具时，我不介意，但我会密切注意它。当他们开始将这些工具的所有广告收益计划到计划中时，我感到担心。有趣的例子：

• 我们可以节省一个月的时间，因为我们将尝试使用面向对象的语言（即使我们仅有的是c开发人员）。
• 我们将尝试这种新的Scrum方法，它将解决我们所有的流程问题！
• 我知道它已经完成了一半，但是如果我们将ORM更改为新的东西该怎么办？

新技术和实践很棒，但是您几乎永远无法获得所有收益。

对我来说，最大的问题是企业认为书面要求浪费时间，这是您可以立即发现的一个问题。

所以基本上 没有书面要求

这是死亡之吻。

管理断开

当负责截止日期，功能，人员等的人员与负责交付项目的人员脱节时。这可能导致：

• 当客户与不了解功能成本的人交谈时，功能蠕变
• 人月综合症，新开发人员被推迟到一个项目中的时间足以使障碍多于帮助
• 不现实的期限，由必须处理期限决定的业务后果而不是实施后果的人员创建。
• 当中间层的管理阻碍了客户与开发人员之间的沟通时，那些不能解决问题的产品。
• 不良的风险管理，潜在的问题未能在开发人员和管理层之间尽早沟通。

因此，当管理层对项目不感兴趣，沟通不畅，不听客户或不听开发团队的时候，就会四处奔波。

1. 当关键开发人员离开而管理层不在乎时

2. 当主要开发人员离开时，其他开发人员都不在乎

第一通常代表着与团队动态完全脱节的经理（谁是“ 10倍超级明星”，谁是体面的程序员，以及他们如何相互影响等）。

第二个通常表示其余开发人员严重缺乏兴趣。

第一次，通常是管理层有人说“我们没有时间..”

通常出现在我们没有时间不喜欢的东西之前，例如文档或代码审查（从统计角度上查找并纠正其他任何形式的错误，包括所有形式的测试）

让客户，营销人员或管理人员选择一个日期，然后尝试将其倒退到想象中的时间表

如果管理能力太弱而无法对企业说“不”。

这会导致无法满足的截止日期，从而导致IT部门缺乏信心，从而导致开发人员创建黑客行为（例如，在某人的计算机上运行访问数据库...某处），从而导致IT部门陷入噩梦，关键系统”必须迁移，这导致...

我能想到的第一个坏信号是，当管理人员不愿将坏消息传递到链上或传递给客户，希望它会消失时-即通过一厢情愿的管理。我想不出有多少次，开发人员证明他们不能在截止日期之前甚至数月甚至数月之内完成任务，但没人愿意告诉客户。我很少见到有客户会在确实有理由提前解释需求时才提出最后期限的事。当我在截止日期的那一天被告知无法满足，并且第二天也不能满足的时候，却要走两个月，我经常看到一个生气的客户。在这一点上，我可能会补充，他们对您的流程提出了质疑-您为什么不早知道这一点。

另一个肯定会出现故障的迹象是，将新的开发人员分配给流程中最困难，最复杂，最关键的部分，而不是让已经了解当前系统的人员分配。然后，不要仔细看他们，看他们是否真的在正确地完成工作或有疑问（如果没有问题，请大红色标记）。新员工需要受到监控，直到您知道他们确实拥有声称拥有的技能为止。我仍然记得曾经度过一个痛苦的夏天，重做了一名新员工的工作（我已经在截止日期之前完成了任务），他获得了项目的关键部分，并告诉所有人几个月都一切都很好，然后在截止日期前一周辞职而没有通知他所做的一切都没有用。

另一个肯定的失败迹象是，当开发人员正在处理那些首先要完成其他事情而又没有完成甚至没有开始的事情时。如果管理人员无法按正确的顺序分配工作，那么您就不做任何事情了。

当然，每次都不推迟最后期限的功能爬行是最糟糕的迹象之一。您将20个小时的工作加到我的盘子上，截止日期增加了20个小时。如果不是这样，则该项目将失败，并保证。

我在职业生涯中看到过的一个肯定的信号是，当管理层开始谈论引入更多机构以弥补时间表时。我从未真正在项目帮助中看到更多的机构。

当非技术经理开始坚持做出他们完全没有资格做出技术决定时。大，大红旗！

最明显的迹象是人员流动率高。当每个人都在寻找新工作时，您可能也应该这样做。

另一个明显的迹象是缺乏进展。如果一年过去了，而且看起来离目标还差得很远，那注定要命。尤其是当需求变化快于实现需求时，就会发生这种情况。

无聊的团队成员。

您“完成了90％”，下周就可以交货了，但是还可以，因为您剩下的就是“测试”。

• 每个人身心都筋疲力尽
• 客户/用户显然对时间表或他们所看到的不满意
• 原来漂亮的设计现在感觉很妥协
• 您已辞职，但要交付一些您真正想解决的相对重要的错误，但却无法
• 您所保持的自豪感在于运送行为，而不是所运送的物品-更像幸存者的心态而非职业自豪感
• 团队害怕某些事情不起作用，并且忽略了这些部分并希望获得最好的结果，因为他们担心那里可能存在什么
• 每个人都坚信他们已经超越并超越了（他们是对的）
• 人们表现出倦怠的迹象（普遍悲观，无私，愤怒）

（摘自Jim McCarthy的《软件开发动力学》）。

牛仔编码器，大人物及其管理接受度

如果项目计划要求对设计，开发，测试和部署进行一次迭代（经典的瀑布式设计），那么对于一个超过1个月的项目，我会跑一英里。

您不需要完全敏捷，但是缩短开发周期可以使您向所有人（客户，管理人员和开发人员本身）展示进度，并在不可避免的情况下应对变化的需求。

开发人员疯狂奔跑

当您意识到其他开发人员（或不幸的是，您）已经开发了与设计有很大不同的组件，并且直到进行系统/ UAT测试之前，才意识到这一点。我不是在说臭虫；我说的是重要的系统组件缺少功能或对功能没有要求，并且在不进行大量返工的情况下绝不会通过UAT。此问题表明：

• 您的质量体系已损坏；为什么相关的开发人员在设计/实施阶段没有解决这个问题。是否未对代码进行审查/检查？为什么单元测试和集成测试没有做到这一点？如果您没有某种形式的一致的单元/集成测试，那么您会很费力。
• 您的项目经理/技术负责人不受开发团队的控制。如果他们不能使开发人员交付所需的东西，他们将永远无法交付完整的解决方案。

当项目的关键开发人员数周未签入任何代码，并且即将出现一个重要的里程碑。

这是一份承包的工作，并且该工作的高级开发人员和项目经理决定，他们希望组队以争取更大的收益，因此另一位开发人员掌握了三周的关键代码人质。最后，我们解雇了不称职的项目经理（他花了6个月的时间将项目推向破产的道路），并与开发人员进行了讨论。

可以说，该项目的其余部分是受虐狂的行军，规格冻结被延迟，为客户提供了一系列让步功能，以弥补PM离开项目的糟糕安排，并且项目质量受到影响因此，到处都是。

项目经理甚至不愿飞到CDR（关键设计评论）上，而只想放弃与客户的会面并散发出嘶哑的感觉。当他要求在该项目下支付差旅费时，有礼貌地告诉他要私奔。

我可以很容易地从这里找到影响该项目的其他答案中至少找到5个。简而言之，在第一个严肃的编码项目中，我学到了很多刻板的教训。

我的第一个迹象是，当他们问我们每个人将在接下来的十周内加班多少小时，并根据项目的成功程度和截止日期向受薪工人提供加班奖励。

我看到的其他主要迹象：需求定义超出了计划，并且结束日期未移动。我们甚至还没开始就落后了。他们从设计中抽出了时间，因此我们从没有数据库设计，没有站点设计开始，但是期望通过按时完成对尚未设计和创建的表的导入来实现交付。

当关键路径上的项目同时而不是按顺序进行时。（如果需要使用工具X，而程序员A才开始构建它，那将延迟我的任务。）

经理在感恩节提交代码的时间。

当您开始收到日期时间戳记晚于晚上11点且早于上午6点的电子邮件时。

当关于如何处理某种复杂性的每个问题都得到了相同的答案时，“请不必担心”。

当他们仍在进行需求更改时，您可以开始质量检查或上线服务。

当您开始每天开会时，需要花费几个小时来讨论您的进度不足。哦，那是因为我整天都在开会。每天5分钟的会议很好，每天的会议要花一个小时以上，不好。

当数据库团队和应用团队不互相交谈时。

当客户无法按时提供承诺的信息时。特别是当这些是数据导入文件，并且您需要数据库中的数据以检查代码如何工作时。

当您考虑在某个经理办公室外面安装停车灯时，告诉您当天是否可以安全接近他。

我认为通常会在截止日期临近时发现失败的项目。就像您说的那样，功能爬坡和固定的截止日期是杀死项目的肯定方法。

但是，关键是提前发现失败的项目方式。我认为在这种情况下，唯一真正的“厄运迹象”将是完全缺乏“我们何时完成”的定义。除非我们知道这一点，否则我们注定要失败的IMO。

在过去的五年中，我经历了三场死亡游行。以下几件事使我对即将来临的厄运感到直觉。

• 该公司决定由初级开发人员来设计和开发新功能，并指派更昂贵的高级开发人员来修复其错误。
• 该公司将关键软件组件外包给没有所需领域专业知识的第三世界公司。
• 关键时刻的周期是如此紧密，以致人们的健康状况正在崩溃。
• 您的团队领导服用的药会让自己每晚入睡，戒掉工作。
• 客户发送变更单的速度比您分析它们的速度快。
• 您应该在几周内完成数年的工作，但是管理层拒绝冻结功能。
• 您的硬件供应商显然无法按时交付可行的产品，并且您公司的决策者不会考虑任何其他选择。
• 开发人员需要原型设备，因此他们有机会满足可能不切实际的时间表，并交给高级管理人员以使他们感觉良好。
• 第一周：“哦，废话，代码有问题。每个人都停止做新功能并修复错误。” 第二周：“哦，废话，我们不会满足功能时间表。每个人都退出修复错误并编写新功能。” 无限重复。
• 开发工作是在一个国家/地区完成的，质量保证工作都在另一个国家/地区进行，因此，关于错误的双向交流始终需要24小时，而且涉及的人员中至少有一个正在讨论复杂的技术问题他们不精通的语言

对我来说，就是那些负责功能集的人（又名经理，产品所有者，客户...）停止关心或对答案似乎毫无希望的时候。有关功能的问题会引起冷漠和沮丧。很明显，他们对项目失去了投资或信心。

当我从事的一个项目“打动了高层管理人员”时，这件事就发生了。我在问有关它应该如何工作的问题，突然之间没有人提出真正的意见。

稍后，该项目被取消，我编写的所有漂亮代码都被废弃了。

几年前，保罗·维克（Paul Vick）写了一篇关于黑洞项目的出色文章。我认为所有建议都是相关的。（我已经编辑了项目和摘要的长度。）

• 荒谬的宏伟目标。就像“从根本上重新想象人们使用计算机的方式”。
• 完全不现实的期限。通常这是因为他们认为他们可以在比原先花费的时间少得多的时间内重写原始代码库。
• 关于兼容性的不切实际的信念。就像相信您一样，您无需任何额外的努力就可以重写并保留所有这些小怪癖。
• 总是从重要的截止日期起“六个月”，这似乎从未到来。或者，如果确实到达，则将另一个里程碑添加到项目的末尾以进行补偿。
• 必须消耗大量资源。通常通过从一种或多种既有产品中吸取生命线。
• 参与使用尚未被证实的全新技术。这样，他们就可以用新技术消除所有可扩展性问题。

我在脑海中翻译“一切都很好。我们没有什么可担心的。” 每当我听到管理层说这句话时，都会把“我们都搞砸了”。您通常会听到经理在不相关的会议中偶然地扔了它（“哦，顺便说一句，一切都很好。没有理由担心！”），但是召开会议专门说这是一个更大的危险信号。

我还没有听到经理说过这些话，而且还没有骗人。

我曾经参与过的一个失败项目的几点建议：

• 管理层使团队加倍，以更快地完成任务。
• 开发人员开始“埋没”错误以按时完成任务，尽管很明显，但在代码审查期间被忽略。

当管理层将项目同时拉向不同的方向时，运输车保持静止。

我曾经参与一个由两个人管理的项目。他们要么没有互相交谈，要么每个人都有自我解决的决心，但他们大约每星期左右都在向相反的方向指挥我们的工作。没多久就意识到永远不会有任何结果。很高兴我的参与只持续了几个月。

请参阅这篇简洁的文章：IT项目正确时。

如果缺少本文中所述的任何元素，则应设置警报铃声：

因此，请确保您的项目具有以下所有条件，否则请关注：

（引用以上文章：）

1. “首先是它们基于对要实现的目标的清晰认识。”

2. “第二个特征涉及整个企业中有关各方，特别是高级管理层的支持和承诺。”

3. “第三是对要解决的问题的理解。”

4. “最终的共同特征是已经提供了足够的资源和技能。”

从统计学上讲，软件项目的开始是一个失败的合理信号，因为绝大多数软件开发者都会这么做。