在理想的情况下，最好在截止日期前减少错误。但是从您的经验来看，这是更可取/可接受的：

1. 赶在最后期限之前，但是有很多错误，因为开发人员急于解决问题
2. 错误少，但不能完全按时完成，因为开发人员在编写代码时非常严格

这个问题的答案在很大程度上取决于业务目标以及客户。

企业：

如果您要与在市场上建立良好的企业级客户进行业务往来，则他们的灵活性较差，无法快速适应变化。因此，在大多数情况下，稳定性是绝对要求。研发和进入新的垂直领域也有例外。在某些情况下，更快完成。

这些类型的客户通常都知道，好的软件需要花一些时间才能开发，并将与您一起努力实现目标。

初创企业：

对于新的创业公司，规则大不相同。作为一家初创企业，您需要立即了解所构建的产品是否确实可以满足您的市场研究预测的需求。对于一家初创公司而言，尽快将原型投放市场可以获得有关产品发展方向的大量宝贵反馈。

它还可以使您成为市场领导者，帮助您在新的垂直市场陷入竞争之前获得宝贵的市场份额。

由于初创企业规模小，灵活且可以快速适应变化，因此该模型最适合他们。

总之，还有其他因素需要考虑，但是主要思想是每个项目都是不同的，并且具有不同的质量和上市时间。由高层管理人员决定有效的业务战略，包括对选择一种方法而不是另一种方法的机会成本进行全面分析。

或... 3.削减不必要的功能

有时，由于客户要求的技术糖果或糖果功能，截止日期很难达到，并且必然会产生更大的漏洞。它是KISS和YAGNI原则的应用。

从本书 “ Rework”中引用，软件需要的功能/核心/中心是业务运作所需要的，就像热狗架可以是没有任何浇头的热狗架一样，您不能砍掉的是热狗。

重新谈判

要学习的最困难的事情之一就是如何使客户满意，而根据我的经验，这可以通过较小的产品迭代次数轻松实现。

有时，截止日期要求从第一天开始，该软件就必须以较高的生产水平运行。经理/客户并不总是（大多数时候）知道他们对该软件的实际需求。因此，请尝试削减不必要的功能并保持质量。最后，它取决于生产环境的关键程度，但是请尝试删除额外的功能并提供质量。再次引用“返工”：

以后做也意味着做得更好

...并在截止日期前减少错误

好吧，您可以这样构成：您现在还是以后要为质量付出代价？首先要么花时间做好它，要么稍后再花时间解决所有问题。我要指出的是，此功能开发后的错误修复阶段可能会比较昂贵，因为由于现有代码已经存在并且质量可能不够高，因此它也可能风险更大并且更容易受到骇客解决方案的攻击。

在截止日期前提交已知问题列表。

人们讨厌发现错误，但是如果事先告诉了他们，它们往往会宽容得多。

这完全取决于情况。

有许多因素需要考虑：

1. 推出补丁有多容易？
2. 是否有可能发布基本的简化版本，然后随着时间的推移修补新的（边缘情况）功能？
3. 这种产品在客户行业的一般文化是什么？他们是否希望一次性发行完美的发行版，或者他们习惯了一个不断发展的系统的想法，而该系统在首次发行时可能会出现问题。
4. 有问题的初始版本会给企业带来多大的风险，而不是延长截止日期？

简而言之，对此没有黑白回答。例如：对于像嵌入式系统这样的东西，很难在现场部署到设备上，而且成本很高，那么最好尝试等待（如果可能，请重新协商截止日期），并尽可能地消除错误。另一方面，对于大型门户网站系统（写为网络应用程序）之类的东西，可以随时通过发布修补程序轻松地对其进行升级，因此发布最初不可靠的版本可能更有意义，并且然后修补问题（以及边缘案例的功能）。

但归根结底，以我的经验来看，这更多的是业务决策，而不是技术决策。如果您处于错过最后期限的情况非常重要的情况，而拥有越野车的初始版本则不是（反之亦然），那么在做出决定时，您需要权衡这些因素。

注意：作为程序员，我当然更喜欢在释放产品之前尽可能完善产品的想法（哎呀，我什至根本没有最后期限；）。但实际上，这在现实生活中是不可能的。通常，精简的初始发行版是一个很好的中间解决方案。

我已经看到很多PM害怕告诉客户我们无法满足时间表，并坚持认为我们会附带已知错误。我可以告诉你，他们每次告诉客户时，他通常对减少错误和缩短截止日期更加感兴趣。我保证他们会比遗漏的截止日期记住更多的错误，除非该截止日期是绝对不可移动的（例如，当您使用税务软件时是纳税申请季节的开始），否则会影响其他一些非常昂贵的事情（恕我直言所有截止日期的98％不符合这些条件。

我认为这取决于错误。您是否要延迟发布以修复在任何计算机上启动应用程序时该应用程序崩溃的错误？当然是。您是否需要解决仅在Windows ME发生满月的情况下发生的错误？那可能可以等待。

如果这是一个严重的错误，则最好放下2号手。原因是，如果必须在更新中推出该修复程序，则修复成本将成倍增加。

对于不太重要的更新，您可以发布捆绑的更新，从而在某种程度上降低成本。

如有疑问，我说您会选择＃2，但是如果采用这种方法会受到管理层的压制，我不会感到惊讶。我怀疑管理人员往往会比在不引起不必要的关键更新方面更能根据截止日期的表现来判断。

都不行 为什么不使用代码来提高质量呢？能够使用质量代码在截止日期前完成？您可能会推出较少的功能，但是如果将质量融入流程中，则可以同时实现两者。

现在发生的事情是，您需要一个授权的团队负责人或开发经理，他们可以推动业务发展并围绕两件事进行对话：

1. 质量融入代码=每个构建减少2个功能
2. 优先考虑利益相关者真正需要的最高功能。

然后，您可以专注于最高价值的功能并将其出色地推出。

就测试而言，它永远不会完成。它结束了，但是从未结束。

选择具有严重性和更高优先级的错误进行发布。

在截止日期前遇到很多错误，会使您在该行业中处于劣势，并且客户不会再找您。您可以与客户交谈以将延迟两三天。

如果您是从最终用户那里看的，那么如果有人不愿在星期一做某事，而当我尝试使用它时，则我将大为烦恼。

但是，如果您从“过程”的角度来看，则意味着该应用程序需要更多的测试，并且它是软件自然寿命的一部分。

我最好的方法是尝试使事情按应有的方式工作（如果它是主要模块，不要关注细节，登录表单应该登录，但是如果您以后不显示通知，则任何人都会被骗掉）。

这是一个只有您可以回答的问题。这取决于产品的类型，客户是谁，客户要求什么，等等。我们无法给出简单的“ a或b”答案。它完全取决于情况。

但我会提醒您，在发布后修复错误的成本远远高于在发布前修复错误的成本。因此，在决定是否要等到发布后修复错误时，要考虑到这一点，因为您将花费更多的时间/精力/金钱。