我是一个由5人组成的团队的开发人员，我相信我们的项目将要走向灾难。我稍后将描述原因，但我的问题是：我应该如何表现？

截止日期为1.5个月，我觉得无论我们做什么，这个项目都会失败。我认为我们应该只是终止项目并停止浪费我们的时间，但是从政治上我认为我们的经理不可能做到这一点。

在这种情况下我该怎么办？我应该付出额外的努力，还是应该轻松些？我该对经理说些什么？

该项目失败的原因：

• 随着截止日期的临近，许多必备功能尚未完成
• 应用程序不稳定且很难使用
• 系统非常复杂，代码很难理解，很难更改-数据模型太受复杂的关系数据库（100多个表）驱动
• 领导不清；经理对新信息做出重大更改
• 几乎没有自动化测试或单元测试
• 严重依赖于其他系统，但尚未进行集成测试

实际上，我们实际上是在1-2个月前从同一个经理下的另一个开发团队继承了这个项目（以及混乱），该团队已经工作了几个月。

在管理阶梯上以最简洁，无对抗的方式传达您的担忧。总结风险，但不要强加于此。

管理层必须始终可以选择做什么，但是评估和传达情况是您的工作。使用电子邮件，以便在事情向南走时留下纸迹。

完成此操作后，请继续真诚地从事该项目。

请记住，您可能不知道有关该项目，其支持者以及背后的财务决策的所有知识。对您来说似乎愚蠢的管理决策实际上可能是基于您看不见的智能推理。

保持书面记录（例如日记，保存的电子邮件等）。仅包括事实和客观观察。将所有结论留给任何人（如果有的话）阅读您写的内容。

作为开发人员，如果您不被视为阻碍该项目的障碍，那么毫无疑问，您很有可能会成功。您的经理可能不太幸运，但这与这里无关。

仅根据一般原则，更新简历，并确保您偶尔会见公司以外的其他开发人员。如果您不属于任何本地开发人员组，请加入2或3。花数年的时间建立朋友和熟人的网络，但从长远来看，这是值得的。请确保将其视为一条2条路-如果您可以帮助有能力的人来填补公司的空缺，那和帮助您找到工作的人一样好。

我建议您花一点时间阅读2本书。

《死亡进行曲》是一本规范的书，描述了软件开发中广泛使用的病理项目管理风格。由于计划压缩，功能过大或管理不善，许多项目最终都处于不良状态。它有助于了解您并不孤单，您的项目并不是唯一的死亡之路。作者Edward Yourdon将死角项目分为4个象限，每个象限都有不同的应对策略。有时，唯一的应对策略是走开。我认为这本书将帮助您弄清楚选择的范围，并缩小可以做什么和不能做什么。

灾难性纠缠是为项目经理撰写的。它旨在弄清楚如何对一个破碎的项目进行分类：需要削减哪些内容，可以削减哪些内容以及如何向客户推销？“常规”软件项目管理将我们带入混乱的项目，而我们也不会一开始就陷入同样的​​想法中来逃避我们的问题。这本书比《死亡游行》更难读，但在书架上却是一本好书。

维持职业/理智的3种简单而愤世嫉俗的策略。

1. 看到正在制造的火车残骸-下车：失败的项目会令员工士气低落，除非您拥有忍者的向上管理技能，否则会对您的职业生涯产生负面影响。如果可以看到任何软着陆，请立即跳转。

2. 如果这不起作用，请不要抬头：人们将开始寻找要责备的人-不要为他们感到轻松！尽管升级管理链上的担忧可能是正确的做法，但这既无效又冒险。您自己的经理不太可能将您的疑虑移交给他/她，这不仅会使你们俩看起来都不好，而且可能会给您打上“麻烦制造者”的标签，即首先应归咎于破坏项目的人，等等。当然，这也意味着要专业，要花很多时间，但绝不要英雄。

3. 计划在T + 1紧急出口：给自己一些选择，并为潜在的内部或外部转移做基础。与人交谈；当项目资金减少时，没有理由等待其他人决定如何处理您，或者在几个月内不可避免地被“迁移”的人所淹没。

