为什么你的时间估算不起作用以及如何提高估算能力

（本文的完整版本最初发表于hackernoon）

在软件开发过程中，我们必须始终进行时间估算。无论估算是否正确，我们都会依赖它并以此作为决策的依据。然而，在典型情况下，开发人员给出的时间估算往往会不足，变成一种“幻想时间”。在本文中，我将讨论为什么时间估算实际上是一种幻想，以及如何最终更好地估算某件事的实际耗时。

为什么时间估算大多是幻想时间？

在之前的一篇文章中，我描述了一个非常常见的模式：估算开发一个软件所需的时间，以及最终因给出错误估算或未能在规定时间内达到预期结果而导致的混乱和混乱。那么，为什么时间估算类似于幻想时间呢？

软件开发在任何创造性过程中都会遇到许多障碍

编写软件远比表面上看起来更像一个创造性的过程。我们选择的编程语言、框架、库等等都与技术相关，但如何实现、集成或操纵它们来解决问题，本质上是一个创造性的过程，取决于解决问题的人。正因如此，同一个问题才能存在多个解决方案。每个人都可以拥有相同的工具，但每个人创作出的杰作却各不相同，并且取决于他们的创作过程。

我们经历着与任何创造性工作相同的过程。有时计划清晰，有时盯着编辑器不知从何入手，也有时不知该写什么。我们设计所有组件之间的连接方式，并随着需求的变化不断修改这些决策。我们既考虑每个用户的个体需求，同时也考虑全体用户的需求，并思考如何满足他们的需求。我们今天写了一堆代码，明天又会全部删除。有时醒来时，我们对迄今为止所做的一切充满信心，有时又会重新审视迄今为止所做的每一个决定。如此反复，直到最终产品问世。这真是一段跌宕起伏的旅程。

创意过程中的时间估算就像一种幻想时间。我们希望它能花费多少时间，但最终我们也无法确定。

没有真正的万能解决方案

时间估算背后的假设是，看起来相似且复杂度相似的问题，其解决时间也应该相似。仔细想想，如果是同一个问题，只需套用相同的解决方案即可。相似不等于相同。因此，无论“相似”问题如何呈现，它们本质上都是不同的，因此需要进行修改才能使其有效。由于每个问题都是一项新的尝试，因此与这些修改相关的时间并非总是已知的或恒定的。

你可能有很多任务要做

理想情况下，当你最初估算所需时间时，你不会考虑外部环境，例如你正在进行的其他项目是否仍然需要你的关注。当被问及你的时间估算时，你可能已经将该项目与其他所有项目隔离开来。你真正的意思是“在没有其他承诺的情况下，在一个完全隔离的环境中，如果所有其他因素保持不变，我可能需要 X 的时间”。你所说的因素是指，如果程序规范没有变化，如果没有其他请求，并且你不必与其他项目共享时间。

中途更改程序规范不会以任何可预测的方式影响时间

有一种假设认为，直接删除规范意味着软件开发可以在更短的时间内完成。虽然在某些情况下可能确实如此，但我从未亲身经历过。讽刺的是，我的经验是，中途添加或删除规范只会以同样的方式影响时间估算；它们不再适用。这并不意味着你会更快地完成项目。它只是意味着你必须修改你的软件，并考虑这一变化将如何影响你迄今为止已经完成的工作。这也意味着你必须考虑需要添加或删除哪些内容才能满足新的程序要求。

事情会出错，有时修复它们所需的时间是无法量化的

在此过程中，可能会出现一些无法预料的问题，而且完全有可能，可能需要几天甚至几周的时间才能找到解决这些问题的方法。问题可能来自您的计算机、您选择的语言、框架、开发环境、某个依赖项发布的最新更新、无法正确集成第三方工具等等。它甚至可能来自您选择实施的解决方案。结果，测试阶段可能表明它不如最初估计的那么高效，因此并非最佳方案，现在您又回到了绘图板上，此时距离截止日期还有 9 天。考虑潜在的错误非常困难，因为您无法预测可能出现的问题以及解决这些问题需要多长时间。

系统内部存在很多相互依赖

在团队协作编写软件时，通常会将任务分配给团队成员。理想情况下，每个任务都可以独立完成，但在某些情况下，它们可能相互依赖。如果一个部分滞后，它会拖累其依赖的部分。通常，为了避免这种情况，理想的做法是在等待实际输入的同时模拟输入并相应地编写自己的部分。有时这种方法有效，但在某些情况下可能更难做到。例如，在不知道缺陷可能是什么的情况下，很难模拟需要后续图像处理以去除缺陷或不需要的伪影的图像。因此，完成为第二部分提供输入的第一部分的延迟也可能会延迟第二部分。

