Project management 什么是WBS以及如何进行WBS？

我想知道你们中有多少人（项目经理和技术负责人）使用WBS（工作分解结构）进行项目规划？我听说这是一件好事，但也有很多“好事”要做，但最终都不会成功

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

---

请记住，我不是项目经理，但有时我必须完成他的任务。

在传统的项目管理中，WBS是一个非常宝贵的工具，如果使用正确的话

我一直采用自上而下的方法，从主要工作块开始：

• 用户界面
• 后端
• 数据转换

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

• 取款交易的数据输入屏幕
• 查询以获取用户历史记录
• 将STATS12表从版本1.1转换为版本1.2

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

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

这具有以下主要有益效果：

• 如果大多数估计是正确的，我可以在每次会议上报告进展情况-这对PM总是很好：-）
• 较小的工作总是比较大的工作更容易准确估计
• 落后于计划的现象很快就会显现出来
• 保存有关估算的历史数据及其与实际情况的最终准确性，可以为下一个周期提供更详细的信息，以便您能够智能地调整估算

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

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

---

我真的不能为你提供任何链接，抱歉，因为这主要是多年来做这个角色的痛苦经历。我确实可以访问许多链接以简化操作，但它们是公司内部的（我们的规模足够大，可以有自己的方法）。

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

WBS肯定会帮助你规划项目。它们对于确保您的赞助者和团队成员关注同一个项目尤其有用，尽管可能只是在不同的层面上

向下工作结构是您将在项目中进行的工作的映射。WBS 应该用来始终如一地解释你将要实现什么，你将如何实现它，需要多长时间，需要多少成本

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

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

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

上述可交付成果将构成您工作分解结构的顶部

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