道歉，如果听起来听起来太愤世嫉俗，但如果您正确地命名了，那么您就不会感到不愉快。要专业，要乐观，但要切合实际。

这个即将失败的项目会对您在公司内外的职业产生什么影响？以我的经验，仅仅与成功的项目相关联并不表示您个人的卓越才能。

在逆境中表现出的特质，有时甚至是某些失败的特质，往往会被上层人士所注意到，而不是您想象的那样。我所说的不仅仅是您的直接经理。

我个人经历过看到我的直属经理因无能而被解雇，然后在同一天被提升为自己的职位。不愉快，但是它表明人们在看着我，喜欢我的所作所为。

通常，失败的项目会带来同样的混乱和混乱，为您提供了闪耀的机会。

因此，这样看待这个项目：这个失败的项目为我的所有优势和最佳品质提供了什么机会？我将从这次经历中学到什么教训，这将使我成为一个更好的专业人士和一个更好的人？

本质上，从失败中汲取的经验之和是真正成功的动力。

注意：托马斯·欧文斯（Thomas Owens）问，一个人在这样的项目中可以做哪些特定的事情。我有一些一般性建议，在这些情况下，这些建议已用作个人指导。它会帮助遇险项目奇迹般地成功吗？否-但是我发现它帮助我对事情保持了正确的看法，尽管处境不佳也能找到个人成功。

1）专注于个人卓越–努力编写更好的代码，满足更高的质量和功能标准。

2）关注个人指标-您编写多少代码会产生后续错误？将该比例降低到尽可能低的水平。当被要求为分配给您的任务提供估计时，您通常是准确的，还是您发现时间轴缓冲过多/不足？在实际分配任务时，您是否提供有关工作进度的良好反馈，包括提前和提前通知交付时间表问题？

3）关注团队指标-这些只是我无法想到的事情：其他团队成员是否因为对您正在执行的任务的依赖而落后？您是否擅长将任务/子任务委派或划分给团队中的其他人？您是否发现与团队中的一个或多个成员沟通困难？我致力于定期改进的所有领域。

在这种情况下，作为阶梯的最低梯级，您只能做很多事情来帮助项目。

• 确保您的工作一尘不染
• 帮助确定最大的问题领域
• 尝试提供答案，而不仅仅是问题。看起来您正在尝试修复它们。

除此之外，您确实需要照顾数字1。

• 记录一切
• 保留所有电子邮件，即时消息对话
• 尽一切可能尝试摆脱项目

失败的项目可能会对灵魂产生毒害，导致沮丧，过度工作和自卑。

这都是与视角有关的。

我和另一个每天都面带微笑的家伙坐在对面时，我一直在做可怕的项目。哦，我怎么想打他脸上的笑容。

有些人对项目的当前状态不感到困扰。他们享受自己的贡献，他们的任务，并在自己的兴趣范围内合作。而其他人则对当前的事物状态产生强烈的负面反应。这与我们对日常工作的预期期望有关。

当您可能正在做一些喜欢的工作时。当前项目中显然有您不喜欢的元素。

您需要确定这些问题要素是什么，然后加以解决。

• 截止期限压力
• 质量控制
• 专业精神
• 管理层指导

许多团队和公司并不认为上述发展方面很重要。我发现他们经常想到以下内容。

• 截止日期压力被认为是激励人们的方式。
• 质量成本更高，回报极限。
• 专业精神适用于其他业务领域。
• 经理是一个计时员，而不是为发展做出贡献的人。

这些问题不是你的。这是他们的，您不应该在他们的行为上浪费任何精力。如果您不是一个笑着享受他的工作的人，甚至在悬崖峭壁上也喜欢他的工作，那么您应该考虑寻找like minded开发商的地方。

您会更加快乐。

尝试积极主动地寻求新的方法来实现项目的成功。考虑如何提出一些替代方案。现在，您的老板可能会因为该项目失败而被殴打，他是否不喜欢有人提出解决方案而不是问题？

