说到管理 瀑布式项目，最重要的第一步是 确定范围这个项目应该做什么，不应该做什么. 这个关键信息通常在 项目范围说明书 列出项目的主要可交付成果和排除事项. 一份精心制作的项目声明似乎足以确定项目的范围——它确实可以. 然而，我可以证明更进一步，创建一个工作分解结构(WBS)的不可思议的价值。. 这是一个经常被跳过的步骤.

WBS是一种可视化的项目管理工具，它所做的正是其名称所暗示的:将产品和相应的项目细分为不同的工作增量. 因为我们的大脑喜欢视觉化的工作, WBS成为团队概念化其工作的有效方式.

一般来说，范围是由从客户或赞助者那里得到的需求驱动的. 担保人可以接近A 项目经理 使用a的初始参数 新产品比如该公司将在北美销售的一系列笔记本电脑. 从那里，项目经理或 业务分析师 衍生出一系列需求，提出诸如“笔记本电脑将是什么颜色”之类的问题?“硬盘的平均故障间隔时间是多少??”“需要多少个USB接口?记住这一点很重要, 在这种情况下, 范围包括任何对项目结果有贡献的东西. 这不仅意味着产品范围(笔记本电脑的特性和功能)，还意味着项目范围(交付这些结果所需的工作)。. 项目范围可能需要诸如为笔记本电脑排列制造或为项目管理分配资源之类的任务.

排除在作用域语句中记录是至关重要的，这样以后就不会有人问类似的问题了, “我们为什么不把货运到英国??“一旦获得批准，这个范围基线有助于预防 范围蠕变, 当某人不考虑对进度的影响而增加了更多的工作时，会发生什么情况, 成本, 风险, 和资源. 任何团队成员都可以检查范围声明，并查看所有决策者都签署了优先考虑哪些市场的协议, 尽管以我的经验, 许多人实际上从来没有读过作用域声明.

这就是WBS的用武之地. 当团队投入时间一起开发WBS时, 它为每个人提供了一个机会来可视化和解释整个范围——什么在里面，什么不在——以及相关的问题，如预算和时间表. 因此，我喜欢将WBS视为项目的罗塞塔石碑.

什么是工作分解结构?

WBS是由美国国防部在20世纪50年代开发的，目前仍被政府团队和承包商普遍使用, 鉴于这些情况下的项目成果往往在一开始就确定了. WBS在其他需要瀑布法的情况下也很有价值, 哪个比许多项目专业人员可能意识到的更常见. 尽管敏捷方法占据优势地位, 哪些不包括WBS作为标准工具包的一部分, 39%的信息技术项目仍然使用瀑布, 根据 项目管理学会 (PMI). 在其他行业，这一比例甚至更高.

WBS将项目范围逐步分解为更小的增量. 这种分层呈现可以出现在 表格或列表格式, 但最常见(也是最有用)的格式类似于家谱, 将相关工作分组到不同的分支.

WBS的第一层确定了项目. 第二层将项目划分为阶段、可交付成果或功能. 选择完全取决于团队的偏好, 但我更喜欢阶段，因为它们更容易与瀑布的顺序方法相一致. 随后的层被细分，直到达到一个称为a的增量 工作包. 在大多数情况下, 完成工作包的时间不超过两周(80小时), 但这并非不可侵犯. 在大型政府或航天项目中, 例如, 一个工作包可能需要几百个小时. 我很少看到一个WBS深入到四五层以上. 到那时，团队应该有足够的信息来知道需要做什么工作.

有时，WBS将包含一个专门的编号方案，以响应分层分解. 最基本的形式是给WBS第二级的每个项目分配一个数字.g., 1, 2, 3). 每列的后续层进一步用小数点(e.g., 1.1, 1.2, 1.3; 1.1.1, 1.1.2, 1.1.3). 根据我的经验, 团队可以在没有编号方案的情况下实现WBS的规划优势, 但在 政府项目，这通常是一项要求.

