我最近有一个项目几乎惨败。对我来说，这是一次彻底的失败，但不知何故，它通过了，不应该通过，只是通过了。各方都有很多善意，责任也同样分担。但现在我把项目文件放入“冷库”，我想知道“最坏的情况”会发生什么。你在一艘正在下沉的船上，复杂性正在爆炸，因为规范中存在一个(不那么)小漏洞，客户完全崩溃了，这根本无法完成
是否曾经不得不在中途说服自己完全放弃一个项目？结果如何？
你的 react 是什么？你做了什么(或打算做什么)来避免将来发生类似的事情？比如“从现在开始，要么是困惑，要么是失败”，“该死，我再也不会做xyz了”，“嗯，我的保险涵盖那个”，甚至可能是“糟糕的事情发生了，别提示了，过去吧”它”？
最佳答案
我们有一个项目，其中一项要求是保证响应时间。经过几个月的开发，我们无法兑现这一 promise 。更糟糕的是，我们把这个问题隐藏得太久了。演示是这样的:这是最后一个里程碑，顺便说一句，我们错过了响应时间的事情。彻底的灾难。我没有参与接下来的谈判，但据我所知，这很丑陋。毫无疑问，存在必须解决的技术问题和设计缺陷。但在我看来，最重要的后果是:我们现在更加重视状态报告。不是以微观管理的方式，但至少更简洁。问题必须更快地出现。现在的内部和外部演示周期比以前短了很多。当然，仅凭这一点还不能解决问题。但我们本可以及时投入更多、综合的资金来解决这个问题。而客户的 react 可能没有他那么强烈。我认为你不可能把失败的概率降到零，所以是的，“糟糕的事情发生了，克服它”。但你可以努力让它尽可能低。你可以研究所谓的失败程度。因此:尽早进行状态检查，尽早解决问题，不要让裂缝变成船体缺口。
关于project-management - 曾经不得不说服自己或多或少完全放弃一个项目吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/802551/