也许有一种方法可以将功能拆分为交错的可交付成果？通常会有一定程度的“必须具备”，因此请查看是否可以优先处理那些优先事项并将其分组为里程碑。在时间轴的末尾拥有一些产品总比没有好。或考虑将团队划分为从事新功能开发的人员和从事稳定性工作的人员之间，这样您可以在两个方面都显示出一定的进步。

如果这些努力成功，则说明您是一个可以找到成功途径的团队成员，否则，您仍将证明自己不会放弃，并将努力寻找解决方案。

听起来像我参与过的大多数项目。但是，它的结局可能不会像您想象的那样糟糕。

1）做好你的工作。只要您完成职责，就不必担心整个项目。

2）CYA。如果该项目确实失败了，并且您怀疑经理会开始责怪除他本人以外的所有人，请确保您有足够的证据证明您做了您所需要的一切（请参阅第1项）。

3）提出一些礼貌的改进建议。不要敲响警钟，不要注定要忧郁，要礼貌而含蓄。

例如，如果团队未编写有效的单元测试（或任何测试），则编写一些与您希望看到的内容更接近的单元测试，并在因果上提及这样做是如何帮助您解决特定问题或节省时间的。

如果您想影响变​​更，无论最终结果如何，都应将重点放在取得具体结果的积极步骤上。这个项目可能永远不会成为赢家，但也许团队可以为下一个项目学习。

也：

4）机会重构是您的朋友。

1. 努力工作; 但不以牺牲家人或健康为代价。
2. 记录所有关键的设计决策；特别是因为它们与您的工作有关。
3. 保持网络联系，并在情况变得过于困难或成为大规模裁员的受害者时保持选择的畅通。
4. 尽量不要将您的项目视为“失败的项目”。每个人都喜欢在逆境中保持积极主动和奋斗的人。因此，尽可能长地尝试成为那个人。乐观的态度，勇气和决心始终对工作场所有益。
5. 如果您要预测失败的项目，那么您将要进行验尸会议。在验尸会议上，每个人都将被追究责任。准备捍卫所有代码。[注意：作为一般规则，您应该始终编写简洁的代码，以便以后保护它。]如果您的电子邮件或设计文档启发了您的决策，那就更好了。
6. 在那次验尸会议上，尽量保持积极态度；并且仅在您的判断，努力或做工受到质疑时出示您的电子邮件和设计文件证据。

我发现最有效的方法是罗伯特·雷德（Robert L. Read）关于如何应对日程安排压力的建议。这是读写的内容：

应对进度压力的关键只是将其转变为上市时间压力。这样做的方式可以使您了解可用劳动力和产品之间的关系。对所有涉及的劳动进行诚实，详细，最重要的是可以理解的估计是做到这一点的最佳方法。它具有允许对可能的功能权衡做出好的管理决策的附加优势。

估算必须明确指出的关键见解是，劳动几乎是不可压缩的流体。您再也不能在一个时间范围内装满更多的东西，而只能在该容器的容积之外装满更多的水。从某种意义上说，程序员永远不要说“不”，而要说“为了得到想要的东西，您会放弃什么？” 产生清晰的估计值的结果将是增加对程序员的尊重。这就是其他专业人员的行为方式。程序员的辛勤工作将显而易见。制定不切实际的时间表对每个人来说也是显而易见的。程序员不能蒙蔽。要求他们做一些不现实的事是不尊重和令人沮丧的。

当您说项目“将要失败”时，这是基于您对需要完成的任务以及每个任务需要付出多少努力的评估。使评估明确，可以理解和详细。将任务分成各个组成部分；尽可能详细地解释如何花费开发时间。

一旦这样做，您便拥有了与管理层讨论问题的坚实基础。一旦您将评估分解为需要完成的所有特定任务，您很有可能证明该工作所花费的时间比您花费的时间要多得多。