重要的是要注意，即使团队根据第二层的阶段或功能组织WBS, WBS仍然是一个“什么”文件, 不是"谁"或"什么时候"的文件. 它应该捕获必须发生的全部工作(通常称为 100%原则)，但并非如此 谁 是吗? 当. 尽管如此, 一旦团队创建了WBS来定义必须进行的工作, 每个人都可以更容易地谈论这些相关的问题.

那么罗塞塔石碑是怎么来的呢? WBS是一个可视化的参考，它允许团队成员在对产品和项目范围的共同理解上保持一致. 这也有助于团队开始理解其他问题, 像成本, 风险, 资源, 和时间表. 正如PMI在其报告中雄辩地指出的那样 工作分解结构实施标准 (对于任何想要了解该工具细节的人来说，这是一个极好的资源):“WBS在所有项目干系人之间创建了一种通用语言, 包括项目管理和主题方面.根据我的经验，这是毫无疑问的.

如何创建工作分解结构

理想情况下，WBS计划不应该是项目经理单独承担的单独活动. 最好是让所有团队的代表一起制定WBS. 这种协作的方法就是通用语言产生的方式. 这取决于项目的规模, 一个WBS可能就足够了, 尽管在某些情况下, 每个团队可能都想制作自己的WBS.

作为顾问, 我领导过许多组织的项目启动活动, 包括全球制药公司, 为此，我共同推动了为期两天的广泛工作会议，以规划新药开发项目. 药物开发过程可能需要10到15年，但范围在一开始就确定了. 利益相关者将从全球遥远的角落参加会议，以更好地了解他们最终将生产的产品. 如果做得好，这样的会议也可以作为一个很好的团队建设练习. 我要强调的是，领导这项工作的人应该是 有经验的主持人.

除此之外，我和我的合作协调人会教与会者如何制作和使用WBS. 来自各监管部门的代表, 市场营销, 制造业, 销售, 等等，他们会在大会议室的挂图上粘贴便利贴，制作自己的WBS. (对于远程会议， 米罗 对于类似的活动来说，它是一个优秀的工具吗.)团队可以按照以下步骤开发WBS 自顶向下或自底向上方法:在第一个场景中, 团队安排命名较大工作项的便利贴，然后添加表示子任务的便利贴. 在第二个场景中，首先安排子任务. 团队偏好决定了哪种方法效果最好, 但我总觉得自上而下的方法更容易设想.

每个小组的目标是绘制出整个范围. 如果这个级别的细节是不可能的(因为一个关键的代表不能参加或任何其他原因), 这个团队仍然包括一个 规划方案 查阅WBS上的项目，稍后再详细说明. 小组头脑风暴使团队能够可视化所提议工作的全部轮廓. 你可以想象接下来的激烈辩论. 人们会说:“这真的是我们在做的吗?” or “That doesn’t belong here; it belongs there.在为期两天的会议结束时, 每个团队都制作了自己的WBS, 我们有一个项目的视觉图片. 赞助商可以环顾四周，然后说, “是的, 这就是我的产品,或者“我们讨论过的市场需求在哪里??“通过这些讨论，团队更详细地了解了其工作的性质.

当与会者在规划他们的工作时, 我和我的同事会把任务输入到调度程序中，比如 微软项目 or 内容. 然后我们专注于将这些项目联系起来，以生成整个项目的初始时间表. 该范围可能需要发起人和其他干系人的正式批准和签字, 因此，会议期间制定的时间表只是一个粗略的草案. 仍然, 该进度表说明了WBS几乎具有即时效用, 允许团队开始为下一个项目步骤做准备. 在现实世界中, 团队经常跳过WBS计划，直接跳转到构建时间表, 强迫他们同时思考“做什么”和“什么时候”. 根据我的经验, WBS提供了一个宝贵的机会来详细说明首先进入范围的内容, 在确定工作何时需要进行之前.

