1. 找出浪费时间的事情
必须赶在 Deadline 之前完成任务的压力是众所周知的。按时交付成果绝非易事，根据具体情况，这几乎是不可能的。无论你处理的是远程团队管理、裁员、削减财务预算，还是其他各种障碍，压力都是真实存在的。
更进一步，当人们只是简单地专注于维持速度时，谁还会想到提高速度呢？当在 Deadline 前完成任务是你的唯一目标时，想办法做得更好并不是你的首要任务。
那么，解决方案是什么呢？首先，对初学者来说，你要明确团队大部分的时间都浪费在哪些地方。我们建议首先询问你的开发人员他们在哪里浪费了最多时间，然后深入。一旦你深入挖掘并找到痛苦的根源，也就能找到合适的工具来解决它了。
例如，我们的一个客户发现他们在调试时浪费了很多时间。他们的开发人员反复执行整个部署过程，等待设置日志行，然后等待获得所需的信息，并希望这些信息是正确的，以便修复他们正在处理的 bug。一旦他们解决了这种痛苦的重复过程，就能大大加快他们上市的时间了。
2. 找出瓶颈
你有没有做过这样的噩梦：有人在追你，但你只能以慢动作逃跑？有时候开发软件就是这样。是慢动作这部分，而不是疯狂的斧头杀手那一部分。就速度而言，没有什么比感觉自己举步维艰更令人沮丧了。如果是由于公司内部流程缓慢而造成的，情况就更糟了。
软件开发周期可能会很长。无论你是在等待代码审批，还是必须经过另一个 CI/CD 周期（yawn），遇到部署瓶颈或其他各种障碍，它都会非常缓慢。以部署为例，你需要部署的越多，需要等待部署瓶颈释放的时间就越长。因此，你坐下来，喝着咖啡，等待瓶颈释放，并想知道为什么这些循环有时比最初编写实际代码所花的时间还要长。
我们的客户也有同样疑问。他们发现，当他们对代码进行故障排除时，依赖于添加日志行并等待多个周期或重新构建 - 测试 - 重新部署。这是一个极其漫长的过程，每次他们需要排除故障时，都会浪费开发人员的大量时间。
不过，实际上不一定非要这样，我们不是故意的。说真的，通过将需要继续进行的流程与开发周期的其他部分分开，可以使自己和开发人员免于陷入到缓慢的开发周期中。想象一下，在这样一个世界中，你可以直接从设置的断点跳到获取修复正在处理的问题所需的数据上。
3. 想办法做到事半功倍
有时候，你会发现作为一个开发经理，你的工作精力有限。无论在什么情况下，拥有合适的开发人员以及拥有足够的开发人员，这对于团队的成功至关重要。然而，你会发现自己陷入了困境。如果你需要雇佣新员工来完成更多工作，那就意味着需要招募大量员工，而这需要大量的时间和资源，而这些是你本来就没有的。如果你不雇佣新人，那就意味着要用有限的精力来实现你的目标。显然，这两种情况都不理想。
正如我们的一位客户提到的那样，他们意识到他们并没有充分利用自己的资源来最大程度地提高效率，而且他们的开发人员将大量时间花在研究生产环境的问题上。他们找到了一种工具，可以帮助开发人员在生产环境中进行调试，并最终为他们在每个 bug 上节省了大约 1 个小时或更多时间，让他们能专注于创造价值的任务。
像我们的客户那样做，通过事半功倍来避免选择。找到可以让你能充分利用现有资源的工具和方法，特别是开发人员。其中一些工具能帮助你实现代码的自动化或减少代码的复杂性。与其制定一个新员工的入职流程或试图在有限的资源下工作，不如充分利用现有工具，以确保你不必在这两个选项中做出选择。
4. 找出你的修复方法
速度降低的另一个原因是修复 bug 所花费的时间和资源。你会发现开发人员的大部分时间都花在修复 bug 上，而不是花在开发新代码或创建新功能上。调试对于运行良好的机器（即你的软件）来说是必不可少的。然而，它完全耗尽了开发人员的时间（准确地说是60%），从而降低了开发速度。
对那些花了无数时间进行调试的人来说，即使你认为已经结束了，但它并没有。这可以 从“完成”（done）的定义 中看出，“完成”指的是“当软件产品必须满足的所有条件或验收标准都得到满足，并准备被用户、客户、团队或消费团队所接受时”。无论你是如何实现它的，这都意味着每个使用该软件的人（不论他们在软件的哪一端）的所有需求都得到了满足， 它才会被认为是真正完成了。然而，获得这种水平的成品可能需要投入大量时间，这使得开发人员无法专注于产品的其他方面（这些方面同样需要他们关注）。
那该怎么办？你是选择做得好的产品，还是持续优化的半成品？相反，我们建议尽快找到能为你提供所需数据的工具和方法，以解决 bug 并缩短解决 bug 的时间。通过释放开发人员处理 bug 的时间，让他们有更多的时间来处理其他事情，包括确保你的软件达到完美状态。
我们一个客户提到他们缺少合适的 Lambda 调试工具。这大大降低了他们开发新特性的时间，延长了发布新补丁所需的时间。他们了解到，无论如何，他们都需要找到一种方法来帮助他们的开发人员进行调试。
5. 找出你的数据
数据使世界运转。但通常情况下，你的开发人员可能会被大量数据所淹没。实际上，软件开发的每个方面都需要数据。然而，这种对数据的迫切需求导致开发人员积累了大量数据，这些数据大多会在代码中制造噪音并分散开发人员的注意力。
通常，正如我们的一位客户所发现的那样，这种过剩的数据可能是由一种称为 Logging FOMO 的现象造成的。它代表了对丢失日志行及其所包含数据的恐惧。开发人员非常害怕丢失某些内容，以至于他们设置了过多日志行，希望其中的某个能为他们带来所需的数据。然而，这些日志会在系统中产生过多的噪音，并且维护这么多的日志会导致高昂的成本。
另一方面，有时开发人员并没有编写足够的日志，从而阻碍他们获取所需的数据点来继续前进并解决问题。这是一个陷阱，但它有解决办法！有些工具既可以帮你准确地获取所需的日志，也能让你在事后进行日志记录，从而避免数据过多的问题。