与您的经理讨论此详细计划后，请准备好保持灵活性。您的经理可能会说“任务X不会花一个月；最多只需要一个星期”，或者“任务Y完全没有必要，请从计划中删除。” 您当然可以讨论这些要点，但是更重要的是，您和您的经理之间应该对时间表进行一些实际的了解。这样，如果您没有被分配时间进行测试，那么您就有了明确的指令不进行测试，而不仅仅是“出乎意料”地耗尽时间。而且，您的经理绝对有可能愿意明确地偷工减料以便按时发货-在很多情况下，

估算为您提供了辩论和讨论的具体内容。它使您位于同一页面上；这有助于您确信经理已考虑到您的顾虑。而且，如果您的经理明确提出了不可能的要求，那么这对你们俩来说都是显而易见的。如果项目做得好，真正地注定了失败，那么您将清楚地说明这一点，并且将由您的经理来精确地决定他希望您如何度过自己的时间。

由于您的经理知道它可能会失败，所以您比大多数人都富裕。我会考虑与经理一起工作，看看是否可以排除该应用程序的任何部分/功能。

我们常常认为每一个客户的要求都是“交易杀手”，并竭尽所能保证交付。在某人与客户合作并深入调查之前，您可能无法做出这些决定。如果您无法执行此操作，请仍然尝试提供您认为最重要的内容。有时候，请求宽恕要比许可容易。

我参加了三个明显失败的项目。这些都是很痛苦的，但是回想起来，三分之二对我的职业生涯没有负面影响，甚至第三分也不是世界末日。

我记得一些观察。

初级职位的开发人员（“按规范编写代码”，“修复错误”之类的东西）不会受到太大影响，除非他们由于团队士气低落而放松下来。在这样的职位上，明智甚至有时成功的生存策略可能只是尽力而为。

• ^{例如，我经历过的一个失败已通过简单，有条不紊地修复了数百个已知的错误得以解决（再加上特别聪明的方法（通过技术负责人来推动这一进展），最终导致高层管理人员决定恢复项目并给出解决方案。新版本带来了又一次机会，从而取得了一定的成功。}

担任高级，有影响力职位的程序员最好准备好分享项目失败的负面影响。通常期望建筑师，技术负责人，高级开发人员产生巨大的影响，以至于被认为对项目的成败负有责任。

在高级职位上，人们最好准备通过分析出了什么问题以及可以做得更好的事情来“间接地”从失败中获益。

如果学习得当，这些知识点，验尸课可能是无价的，高级职位的非常成功的职业可能取决于对这些知识的学习程度，如WP在此出色的回答中所述：

判断不是来自成功，而是来自失败。大多数公司都想雇用以前的公司为自己的失败付出了代价的人。

从更实际的角度来看，可以考虑将“下一个/更新版本”方法作为解决故障的一种可能方法。偶然地或不是偶然地（我认为不是），但这两个没有破坏我的职业的失败经历了非常相似的场景：释放N是一场彻底的灾难，释放N+1是可以容忍的，释放N+2以及后来都是很成功的。

穿上鞋子，我很可能会花些力气准备/推广“下一个版本”的想法。制作（并进行交流！）类似的已知问题的暂定清单，您希望在计划发行后予以解决。为下一个版本起草非正式的粗略路线图。

想一想如何将这些想法传达给周围的人，如何影响管理层考虑此计划。如果该项目的人员具有良好的营销技能，则可以通过将即将发布的版本包装为更平滑的术语（例如“抢先体验”，“测试版”，“客户预览”，“介绍性发布”）之类的方法，使他们分摊故障损失。那。

考虑一下备用计划，以防万一更高的建议对这个想法充耳不闻。还记得上面有关“修复一百多个已知错误”的故事吗？确实有机会改变。

管理层现在似乎对下一个版本的想法充耳不闻，但是面对强有力的令人信服的项目质量进展证据，他们有很大的机会重新考虑。

• ^{冻结计划发布的代码与管理层决定完全删除它之间的时间很可能会很长。这段时间就是您的机会：如果您将精力集中在解决已知问题上并适当地“宣传”​​进度，那么这可能会有所作为（就像对我而言）。}

这里已经有大量的实用（或其他）建议，但对我而言，这个谜题的关键是以下两项（强调我的意思）：