需要注意的是，专门的工具可以帮助项目经理开发WBS. 一个叫做 WBS Schedule Pro, 它与微软项目无缝集成. 如果一个项目经理不能把整个团队团结在一起, 无论是面对面还是虚拟的, 我仍然鼓励项目经理自己起草WBS, 也许使用专门的工具. 项目经理可以在会议上向团队展示该草案. 草案可能会有一些错误，但相信我，团队将很乐意纠正这些问题. 这是一件好事.

为了记录，我还要求ChatGPT为我生成一个WBS，并且它以项目符号格式这样做. 总体情况出人意料地好. 仔细提示, 我怀疑项目经理可以求助于生成式人工智能工具，以获得有用的头脑风暴帮助，甚至可以使用dall - e3等图像生成器来渲染图形化的WBS. 当然，结果的准确性需要反复检查.

WBS规划的其他成果

虽然WBS可能看起来“仅仅”是一个范围工具，但它提供的远不止于此. 项目经理不仅要考虑范围，还要考虑成本, 风险, 资源, 利益相关者，以及其他问题. 如果部分作用域丢失，这意味着存在:

• 没有与之相关的资源.
• 没有时间安排.
• 没有发现任何风险.
• 没有指定利益相关者.
• 没有任何假设.

这些问题不会出现在WBS上, 但是，如果团队已经聚集在一个大会议室里进行WBS计划，或者使用像micro这样的工具进行虚拟协作，那么就提供了一个开始解决这些问题的绝佳机会. 事实上, 我认为现在是做这件事的最佳时机, 假设项目经理已经在正确的时间、正确的地点安排了正确的人员. 团队可以看着充实的WBS，然后说:“这个项目需要多少人?或“有哪些风险??赞助商可能会叹口气问:“这一切要花多少钱??”

使用活动挂图或在线白板, 团队可以开始记录风险, 资源, 还有我们称之为停车场的行动项目. (政府使用一份名为《欧博体育app下载》的文件正式定义了这些相关关注点之间的关系 工作分解结构词典. 然而，我从来没有遇到过一个团队在非政府环境中使用这个词典.)

WBS在敏捷中工作吗?

An 专家 读这篇文章的人可能会说:“所有这些听起来都很棒，但我们能利用这些吗??严格来说，答案是肯定的——pmi指数 工作分解结构实施标准 甚至包括了一个关于在敏捷中使用WBS的章节. 但我不会推荐它, 考虑到传统项目管理和敏捷之间的主要区别之一是如何处理范围.

当我们或客户或赞助者非常清楚我们想要的最终结果时，我们通常会使用瀑布法, 结果, 或产品. 改变是允许的，但需要一些费力 变更控制 过程. 在敏捷, 最终的结果不是很明确, 允许发起人或产品所有者随着项目的发展改变他们的想法. 这意味着从一个sprint到另一个sprint的范围可能会变化——通常只有一两个星期的持续时间——因此，花在创建WBS上的时间会分散团队的注意力，使他们无法专注于交付的价值.

更好的计划意味着更好的项目

创建WBS的过程听起来可能很耗时, 它可以是, 特别是如果项目经理在计划会议中没有涉及到所有的涉众，或者需求没有被很好地理解. 然而，如果有足够的前期准备，作为一个团队创造一个WBS可能是一个奇迹. 它将所有人聚集在一起, 执行计划, 火花的谈话, 并引发了关于谁的书面讨论, 什么, 当, 在哪里. 从长远来看，这些结果将节省时间.

我已经参加了十几次我之前描述的为期两天的计划研讨会, 我们从来没有失败过，以一个良好的整体意识项目结束. 如果我在管理一个瀑布式项目, 我将尽可能使用WBS, 即使这两天我都无法让团队团结起来. WBS是计划的基础，简而言之，更好的计划会带来更好的执行.

希望在促进项目会议方面得到深入的指导? 吉姆的书 伟大的会议造就伟大的团队:项目领导者和敏捷者指南 在提高团队凝聚力和充分利用项目管理会议和敏捷活动方面提供了实用的建议.