什么是WBS，怎么做？

Question

我想知道你们中有多少人(项目经理和技术主管)使用WBS (工作分解结构)进行项目计划？我听说这是一件很好的事情，但是还有很多“好事情”要做，这些事情最终都不会成功。

这真的对项目规划有帮助吗？如果是这样的话，正确的方法是什么？也许一些链接/文章可能会有所帮助。

请记住，我不是一个项目经理，但有时我必须做他的工作。

Answer 1

在传统的项目管理中，如果使用得当，WBS是一个无价的工具。

我总是采用自上而下的方法，从主要工作开始：

• user interface
• back-end
• data conversions

并简单地深入到更具体的层次

用于提取transaction

• query的
• 数据输入屏幕，用于获取STATS12表的用户history
• conversion，从版本1.1升级到版本1.2

直到工作分解结构中的每个元素都小于报告期。

我的意思是，如果我必须每两周报告一次进度，那么任何单个元素都不允许超过估计的8天。如果是，则需要进一步细分。

这主要有以下有益的影响：

• 如果大多数预估都是正确的，我可以在每次会议上报告进度-这对于PM来说总是很好用的：-)。
• 较小的作业总是比较大的jobs.
• Falling更容易准确地进行预估，进度落后的情况很快就会变得明显。
• 根据实际情况保存有关预估的历史数据及其最终准确性，从而为下一个周期提供更详细的信息，以便您可以调整预估intelligently.

最后一点在未来的评估中很重要。例如，如果Sam持续低估了10%的用户界面作业，那么您知道将来应该提高这些估计值。

这应该会发生，否则你的PM工作更多的是猜测/黑魔法而不是工程。

我真的不能为你提供任何链接，对不起，因为这主要是多年从事该角色的痛苦获得的经验。我确实有很多链接可以让它变得更容易，但它们是公司内部的(我们足够大，可以有自己的方法)。

Answer 2

WBS当然可以帮助你规划你的项目。它们对于确保您的发起人和团队成员关注同一项目特别有用，尽管可能只是在不同的级别。

Work Down Structure是您将在项目中承担的工作的地图。WBS应该用来始终如一地解释你要实现什么，你将如何实现它，它将花费多长时间，以及它将花费多少。

WBS本身并不能完成所有这些事情，但它是计划项目的早期构建块之一。您通常会在定义/验证项目范围后创建您的WBS。你将需要详细的作用域，因为你的WBS将从你的可交付成果中分离出来。

创建WBS是一个自上而下的过程，在这个过程中，您可以获取可交付件列表，然后将它们分解为工作包。如果你正在创建一个新的金融系统，你可能会有几个可交付的项目；

1. General Ledger
2. Journal Interface
3. Account Payable module
4. Accounts Recievable module
5. Bank Interface
6. Reporting

上述可交付成果将构成您的WBS的顶部。

1.0.0 General Ledger
  1.0 Transaction Ledger
  2.0 Accounts Maintenance
2.0.0 Journal Interface
  1.0 Journal creation
  2.0 Journal review
  3.0 Journal update
  4.0 Journal deletion
3.0.0 Account Payable module
  1.0 AP Invoice creation
  2.0 AP Invoice review
  3.0 AP Invoice update
  4.0 AP Invoice deletion
4.0.0 Accounts Recievable module
  1.0 AR Invoice creation
  2.0 AR Invoice review
  3.0 AR Invoice update
  4.0 AR Invoice deletion
5.0.0 Bank Interface
  1.0 Generic Payment interface
  2.0 ANZ Bank interface
  3.0 Westpac Bank Interface
  4.0 Commonwealth Bank interface
6.0.0 Reporting
  1.0 Trial Balance
  2.0 Balance Sheet
  3.0 Operating Statement
  4.0 Invoices Pending

(注:编号系统很方便。例如:您将知道6.3.2是创建运营报表报告的第二个任务。)

然后，你会不断地将它们分解成工作包，每个工作包需要4小时到5天的时间才能完成。一旦您完成了WBS，您就可以让您的团队成员或专家从下到上估计每个工作包(任务)需要多长时间。然后，这些评估将帮助您计划与您的WBS和最初商定的范围一致的初始计划和预算。

为什么要这样做呢？有几个原因，第一个原因是沟通容易。您的评估员需要低级别的工作包(即:4小时到5天)才能准确地进行评估。但你的赞助商需要高水平的具体交付成果来评估你的日程安排和预算。通过尽早决定WBS，您可以同时实现这两个目标。

通过使用一致的WBS，赞助商可以查看您的日程安排和预算，并将其与您的原始计划联系起来。他们可能会认为4.0.0不值得为此付出努力。这是从你的可交付成果中转移出来的WBS，你的发起人只需要看一看第一层就能了解正在发生的事情。

如果你在早期定义了你的WBS，你的发起人，你的早期团队成员和其他利益相关者可以看到他们参与了什么，还可能发现你的项目中缺少什么。上面的老生常谈的例子中有很多遗漏，专家很容易在你开始之前发现和修补漏洞。

这里的关键点是；

1. Create your WBS from your deliverables
2. Break the WBS down into work packages between 4 hours to 5 days long
3. Estimate on the work packages
4. Report your schedule against the top level(s) of your WBS
5. Report your budget against the top level(s) of your WBS

复杂的(例如:昂贵的或有风险的)项目通常需要另一个步骤。大型项目或具有高风险概率的项目通常是分阶段的。这仅仅意味着将你的交付成果分成几个阶段作为顶层。每个阶段都应该产生一些可衡量的东西，并允许你的发起人决定是否继续。这样就避免了一种大爆炸式的方法。在进入下一阶段之前，每个阶段都应该被判断为完成，吸取的经验教训等。大型软件开发、构建和构建都是以这种方式完成的，实验项目也是如此，因为可能无法确保成功，因此需要仔细监控结果。

上面的同一项目被分成了几个阶段；

1.0.0.0 Phase 1
  1.0.0 General Ledger
    1.0 Transaction Ledger
    2.0 Accounts Maintenance
  2.0.0 Journal Interface
    1.0 Journal creation
    2.0 Journal review
  3.0.0 Reporting
    1.0 Trial Balance    

2.0.0.0 Phase 2
  1.0.0 Journal Interface
    1.0 Journal update
    2.0 Journal deletion
  2.0.0 Account Payable module
    1.0 AP Invoice creation
    2.0 AP Invoice review
    3.0 AP Invoice update
    4.0 AP Invoice deletion
  3.0.0 Reporting
    1.0 Balance Sheet
    2.0 Operating Statement

2.0.0.0 Phase 3
  etc etc etc

你的WBS应该有一个明确的链接到你的可交付成果，并且你可以对复杂的项目使用阶段化。无论哪种方式，逻辑都是一样的，继续分解你的WBS，直到你有了最低级别的工作包，这些工作包是可以在4小时到5天内完成的具体任务。你和你的团队成员需要专注于完成工作包，然而你和你的发起人将专注于监控和控制WBS的顶级一两层。

编辑： WBS不应该一直到任务..我在tasks and WBS上发布了一个更清晰的例子。

Answer 3

根据Capers Jones的说法，WBS是必不可少的:缺少/未知/不完整的需求、设计和计划是项目失败的主要原因，WBS有助于发现和明确定义项目范围。我用过各种工具，从白板到思维导图工具。不要让这个工具束缚你的手脚，找一个可以工作的或者只是用纸。