截止日期为1.5个月

和

...实际上，我们是在大约1-2个月前从同一开发人员领导下的另一个开发团队继承了这个项目（以及混乱）。

所以....

欢迎来到Patsy复仇者联盟

前一个团队要做的事比失败要好。经理以某种方式同意了这一点。在接近最后期限的情况下更换团队并不是最好的项目管理措施，所以……这是怎么回事？

更正：在截止日期之前约3个月，替换了之前的团队。

-> 了解先前的开发团队是如何逃脱的，并做到这一点。<-

3个月几乎没有足够的时间来加速这种明显大小的系统的运行，更不用说校正其体系结构，添加测试并完成它了。你需要更多时间

而且，如果您无法做到这一点，除非您绝对确定该项目将无限期扩展，或者得到魔术精灵之类的东西的帮助，否则您不希望成为最后一个拿着袋子的人。

苛刻？是。但是，尽管先前的团队/经理的计划不周（至少！）不是您的错，但“交付失败” 将是您的错。

先前的团队保释了。前一支球队被踢到路边。这告诉你什么？它告诉我您是周转团队……而您的经理正在依靠您的英勇来挽救一天。

一个5人的团队，还有1.5个月的时间。新团队只进行了1-2个月的项目，因此新团队甚至没有超出学习范围。粗略地猜测这个项目的规模，在我看来，即使该项目根本没有问题，新团队也不会超出学习范围。

所以，我（仍然）认为您已经迷住了。

如果是这样的话-只有您可以决定什么是真实的，或者您想相信什么-您不必欠任何人任何解释或道歉，以免遭受火车残骸的困扰。您确实需要对此保持谨慎。

我严重怀疑经理是否没有意识到该项目处于危险之中，这意味着温和的解释只会给您带来负面的关注。除非您的经理是罗杰斯先生，否则您的未来将处于危险之中。

但请始终记住：不要从互联网上的陌生人那里获得职业建议。

这对您来说是一个难得的机会！让我们从企业家的角度出发。

假设管理层希望这个项目成功，那么您将有很大的帮助他们做到这一点。意识到这一点如此重要的原因是，您必须坚定信念和信心，使您看到的警告信号实际上会导致该项目的失败[1]。

这是您练习系统思考和人际交流中重要技能的机会。了解并可视化遗漏的问题和潜在机会，以便您制定策略以尽可能清晰，简单地进行沟通。

在这里认识到您提高技能的机会。

[1]取消项目实际上是成功的。失败将是在失败之后花费大量金钱。

你能做什么

• 以自己的卓越表现来对待它，这是“他们的”项目，也是您的，即使您知道它会失败，也要拥有所有权。为什么？因为a）您可以帮助它减少失败的几率，b）在遇到困难的时候，这是您学习最多的地方c）您应该通过自己的卓越标准来衡量自己，尽力而为可能不会节省项目，但是您可能最终仍然为自己感到骄傲

• 与其他开发人员交谈，看看他们的想法，您可能会发现许多人也有相同的挫败感，如果做得仔细（不要让别人认为您要发动叛变或其他事情），那么这不仅可以帮助您，而且可以帮助您。其他人也一样

• 忽略问题并不能解决问题，谈论如何克服各种困难，例如至少获得一些体面的必备品，或者正确完成主要的“哇因素”用例，可能会解决这个问题项目失败少得可怜。怎么做？好吧，很少有“时时艰难，时时艰难”或“绝望的时光证明了绝望的措施”等想法，例如：大量使用OSS，极端编程/敏捷方法，周末黑客马拉松（仅限志愿者，不强迫人们周末工作）。在这个时候，您可以表现出领导才能（如果您不在团队领导/高级职位中，请小心），但是您可以利用这一优势并成为他们的嘲笑者，只是让人们感到他们可以使这个项目比失败少一点大家都知道会的。

