估计是核心能力

估计构建或修复软件将花费多少时间和精力并不容易，而且大多数人对此都很不满意。您在职业发展软件中越高级：

• 随着时间和预算的增加，您将从事的项目更多，而不仅仅是一点点。
• 准时发货给您带来更大的压力。
• 在未按时完成截止日期时，您会感到更加痛苦。
• 您将被要求估算更复杂或模糊的任务。
• 提供估计并表达您对估计的确定程度会越好。

在我的两年中 射灯，我担任过两个角色。作为一名现场工程师，我为客户和内部软件项目编写代码。作为一个 伙伴 在业务中，我与潜在客户进行了交谈，并提出了新项目的建议。

换句话说，我花了很多时间来估算软件任务：得出完成某件事所需的时间和精力。从小型的高分辨率任务，例如“当您单击“确定”按钮，确认表单字段”到大型的低分辨率的工作，例如“我们需要将20年的文章和照片迁移到新的CMS中，编辑喜欢使用它，使他们可以很好地控制网站内容的管理方式，我们还需要重新设计内容，以使访问者获得更好的体验。”

这些是非常不同的软件任务，但是它们需要大致相同的方法来回答问题： 完成这项工作需要多少时间？

时间是一个人造的概念。因此，‘when’无关紧要。只知道它会在昨天或明天发生。

-小野洋子（@yokoono） 2018年2月23日

最终，如果您开发软件，则需要一个计划，这意味着您也需要好的估计。

许多工程师犯的错误

有某种类型的工程师 我一直是这个人！ —技术能力强并且经验丰富的人士，他知道如何完成常见的工程任务，热爱技术和运输软件，并希望取悦老板。但是，这位负责任，富有成效和可爱的工程师也是如此残酷乐观，他们常常犯错误，因为“如果一切顺利，我们可以在本周完成！”我们将这个人称为“这应该很容易”的工程师。

问题是乐观。由于TSBE工程师始终低估了交付关键软件功能所需的时间，因此他们将项目时间表置于风险之中，因为 一切都不会顺利。出于多种原因，与这位工程师一起工作很有趣，而且很愉快，直到您对晚上和周末的工作时间感到苦恼，因为计划的时间表具有破坏性的乐观态度，所以推迟了发布日期才可以发货。

不要成为TSBE工程师。

令人不安的真相

估计为：

• 您的项目经理和业务主管需要的信息，以计划项目并确定功能优先级。
• 知情的猜测。

估算值不是：

• 有机会证明您是10倍的工程师。
• 对完成任务的承诺。

估算值不一定要像需要的那样准确 有用.

良好的估计会在您的PM，业务领导者和合作者之间建立信任。能够及早发现项目中的风险和不确定性，可以为您的项目团队提供所需的信息，以围绕这些风险和不确定性进行计划。

您是否一直在进行途中发生无法预料的工作，或者只是花费更长的时间执行您所知道的工作，而感到困惑？这会在工程师和业务主管之间造成不信任，如果这种情况反复发生，这种不信任会加剧并加剧怨恨，也就是说，如果您还在经营。

是的，估计很麻烦。

如果您给出一个简短的估计，而任务完成的时间和精力超过了整个时间，那么从短期来看，您看起来会很棒，从长期来看，您会感到很糟糕。如果您提供长久的估计，则可能是在告诉项目和业务负责人（以及客户！）他们不想听到的昂贵消息，这在短期内可能很难做到。

我的估计总是过于乐观，这会给您的生活带来很大压力，尤其是当您是一个年轻的程序员时，没有经验和自信来告诉老板不舒服的真相。

— 堆栈溢出用户 RB

所以你会怎么做？有很多公式化的建议可以使您的估算更切合实际，例如：“猜测一下需要多长时间，然后将其增加三倍。”抱歉，这不起作用。当您给出估算时，您必须证明其合理性，并且“我将其增加了三倍”并没有实现。没有技巧或捷径可以更好地进行估算。

xkcd 关于项目估算

您只能采用多种方法来告知您的估计信息。以下是对我们有用的一些方法。

1.做到 Smaller

合理化估算的最有效方法是将其作为各部分之和来计算。首先将手头的任务减少到最小，然后估计每个任务。

在Postlight，我们为客户构建软件，因此在构建过程中，数周之内我们都不会消失。我们的工作的一部分是不断地向我们的客户展示进度，并至少每周进行一次迭代。为了做到这一点，我们必须将任务分解成可以展示和快速运送的小块。为了估算这些任务，我们使用T恤尺码（S，M，L，XL），并且每种尺寸都有非常具体的定义-不是小时或点数，而是以人类友好的时间为单位。

T恤尺码门票，Postlight风格。

