时机就是一切

引言

当有人走到你面前问你“X工作需要多长时间？”或“这项工作有多少？”时，答案通常是太快说出口，而且最接近于猜测，而不是经过推理的估算。此外，还有一个普遍的抱怨是，开发项目（或IT项目）总是不能按时完成，而且经常总是延期。

面对这种情况，客户、经理和您自己都会感到沮丧，这就是为什么我想写下我在这方面的经验。文章中有“一些”方法论，但我的目的不是讨论任何具体的方法。

背景

我在软件开发的几乎所有方面都待过，作为开发者、分析师、测试人员，也作为项目经理和团队负责人（或资源经理）。在任何这些职能中，你经常会遇到关于某项工作需要多长时间的问题。我将尝试写下我的方法或思考过程，希望您能（部分）从中受益。

关于时间

在项目管理中，时间具有双重含义，您应该清楚您指的是哪种时间。通常，您交谈的人不了解这个问题，这可能导致误解。

1. 运行时间

第一次是运行时间，即从日期A到日期B完成一项任务所需的时间。“这项任务将在1个月内完成”。这意味着从现在起1个月，任务将完成。

2. 工作时间

第二次是工作时间，即完成一项任务所需的工作量。“这项任务需要1个月的开发时间”。但是，这可能意味着如果一个人每周只工作一天，那么完成这项工作大约需要28到31周（运行时间）。

您可以看到，划线陈述几乎相同，但含义完全不同，对吧？

为避免沮丧，请务必弄清楚您指的是哪种时间。

工作时间估算

正如您可能在关于时间段中所看到的，当被要求估算某项工作需要多长时间时，您需要将实际工作量与可用资源结合起来。因此，您的首要任务是确定工作量，通常以人·天（FTE）表示。

FTE：Full Time Equivalent（全职当量），这是1个人一天（或多或少）可以完成的工作量。

更多信息可以在这里找到。

为此，我通常使用FPA类型的方法。

FPA：Function Point Analysis（功能点分析）。您将要执行的任务分解。

更多信息可以在这里找到。

它可以很简单，就像打开Excel并写下任务的估算一样，但是，在这里您可以更深入地研究，并尝试将任务分解为更小的任务。我的经验法则是，子任务应该足够小，以便您（凭您的知识和经验）确信该子任务的工作时间估算正确。（请注意，您可以随时向相关“专家”寻求任何任务的输入）如果您已经知道谁将执行该任务，那么获取他们的意见总是有益的。

WBS：Work Breakdown Structure（工作分解结构）

更多信息可以在这里找到。

例如：任务是“为我们现有的应用程序编写登录系统”，这通常是您唯一能获得的信息，除非您自己开始深入挖掘。您无法仅凭这句话做出准确的估算。您可以更准确地估算的任务是：“编写数据库访问模块”（假设您了解数据库），“创建登录网页”，……但是即使是更小的任务也更好。

通过分解任务，您还可以发现许多问题

• 我们是否已经有数据库访问模块，我可以重复使用它吗？
• 我们需要数据库访问，还是他们想要一个SSO系统（例如OAuth）？
• 登录页面包含什么内容，如果访客再次访问，它是否应该能够识别他们？
• 访客将如何被识别（Cookies、IP等）？
• ...

不难看出，这种分析与良好的功能分析（尽管是高层次的）有些并行。

但是确定任务只是工作的一部分。请记住，估算只是“估算”，“猜测”。我们希望使猜测尽可能准确，尽可能接近实际情况。

为了增加我们猜测正确的几率，您可以为每个任务添加一个复杂性指数。我使用1到5的指数。

1. 尽可能简单。例如，创建一个数据库表，（通常）很容易；写入文件，在表单上创建其他文本框，……（乘数0,5）
2. 比正常情况容易，但涉及的工作量稍多（乘数0,75）
3. 正常复杂性，您有信心可以完成（乘数1）
4. 高于正常复杂性，您对解决方案的查找方向有大致了解，但需要一些研究（乘数1,5）
5. 非常复杂，您几乎不知道如何开始或如何完成，这些任务甚至可能需要被放弃或替换为替代方案，因为它可能不可行（乘数2）

