在最后期限之前还是更少的错误？

Question

在一个理想的世界里，最好是以较少的错误在最后期限之前完成。但从你的经验来看，哪一种更可取/更可接受：

1. 在最后期限之前，但是有一些but，因为开发人员急于处理问题。
2. but较少，但没有完全达到最后期限，因为开发人员编写代码非常严格。

Answer 1

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

企业

如果您与一个在市场上有良好地位的企业级客户进行业务往来，那么他们的灵活性就会降低，并且无法快速适应变化。因此，在大多数情况下，稳定性是一个绝对的要求。研究和开发以及进入新的垂直领域也有例外。在某些情况下，完成速度更快。

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

Startups

对于一个新的创业公司来说，规则是完全不同的。作为一家初创公司，你需要马上知道你正在开发的产品是否真的能如你的市场调研所预测的那样满足需求。对于一家初创企业来说，尽可能快地在市场上推出一个原型，就能得到很多关于产品发展方向的宝贵反馈。

它还可以使你成为市场领先者，帮助你在新的垂直市场中获得有价值的市场份额，以免它充斥着竞争。

由于初创企业规模小、灵活，而且能够迅速适应变化，因此这种模式对它们来说效果最好。

这取决于执行领导决定一个有效的商业战略，包括彻底分析选择一种方法而不是另一种方法的机会成本。

Answer 2

或者..。3.削减非必需功能

有时，由于技术上的糖果或客户要求的糖果功能，最后期限很难完成，并且天生就会产生更多的漏洞。这是应用的接吻和雅格尼原则。

引用这本书的话，“返工”，你的软件的核心/中心是业务运作所需要的，就像热狗站可以是一个没有任何配料的热狗站一样，你不能切断的是热狗。

重新谈判

最难学到的事情之一是如何让客户满意，在我的经验中，这可以更容易地通过更小的产品迭代来完成。

有时候，截止日期要求软件从第一天起就在生产级别上工作。经理/客户并不总是知道(这是大多数情况下)他们实际需要的软件。所以尽量减少不必要的功能，并保持质量。最后，这取决于生产环境的关键程度，但要尽量减少额外的特性并提供质量。再次引用“返工”：

以后做也意味着做得更好

...and还以较少的bug满足了最后期限

Answer 3

那么，你可以用这样的方式来描述:你想现在还是以后为质量付费？要么花点时间把它做好，要么花些时间解决所有的问题。我认为，这个后特性开发bug修复阶段可能更昂贵，因为它也可能风险更大，更容易出现黑客解决方案，因为现有的代码已经到位，而且质量可能还不够高。