项目规划 II： 工作量

项目规划 I： 工作分解结构

引言

所有的计划都是错误的。尽管如此，人们在开始旅程时还是会带水。那么问题是：多少才够，多少太多？

任何项目都会消耗工作量，例如以工作小时或工作日衡量。但至少组织（由项目发起人代表）为了获得项目的好处并为此付费，必须提前知道工作量。首先，因为必须提供执行工作所需的资源；其次，因为一个普通的项目只有在回报大于工作量/成本时才有意义（例如，利润、节省）。

因此，我们需要提前了解项目的工时，尽管我们知道我们的计划只能或多或少地反映现实。

背景

我们在 第一部分 中讨论了规划的基础知识，我们的基本项目组织结构如下：

我们有一个核心团队，包含一些核心团队成员（TM）和一名项目经理（PL），向项目发起人（SP）汇报。此外，我们还有一个由该核心团队产生的基本工作分解结构。

现在，我们来分配核心团队成员的责任。

分配责任

我们的核心团队由 John、Susan、Lydia 和 Mike 组成。每个工作包指定一名负责人来管理它——不管有多少人将参与这项工作。

现在，让我们开始进行关键的工作量规划部分。这取决于根据每项工作包的类型选择最有效的估算方法。

以下考虑由负责各自工作包的责任人进行。

显而易见的工作量

让我们以我们项目在我们的工作环境为例：

• Lydia 认为，“4.3 安装 IDE”这项工作包显然需要一个人 4 个净工作小时才能完成（达到足够质量）。
• John 认为，“8.1 开启新系统”显然需要 1 个小时。
• John 认为，“8.2 关闭旧系统”显然需要 4 个小时。
• John 认为，“1.1 项目规划”显然需要核心团队 4 个人各 4 小时（= 16 小时）。
• John 认为，“1.3 项目收尾”显然需要核心团队 4 个人各 2 小时（= 8 小时）。
• Susan 认为，“4.2 购买 IDE”显然需要 2 个小时。

公式

让我们假设，在我们的项目工作环境中，对于某些工作包，我们可以根据每项工作包的负责核心团队成员找到一个公式：

• “6.3 执行培训”需要为每 10 个用户群体培训 4 小时，加上 1 名培训师，我们有 40 个用户需要培训。所以总共是 10 * 4 * 4 + 1 * 4 * 4 = 176 小时。
• “7.1 定义测试用例”每个测试用例需要 0.5 小时，我们估计会有大约 300 个测试用例。所以是 150 小时。
• “7.3 执行测试”每个测试用例需要 1 小时，其中 10% 需要重新测试。所以我们有 300 小时加上 30 小时加上 3 小时 = 333 小时。
• “1.2 项目控制”在 7 次项目控制会议中需要核心团队 4 个人各 2 小时，以及每个控制周期项目经理 8 小时。总计是 112 小时。

经验

让我们假设，在我们的项目工作环境中，经验能帮助我们完成一些额外的工作包：

• Mike 认为，“2.1 分析流程”需要为 20 个流程（或用例）进行分析，每个流程 4 小时。所以这项工作需要 80 小时。
• “3.1 定义类”将需要 20 个类，每个类 2 小时：40 小时。
• “3.3 定义用户界面”将需要 10 个屏幕，每个屏幕 6 小时：60 小时。
• “6.2 制作培训材料”将需要每 1 个课堂培训小时制作 5 小时的材料。每个用户群体重复的培训将持续 4 小时，所以这项工作包将需要 20 小时。
• 这样一个规模的系统在第一个月会产生 100 个请求，平均每个请求需要 2 小时来处理。所以“8.3 处理问题”将需要 200 小时。

可接受度

在某些情况下，我们可以简单地询问执行工作的人员，他们可以接受的最高工作量。

• 对于“3.2 设计数据库”，Lydia 表示，对于一个拥有 20 个类的系统，她可以接受 40 小时。
• 对于“5.2 制作 UI”，Lydia 表示，对于一个拥有 10 个屏幕的系统，她可以接受 80 小时。
• 对于“7.2 自动化测试”，Susan 表示，对于这个规模的系统，她可以接受 100 小时。

工作包含工作

对于“5.1 编码类和方法”，我们到目前为止的所有方法都可能失效。所以我们记住“工作包含工作”。因此，我们可以将这个工作包分解为更小的工作包。

现在，我们不应忘记将核心团队中的负责人分配给新的子工作包，而不是分配给它们的父工作包 5.1。之后，我们可以应用上述任何一种方法，包括当前这种方法（再次将其分解为更小的工作包）。

假设我们最终得到 5 * 16 小时、5 * 40 小时和 10 * 80 小时（分别为工作包 5.1.1、5.1.2 和 5.1.3 节省 80 小时、200 小时和 800 小时）。

自上而下

现在我们来看看迄今为止的结果。

现在很清楚，我们项目到目前为止的工作量至少是 2,500 小时。

如果迄今为止的总工作量比所有人预期的都要高，我们就必须从项目规划转向项目管理，即谈判和解决冲突。当然，我们到目前为止的工作量计算应该为项目经理和项目发起人之间的任何谈判提供一个非常好的基础。但这已经是另一篇文章了。

如果迄今为止的总工作量低于预期，比如说预算是 3,000 小时，我们可以将剩余的约 500 小时分配给剩余的工作包。也许这会奏效并带来一个好结果。如果我们发现某些工作包无法在它们的预算内完成（小时），在这种情况下我们也必须开始谈判。

这是结果。

关注点

当我们记录所有假设时，我们就能够应对项目中的任何新发展。例如，“3.1 定义类”的结果可能是需要 30 个类而不是 20 个。那么我们就可以轻松地调整计划并进行适当的项目控制，以做出有效的项目决策（这再次是另一篇文章）。

我们也不应该忘记，工作量和质量是相关的，但仅限于一个有限的范围。增加工作量会提高质量，但工作量大大增加可能不再提高质量。另一方面，减少工作量会降低质量，但工作量太少最终将一事无成。

除此之外，这里所有的计算仅包括“内部工时”，即项目执行组织员工所做的工作。分包商或自由职业者的工作是所有“外部成本”的一部分（再次在单独的文章中讨论）。

历史

2015年11月26日 - 发布