• 确保您的管理层知道，但是非常非常小心，如果他们知道，他们将不胜感激，您以一种非对抗性的，冷静的方式告诉他们，如果他们不这样做，他们将更加欣赏，并且想知道为什么没人告诉他们之前关于它。您应该告诉他们这是一项服务，没有任何情感方面的支持，只是简单的事实，也没有议程。如果他们问您您认为他们应该怎么做（这是一个好兆头，但很少见），请参阅下一节

您无能为力，但您的管理层可能应该

• 他们不应该更多的人加入该项目“帮助”看到这

• 立即致电客户并告知他们坏消息。为什么这是个好主意？好吧，我将引用敏捷软件开发的宣言，但是即使没有宣言，甚至瀑布爱好者也不会感到意外。如果客户事先知道这个项目注定要失败，他们会很不高兴，但会高兴得多，因为您告诉他们在问题浮出水面之前有问题，并且您已经做好了准备，并竭尽所能它。客户可以做很多事情，但是大多数事情并没有比在最后一分钟发现他们没有交付物（或者他们做到了，但是质量不高）要糟糕。客户会对此表示赞赏，因为他们将能够延迟聘请测试人员，离岸IT人员，更改他们的内部培训计划，并且仅仅是因为您对他们诚实。

• 与客户一起，想办法从项目中做出一些事情，最常见的方法是对项目进行范围界定。例如，有些功能可能很难以设计方式进行开发，如果客户同意一些小的修改和简化，那么某些功能将变得更简单。

• 更新自己的高级管理人员，这也将帮助他们保持自己的工作。

你应该怎么不办

• 要求向项目添加更多人（请参阅此）

• 退出/寻找另一份工作（至少现在还没有），这是您可以从中学到的东西，它可以使您有一天成为一名更好的开发人员或更好的经理。您将学会更好地欣赏许多事情，更好地管理时间，更好地设计，更好地编写代码，以及更好地与同事和管理层合作。如果您不喜欢在那两个月内工作，那不是因为任何其他原因，而是在这两个月后找工作。

• 对项目，管理，您继承的不良设计，您要指导的新手开发人员抱怨，抱怨或否定，这需要您花费3个小时来解释他们所做的事情需要您花费1个小时，要与您一样积极能够。

• 批评管理并成为麻烦制造者的目标，他们俩在同一条船上，他们可能知道您不了解的事情，您所能做的就是更新他们（总是更新您自己的直接经理，永远不要绕过她/他）

• 责怪别人，（或你自己），这无济于事

• 认真对待，除非它是医疗设备，否则如果您错过了最后期限，没有人会死，这是软件，我们错过了生存，放松的最后期限。

这只是我的两分钱，YMMV

找到项目遇到的问题，并尝试客观地明确量化。使用每个“指标”进行量化时，请确保定义您认为该指标很重要的原因。您想让您的经理了解如果某个指标不在“可接受范围”内将带来的后果。您需要为每个指标提供一些指导，以指示哪些值是“良好”，“可接受”，“有问题”或“不良”。预先定义每个条件。如果可能，您可以描述一个项目成功所需的最低限度内容，并将其与当前项目进行对比。

• 可以通过许多静态分析工具来量化静态代码质量。您可以按照自己的意愿将其保持简单或详细。我建议您从以下指标开始：
  • 圈复杂度
  • 代码的大小（例如，每个函数/类的行数，文件数，表数...）
  • 确定哪些模块太大
  • 复制。
  • 坚持代码风格
• 缺陷率
  • 每个KLOC（按模块和/或子系统）（确定系统中有问题的部分）
  • 您可以计算每个团队成员多少钱，但我认为您应该自己保留
  • 解决与发现
  • 解决错误所需的时间（也许如果有问题，请绘制此图）
  • 如果以目前的速度持续下去，也许可以估计需要多少时间
• 规划
  • 推断用于构建功能的时间。考虑到功能的复杂性。这不必很精确。您想要传达的是“特征A，B和C与D，E和F具有相同的复杂度。如果计划的时间，ABC使用170％的特征。如果没有变化，我们期望相同DEF需要时间”或“平均功能花费比计算时间长X％的时间。我们没有理由认为其余功能更易于构建，因此我们应该在以后的计划中对此进行补偿如果不切实际，没有计划是没有用的。
  • 尝试每月或最好缩短发布时间。如果只是内部的。这可以帮助您进一步推断项目所需的时间。这也可以使您免于做出不切实际的承诺（如果您在发布完成之前不致力于新工作）。为每个缸进行计划，并确保新功能仅进入下一个循环（即，永远不能将其添加到当前循环中）。