对于每个指数，您将工作估算乘以乘数，以获得新的工作估算，通常更接近现实。（我添加了乘数的示例，但您可以选择自己的。）

在创建FPA（例如在Excel表中）后，您会发现最初的想法有多么错误。在我们的示例中，“创建登录页面”，您可能立即会想到一个数字（假设您对背景有点了解），在为特定任务创建FPA后，您往往会发现自己有低估的倾向。

运行时间估算

尽管大型项目的FPA可能是一项艰巨的任务，但获得运行时间可能更具挑战性，尤其是在一个较大的团队中，人们被分配到多个项目。

在进行此类计算时，请勿犯1 + 1 = 2的错误！

具体来说

• 如果一项任务的工作时间是10人·天，那么1个人全职工作将需要10天的运行时间。
• 如果一项任务的工作时间是10人·天，那么2个人全职工作将需要大约12天的运行时间。

这是一个非常常见的错误，也会导致经理和客户之间产生许多挫败感。之所以不像您最初预期那样计算，是因为2名开发人员需要协同工作，他们需要开会，需要同步他们的工作，需要检查等等。换句话说，越多的人一起工作，产生的开销就越多。对于2名合作的开发人员，我增加了20%的时间（时间的1/5），对于更多的开发人员，您需要增加更多，3个人增加到33%或更多，而4个人将已经有50%到60%的开销。但当您有3到4个人在处理同一项任务时，您可以开始质疑您的FPA，并仔细检查是否无法将任务分解成更好/更多的子任务。

如果可以分解工作，让开发人员不互相干扰，每个人都有自己的范围，那将很有帮助。

一旦确定了谁将处理某项任务，您就需要检查他们愿意为此投入多少时间。他们很可能兼职工作或同时处理其他项目。在这种情况下，您也无法认为50%的分配时间等于50%的运行时间，而不是与工作时间相比。对于10天的工作时间任务，以50%的可用性，运行时间也可能在12天左右。这是因为您需要考虑“进入状态”的时间。想象一下您正在编写一个复杂的算法，突然您的经理走进来问一个基本问题（“嘿，你明天早上来开会吗？”）。发生这种情况时，您需要时间才能重新回到正轨。您被打断的次数越多，“进入状态的时间”就越多。这同样是一种开销。

一旦您确定了正确的人数以及他们在此任务中的可用性，请交叉核对运行时间与计划的假期，并确保将其计入。如果是一个长假期，请至少留出一天的时间来重新进入状态（阅读邮件，了解最新状态……）。作为团队负责人，我要求我的团队成员尽可能提前规划他们的长假期。此外，我认为任何经理最多应管理10名团队成员。超过这个数量将导致失去概览和糟糕的管理。（当然，这取决于经理需要与其团队成员的“亲近程度）

因此，您已经详细进行了FPA，为每项任务分配了资源，并考虑了他们可以投入到项目中的时间以及他们的假期。在我们简单的例子中，您为2个人分配了14天的运行时间来完成10天的工作时间，因为他们都休了1天假。您去见您的经理，向他展示您的详细分析，他很高兴，您也很高兴，大家都很高兴。这项任务的一个子任务是“创建数据库表”，因此一位开发人员编写脚本并将其发送给DBA（数据库管理员），DBA回复说：

“您的请求已获接受，并将在一周到三周内实施，完成后我们将通知您。”

操！（原谅我的脏话，但我相信在这种情况下每个人都会有类似的反应）。

但不幸的是，您确实需要检查每项任务是否有对另一项任务或另一人的依赖关系。您可能需要客户、DBA、另一位开发人员的输入，或者需要先开发某个模块，而您在您的任务中会用到它。换句话说，并非所有任务都可以并行运行。

计算运行时间时需要问的问题

1. 有多少人会参与这项任务？
2. 每个人会花多少时间在这项任务上？
3. 有计划的假期吗？
4. 是否有对其他任务或人员的依赖关系？

不要告诉客户，但

在为计算运行时间分配资源时，很可能这些资源要分配给多个任务，并且分配时间较长。为了更好地估算运行时间，不要将100%可用的资源视为100%，而是视为90%或80%。其他的10%或20%是缓冲，原因有很多：状态不好、因为被视为专家而被过多打扰、午餐时间较长、电话、意外的会议……您仍然按100%计费，但是运行时间会更现实。

