您不必为了速度而牺牲质量。 实际上，您可以多快地识别并解决用户问题在我们如何考虑质量方面起着重要作用。
如果您订购披萨，则要花五个小时才能送出多好都无所谓。
但是快速行动需要注意使团队减速的确切原因。 也许需要改进某些流程，也许您需要减少会议次数，也许需要更多会议，或者您只需要毫不留情地确定优先顺序。
就像我们尝试产品一样，我们也应该尝试我们的工作方式-始终适应，始终精炼，始终追求更高的效率。
在本文中，我们将深入探讨两种更快地构建更好的事物的重要方法：保持简单和果断。
保持简单
寻找可能可行的最简单方法，然后在此方法上迭代。 每次迭代都将比上一次更加明智，同时提供更多纠正路线的机会。
这是敏捷开发背后的重要思想，并且与“您将不再需要并保持其简单，愚蠢”原则密切相关。
它适用于我们如何缩小范围并将大型功能工作分解为可交付的块。 但这也适用于小事情，例如我们在代码中引入的抽象。
在这两种情况下，不要仅仅因为您知道以后就需要进行工作。 为什么？ 因为我们的代码应具有足够的延展性，以便您可以推迟工作，而以后不必再进行大量工作。 当然，只是在脑子里新鲜时就这样做很方便，但是要克服这种诱惑并客观地问自己：现在真的需要发生吗？ 现在不完成会带来什么后果？
通过等到您真正需要它，您将对需求有更清晰的了解（而不是试图弄清您认为的需求是什么），该系统可以保持更简单的状态，时间更长，只有一半时间可以使用您甚至不需要它！
需要明确的是，这是避免过度设计的一般准则，这不是硬性规定。
如前所述，您的代码应具有延展性，并且需要不断进行重构，管理技术债务，当然还需要有一定的远见。 目的是避免在推定功能的服务中引入复杂性，尤其是在没有令人信服的理由说明为什么以后无法完成时尤其如此。
正如马丁·福勒（Martin Fowler）所说：“这并不意味着放弃所有抽象，但是它的确意味着任何使当前需求的代码难以理解的抽象都是有罪的。”
他接着说：“但是，如果您确实有可扩展的代码库，那么它将增强这种灵活性。 它具有既可以被进化设计又可以实现进化的特性。”
决定性
快速行动的第二部分是制定明智的决策流程。
当然，目标是根据经验研究和数据做出有根据的决策。 如果这是一个艰难的决定，那可能意味着您需要更多时间来收集数据并进行更多讨论。
但是，有时候最好还是从速度的角度出发，去尝试一些事情，尤其是当错误的后果还不是那么糟糕的时候。
这是保持简单和果断的地方。 奥卡姆（Occam）的剃刀告诉我们，最简单的解释通常是正确的解释，在这种情况下，这意味着最简单的选择至少是一个明智的起点。
请记住，只有当您积极寻求可以在转错时通知您的信息时，这种思维方式才有用。 这不关乎正确，而是要做出迅速，周到的调整，直到您到达正确的位置。 这是关于实验胜于猜测，行动胜于无所作为。
金·斯科特（Kim Scott）通过与安迪·格罗夫（Andy Grove，英特尔前首席执行官）就史蒂夫·乔布斯（Steve Jobs）进行对话，在自己的《激进的坦率》一书中解释了正确与正确之间的区别。
格罗夫说：“他妈的史蒂夫总是做对了。”金回答说：“没有人总是对的。”
格罗夫解释说：“我并不是说史蒂夫永远是对的。 我说他总是正确。 像任何人一样，他有时是错的，但他坚持并且并非轻率地坚持，人们会告诉他什么时候他错了，所以最终他总是会正确的。”
一个与此相关的框架是“薄弱的强烈意见”。 这个想法是果断的，并形成强有力的意见，但不要固执己见，以免丢面子或避免浪费工作。
简而言之，正确是关于自我的，正确是重要的。
好吧，那以及您到达那里有多快。