• 测试覆盖率：说明“正常”的测试覆盖率值并显示您当前的覆盖率是多少
• 文档：实际记录了多少％？有多好？
• 模块化：
  • 基于类（耦合和内聚）
  • 基于套餐
  • 基于子系统（有多少个通信路径？）

无论项目是否成功，您都应该去上班并做任何事情。您将获得报酬执行您的工作。尽力而为。假设您不是项目经理/负责人，则决定是否取消程序不是您的责任。您决定松弛的决定与您决定取消项目的决定相同。那不是你工作描述的一部分。

但是，从更大的角度看，这并不意味着您应该每周工作50、60或更多个小时才能达到时间表。再次，这是管理层的工作，以弄清楚如何实现项目目标。每周工作50小时以上不是一个合理的选择，除非他们愿意支付加班费并且您愿意保留家庭生活。再次，制定可实现的时间表是管理层的工作。他们不能假设他们可以强迫员工为了满足不切实际的时间表而无视他们的家庭生活。

此外，时间表可能会说还剩1 1/2个月。那可能不是“死亡”日期。某些客户可能会在那个日期之前拿走您拥有的东西，即使不是全部。一些客户可能已经想出了额外的资金，因为他们已经在该项目中投入了大量资金。有时，公司本身可能会承担额外的费用，以确保客户满意。所有这些都是您无法控制的。尽力而为。这将为管理选项提供帮助，使灾难项目成为一个成功的故事。我已经看过很多次了。

我只能重申别人说的话，但我要强调：始终努力争取最好的工作，并保持书面记录。出于CYA和技术原因。

您遇到的任何后果都取决于管理层的个人性格；但是，让我告诉您，面对无能的说谎管理者，这真是太糟糕了。但是最糟糕的是，您会保留自己（和同伴）的尊重。

充分记录“死亡行军”的技术方面。当您遇到不可避免的面试问题时，您是否参加了失败的项目？为什么会失败，您怎么做才能阻止它？骨头管理不是答案-即使是原因。

认为这是不可避免的，完全失败的并且只是放弃项目是一种容易的方法。作为顾问，我经常受邀为处于退化，失败或失败的各个阶段的项目提供帮助，而我所获得的部分报酬是恢复并完成了这些项目。

您认为完全失败的情况可能不会被每个人都这样认为，具体取决于透视图。在理想的世界中，每个功能都可以完整地完成，优雅地编码，并且独立于其他系统和测试的每一行代码。我还没有见过像第1版中那样的单个项目。在现实世界中，交付项目意味着做出一些妥协，甚至可能缺少一些关键功能，但该产品可以交付，尽管充其量是Beta版质量，至少您会获得有关首先要解决的问题的反馈。这样做的好处是可以通知管理层软件从未完成，而不是尝试在真空中开发特定的v 1.0，最好以敏捷的方式迭代和响应更改。最后，对于您这个职位的开发人员来说，我认为关键是要在这种情况下开发尽可能好的代码-记录下来，自己编写测试，如果必须的话（尤其是对于外部依赖项），并利用对系统的了解来传达哪些功能是真正关键的，并且必须-有，哪些可以等待一周或一个月。让自己对您的疑虑发表意见，并像对我们一样对它们进行辩护。除了为计划B做好准备之外，还应为您和其他可怜的人可能会在产品交付后修复所有错误且尚未完成代码的事实做好准备-如上所述，这意味着以模块化解耦的方式编写代码-如果您认为持久层代码不好，希望您可以在下一个版本中完全替换它。最后，不要绝望-处理这种情况是您的一部分 被支付，这是一个学习过程。无论该项目的结果如何，这都将是未来的宝贵经验。