旨在将事情减少到日常工作量或更少。如果您认为有一些事情需要一周或更长时间，请进一步分解。这种做法需要更多的前期工作，但也可以通过其他方式为您争取成功：它迫使您更快地消除工作中的未知因素，它使您能够进行小的离散提交（这使代码审查和测试更加容易），而且它使您可以尽早并经常显示和展示正在进行的工作。

2.缩小不确定性的范围

不确定的软件需求越多，构建该软件的时间和成本估算就越不确定。随着软件需求变得清晰，确定性会随着时间的推移而增加。 不确定圆锥 是一个有用的项目管理概念，可用于合理化范围更广，不确定性更高的估算范围。围绕需求在锥体中的位置来确定估计的确定性。做出的决策越多，圆锥越窄，估计值越准确。

“软件组织通常会通过在不确定性锥体中过早做出承诺来破坏自己的项目。如果您在“初始概念”或“产品定义”时做出承诺，则估计误差将是2倍至4倍。

-史蒂夫·麦康奈尔， 软件评估：揭开黑色的神秘面纱 Art

3.高估的错误

许多工程师天生就对快速实现技术抱有乐观的态度。相关：软件行业遭受错过的发货日期和超出预算的项目的影响。您从未听说过提早发布的软件项目。成功状态为准时，失败状态为延迟。

有疑问时， 过度估计。

高估项目的风险小于低估的风险。如果您高估了？最糟糕的情况是，工作会扩展以填补您分配给它的时间，并且无论如何您都要花费计划中的金钱和精力。如果您低估了您的风险，则可能会延迟交付并超出预算，这可能会直接影响业务的健康。

这是两种防止低估的简单方法。

提防 “Just”

曾几何时，我在一个建立了Slack的软件团队中工作，以便每当有人说“仅”一词时，机器人就会做出响应，即“仅”。提醒您： 什么时候 someone says “just,” there’s a chance they are minimizing what something entails. 训练您的保守估计耳朵来听类似以下短语：

• “那只需要几分钟”
• “只写一个脚本”
• “只缓存它”
• “只需创建批处理流程”

那将比你花更长的时间 Think

保留一份工作清单，这些清单执行起来几乎总是比您认为乍一看会花更长的时间。对此有所纪律。每当您想到某项功能或票证提示时，“哇，我认为那不会花那么长时间”，将其添加到您的列表中。

以下是我列表中的一些内容（这些内容严重影响了网络技术）：

• 日期很难： 处理时区，leap年，重复发生的事件（“每月的第三个星期五”，“每月两次，分别在15日和30日”）几乎总是涉及到您直到错过了截止日期的腰部深处才意识到的极端情况。
• 国际化： 具有各种方向性，本地化，字符编码和geo-IP定位的跨字母翻译支持在从服务器体系结构到线框的整个堆栈中引入了复杂性。
• 正在同步： 无论是在客户端上提供脱机支持，还是设置服务器端缓存，都可以使不断变化的数据集保持多个副本，并快速而明智地传播这些更改，从而使任何来源都不会过时。
• 第三方库或API： 第三方服务或工具始终存在意外的陷阱，性能问题或安全漏洞的风险。
• 发送大量电子邮件： 垃圾邮件过滤器是高度发展的，目前基本上是敏感的。这就是为什么存在诸如Mailchimp和Sendgrid之类的企业的原因。
• DevOps： 成熟的云服务和工具使您可以很容易地说出“我们将在AWS上启动它”。 （只是！）尽管有了令人难以置信的工具和服务，但是devop可以轻松地付出比您想象的更多的努力（这就是托管托管服务也是蓬勃发展的业务的原因）。

4.用备份 Research

最后，当有人问您要花多长时间时，请不要立即以您的直觉来回应。无论您有多丰富的经验，每个软件任务都是独一无二的，所以请打个招呼，说：“让我做一点研究，然后告诉您。”当其他所有方法均失败时，请尝试以下方法之一来告知您的猜测：

• 有时间限制的峰值： 如果您不确定某个特定的库或工具或技术实现是否可以正常使用，请将计时器设置为30或60分钟，然后将一个肮脏的原型放在一起。编写最简单和最小的代码，以查看您是否处在正确的轨道上，以及事情是否按照您认为的方式运作。
• 与其他工程师交谈： 如果您的团队或网络中的任何人在您没有的领域中积累了类似的经验或经验，请询问他们的想法或他们在工作中学到了什么。您会惊讶于与另一位工程师进行的快速聊天可以帮助您发现您未曾想到的事情。
• 橡皮鸭： Just as 橡胶诱导可以帮助调试，请尝试向另一位工程师解释您的估算背后的思考过程。 “我认为这将需要3个月的时间。这是我的细分”，可以提高您估算的准确性  和 在团队内部传播建立估算背后的基本原理的良好做法。

估算软件任务很困难！您做得很棒。让我们一起做得更好。

吉娜·特拉帕尼（Gina Trapani） 是Postlight的执行合伙人。如果您需要评估软件工作量的帮助，请联系： [email protected].