开销

我们已经多次提到开销。我认为它是项目延迟的主要因素之一。开销是指非核心项目时间损失的时间。这可能是因为您需要与其他同事同步工作、开会，以及填写时间表、报销单和其他行政事务。

等待输入也是一种开销。当然，您的开发人员可能在其他项目和任务上有足够的工作，但这并不能加快您当前的项目。等待某人（如上面示例中的DBA）或某事（需要先开发的模块）很难计算。最好的方法是了解项目和相关利益相关者。如果您亲自认识这些人和他们的声誉，会很有帮助。

我们还没有讨论过一种开销，那就是文档，或者更确切地说，“项目管理时间”。在大型公司中，这会占据很大比例（有时比实际开发花费的时间还多）。想象一下，客户要求您更改现有应用程序中按钮的标签。假设按钮显示“GO”，他们希望将其改为“calculate”。如果您需要为此设置一个单独的项目，或者您可以将其包含在下一个版本中，并进行一系列其他更改，那么区别就很大了。如果在一个单独的项目中完成，您需要考虑

• 文档（功能和技术），如果您写过文档，您就知道文档中总是有很大一部分是无用的（法律术语、项目范围、链接文档列表、利益相关者……）
• 开发本身
• 测试（含文档）
• 发布（含文档）

计算所有这些，一个简单的标签更改可能需要几天时间。现在，我们将这项任务纳入一个更大范围的项目。您仍然需要完成以上所有工作，但所有文档、测试、发布……的开销现已分摊到整个项目。现在更改按钮标签可能只计算半天，甚至两个小时。

分析、开发、测试

很多时候，我们只为开发创建FPA，但客户只关心何时可以交付系统/项目。最好的做法是扩展您的FPA，将其包括分析（功能和设计）、测试和发布（包括用户文档、安装指南……）。然而，如果您无法做到（出于某种原因），一个好的经验法则是，您需要1/3的时间用于分析，1/3用于开发，1/3用于测试，这意味着将您的估算乘以三。这些数字很有用，因为在大多数情况下，如果您确实进行了完整的估算以包括分析、开发和测试，您可以验证您的估算。它们应该大致占1/3、1/3和1/3。如果不这样，那通常是有一个好理由，或者您犯了错误。所以，这将是一个快速的检查。

通知

• 始终澄清您指的是哪种时间（工作时间还是运行时间）
• 切勿陷入给出强制性答案的陷阱。经理总是试图让事情“紧急”，但很少有真正紧急的。花时间仔细分析。
• 不要让任何人根据他们的“猜测”来改变您的估算。例如，如果您说“这项工作将在六周内完成”，那么其他人就不应该试图推翻您的猜测“你肯定可以在三周内完成吗？”
  此外，如果您说一项工作需要六周，而您在三周内完成，这比反之要好。
• 当您需要就项目做出决策时，例如“是购买现成的产品还是自行开发”，FPA非常有用。为两者都创建一个分析并进行比较。验证您是否具备任一选项的内部知识。
• 在进行运行时间类型的计算时，切勿犯1 + 1 = 2的错误！
  2名开发人员不会使工作速度加倍。
• 不要将100%可用的资源分配满100%，而是考虑90%-80%。
• 确保向所有利益相关者（客户、经理）澄清，估算可能会发生变化。它们是猜测，可能是计算过的猜测，但仍然是猜测。

结论

估算工作和运行时间从来不是一门精确的科学。您依赖各种输入参数，从您自己（或他人）的经验到您可控和不可控的资源可用性。这些参数可能因公司、项目甚至时间而异。当涉及到项目管理和规划时，我认为良好的沟通是关键。拥有一个良好的估算计算工具，有助于进行这种沟通。

所以最终，项目仍然可能延期或不能按时完成，但至少您拥有非常好的信息进行沟通。此外，估算的质量越高，大幅延期的几率就越小。

感谢您的阅读，希望您觉得有所帮助。

历史

• 版本1：文章创建（2018年2月2日）
• 版本2：文章更新（2018年2月5日）