在团队中，协作是编写大量软件的核心。你可能正在努力修复某些问题，从而影响了队友的工作能力，因为这取决于你完成自己的工作。这样一来，不仅会影响你的日程安排，也会影响他们的日程安排，给你们双方都带来压力。

你不擅长估算

当别人估算你的时间时，你很容易责怪他们，但有时，即使是你自己的时间估算也不够准确。你原以为只需要一个小时，结果却花了两个小时。例如，你原本预计一个程序需要两周时间，但实际只给了一周。当你错过了截止日期时，他们又额外给了你一周时间，然而你仍然错过了截止日期。因此，你最初的估算仍然是错误的。如果没有理想主义的乐观主义，我们又会怎样呢？我们很容易认为自己能够克服编写软件所需的脑力消耗，然而，脑力消耗往往伴随着体力消耗，而脑力消耗和体力消耗之间的休息和恢复精力的时间往往被忽视。小事往往积少成多。花时间休息，偶尔进行头脑风暴，这些任务很难准确量化，但却非常重要，而且会占用相当多的时间。在估算总体时间时，这些任务可能看起来微不足道，但它们会显著影响编写软件所需的时间。

那么为什么我们仍然需要实时估计？

如果时间只是幻想，为什么我们仍然需要并依赖它？

您的用户可以实时使用它

需求与时间因素相关。未来 3 个月需要的功能，如果 6 个月后才出现，就不再适用。因此，你可能需要根据用户需求来规划可行性。如果你正在组织一场马拉松比赛，需要一款应用程序来追踪参赛者的位置、配速、生命体征和速度，并引导他们沿着正确的路线前进，那么在马拉松比赛结束后很久才推出这款应用程序就毫无意义了。这并不能解决问题。估算一下开发这款应用程序所需的时间，可以让利益相关者有充足的时间根据截止日期进行规划，甚至可以提前启动项目以满足用户的需求。

截止日期可以帮助人们保持专注

我有时会拖延，尤其是在处理我的副业项目时，尤其当我的兴趣消退，或者我深深沉迷于另一个项目，而没有固定的截止日期时，拖延会更加严重。时间预估可以帮助我在特定时间内专注于一项特定任务。即使我可能会在设定的时间范围内拖延，但在我的内心深处，我知道有一个项目需要完成，我会抽出时间去完成它。

时间估算确实有助于整体规划

我认为人们询问时间估算并不是因为他们喜欢给别人施加压力。如果他们这样做，你或许应该重新考虑一下你的工作环境。时间估算可以帮助其他人在给定的时间范围内规划他们的项目部分。许多软件是集成的或构建的，可以协同工作。如果产品的一部分缺少关键功能，你就无法发布产品。由于整个系统是其各部分的总和，因此其总时间会受到每个部分时间估算的影响。有了近似的时间估算，项目经理可以决定哪些部分可以并行创建，哪些部分只能在其他部分完成后才能开始，以及总体而言，这将如何影响他们何时完成项目。

我们倾向于理解时间估算的原因，以及为什么我们有时会低于预期的时间。因此，下一步是重新评估我们估算软件设计的方式。

考虑到这一点，我怎样才能更好地进行估算？

每当有人问我“这需要多长时间？”时，我都会屏住呼吸。为什么这个问题会让我如此焦虑？因为在我的内心深处，我知道估算时间的所有细节，以及那些我们通常会忽略的细节。然而，随着时间的推移，我已经想出了一些步骤来分解我认为某项任务需要的时间。我还没有精确到秒，但随着时间的推移，我越来越擅长给出更准确的估算了。

给出一个粗略的估计，并要求时间来分解问题，然后给出更好的估计

如今，我会根据当时的脑力劳动给出一个初步的粗略估算，但也会要求一些时间，以便在会议之外得出更准确的时间估算。这样做通常能让我更好地了解项目范围，将其分解成几个部分，并确定每个部分需要花费的时间。完成后，我会为每个部分添加各种时间估算，我们称之为“探索时间”、“错误修复时间”和“暂停时间”。这些并非行业术语，只是个人用语。

“探索时间”通常是我估计在确定如何实现该特定块时将花费的时间，用于考虑我的选项。编写软件来解决问题的好处在于一个问题可以有多种解决方案。具有讽刺意味的是，这有时也可能是一个问题。在尝试确定应该使用哪种方法解决问题时，太多的选项会导致分析瘫痪。就我个人而言，在选择选项时，我会花时间考虑每个选项如何解决问题、它们的灵活性、优点、缺点、未来的可维护性和一般的相互依赖性。我还会考虑，如果我以后选择改变我的方法，切换到不同解决方案的成本是多少，以及这将有多困难？我发现增加探索时间还可以让我在研究时不会觉得浪费了总时间，因为我已经留出了深入探索我的选项的时间。

“Bug 修复时间”通常是我估计查找和修复特定块中的 bug 所需的时间。当编写与以前实现的软件类似的软件时，这个时间估计可能没有必要。我发现，当我遇到不确定如何解决的 bug 时，这个时间是一个安全网。估计修复 bug 需要多长时间并不容易，但估计根本没有 bug 则更糟糕。当 bug 出现时，紧迫感和随之而来的压力就会出现，因为你没有预留时间来修复 bug。我以前就遇到过这种情况，我不喜欢这样。但是，预料到事情会出错并留出时间来解决它们可以让你感到平静，并且在总体上仍然准时。

“暂停时间”通常是休息时间的委婉说法。这段时间是离开软件，休息一下，刷新一下。每个区块都有自己的暂停时间，因为每个区块的设定不同，因此它们消耗的精力和体力也会有所不同。我在写完 CSS 代码后需要的休息，可能和我在写完测试后需要的休息不一样。

一般来说，想想你写程序的习惯，那些你忽略的小细节花了多长时间？想办法把它们算出来，然后加到你的总体时间估算里。

对你熟悉的部分和不熟悉的部分做出不同的评估

熟悉的事情更容易估算，因为我们已经做过10次、100次甚至1000次了。我们知道大致的流程以及处理这些事情需要多长时间。然而，即使是看似相似的事情，也并非在所有方面都完全相似。尽管如此，微小的变化也很容易处理，因为它们的偏差很小。因此，它们的估算结果可以足够接近我们之前遇到的问题。

我们不熟悉的事情更难估算，因为我们从未做过。也许我们听说过，也知道一般的方法，但从未真正坐下来实践过。那么，我们如何估算从未做过的事情呢？一种方法是根据他人的经验进行估算。当我们不知道某件事需要多长时间时，我们可以进行推测，或者依靠那些有经验的人，并根据他们的经验估算我们的估算。这并非理想状态，但总比凭空捏造一个数字要好。使用他人对一项任务所需时间的估算会带来许多未知因素。首先，对已知事物的时间估算是主观的，会受到经验的影响。一个设计和编写了数百个查询数据库的应用程序代码的人，与从未做过类似事情的人相比，实现类似任务可能只需要X个时间。特定领域的知识也会影响编写该领域代码所需的时间。我们每个人都是不同的。

就我个人而言，在估算完成一件从未做过的事情所需的时间时，我倾向于参考前辈的估算，然后将其翻倍。这样，理论上我就能有时间完成两次。一次完成，然后我会利用额外的时间回顾自己对任务的理解，为下次执行类似任务做好准备。

记住要考虑你的个人习惯

人与人之间存在差异，习惯也各有不同。我们解决问题的方式、集思广益的方式，以及最终评估和处理情况的方式也各不相同。有些人喜欢连续几个小时解决同一个问题，然后休息一下，而另一些人则喜欢集中精力几分钟，中间稍事休息。有些人喜欢在晚上进行脑力劳动，而另一些人则喜欢在早上进行此类工作。有些人不能空腹工作，而有些人不能饱腹工作。尽管如此，无论您的偏好是什么，请考虑您的习惯如何影响您的表现，并在估算时将其考虑在内。您是否需要中间休息更多时间？您是否需要投入充足的时间进行研究？

让你的团队随时了解情况，如果需要修改，请咨询他们

总而言之，无论发生什么，都要让你的团队随时了解情况。我知道这并非提高时间估算能力的直接方法，但持续与团队沟通你的工作成果以及你在时间轴上的进度，可以让你和团队始终保持一致。记住，编写软件和发布产品是一项团队合作，你可能认为他们不会受到你时间轴修改的影响，但实际上他们很可能受到影响。做好合理的估算，考虑到你这边的延误，可以帮助你的队友保持他们的日程安排。这样，当你这边发生任何变化时，他们就不会承受赶上截止日期的压力。

最后，从你自己的估计中学习

每次处理某件事时，都要记录下你预估的时间和实际花费的时间。然后比较一下你的估算值与实际值之间的差异。是否存在外部因素导致这个值出现异常偏差？如果存在，这些因素是什么？
随着时间的推移，不断练习，并从自身经验中学习，你的估算能力应该会越来越强。

希望你喜欢这篇文章！请在评论区留言告诉我。