六．创建工作分解结构（WBS）

6.1什么是工作分解结构

工作分解结构：work breakdown structure，简称WBS。是对项目所涉及工作面向交付成果的分组，它定义了项目的全部范围。（用来把一个复杂的项目分解成更小、更容易管理的部分。）

简单来说，WBS的作用就是把一个“大项目”拆分成多个“小任务”，并明确每个任务的具体内容和目标。这样，项目团队就能清楚地知道要完成整个项目需要做哪些具体工作。

6.2WBS的两种类型图示

1.1产品范围

1.2项目范围

6.3WBS的特点

充分必要性交付物独立性

6.4主要的工具

主要的工具是：分解（decomposition）,也就是说，把项目可交付结果划分为更小的部分。

6.5什么是基线范围(scope baseline)

基线范围（scope baseline）包括批准的项目范围说明书和与之相关的WBS以及WBS字典。

时间基线

时间基线（Time Baseline）

时间基线 是项目管理计划中的一个重要组成部分，它记录了项目在各个阶段的计划开始时间和计划结束时间。时间基线通常以甘特图或项目网络图的形式呈现，展示了项目的整体时间安排

6.6WBS的痛点

管理层对关键节点把握不准，所以项目经理应该在充分沟通下去建立了WBS并及时调整。

6.7WBS的表达形式

1）使用指南法（Usage guide method）

举个例子：

指南法的特点：

层级分明：通过缩进和编号，清晰地展示任务的层级关系。易于理解：类似于大纲的形式，易于阅读和理解。灵活性高：可以根据需要添加或删除任务，调整层级结构。

例子

假设我们正在为一个“产品发布会”项目创建WBS，使用指南法可以这样表达：

取消自动换行

复制

解释

1. 产品发布会项目

1.1 项目管理

1.1.1 项目计划制定

1.1.2 项目进度跟踪

1.1.3 项目风险管理

1.2 活动策划

1.2.1 活动主题确定

1.2.2 活动流程设计

1.2.3 活动场地选择

1.3 宣传推广

1.3.1 宣传材料设计

1.3.1.1 海报设计

1.3.1.2 宣传视频制作

1.3.2 媒体合作

1.3.2.1 媒体邀请

1.3.2.2 新闻稿发布

1.3.3 社交媒体推广

1.3.3.1 微信公众号推广

1.3.3.2 微博推广

1.4 现场执行

1.4.1 场地布置

1.4.2 设备调试

1.4.3 人员安排

1.5 后期评估

1.5.1 活动效果评估

总结报告撰写

2）类比法（analogy approach）

采用一个相识项目的WBS作为出发点

3）思维导图法（Mind mapping method）

一些项目经理喜欢使用思维导图法来帮助开发WBS。

4）自上而下法（top-down approach）

1>定义

自上而下法是从项目最大的条目开始，将它们分解为次一级的条目。这个过程实际上就是对于工作的进一步划分。 自上而下法是从项目的整体目标或最大的任务开始，逐步将其分解为更小的、更具体的子任务。这个过程就像是从一个大蛋糕开始，先切成几块，然后再把每块切成更小的部分，直到你得到可以一口吃掉的小块。

2>步骤

1.确定项目的总体目标或最大的任务。例如，假设你正在管理一个“产品发布会”项目，项目的总体目标是“成功举办产品发布会”。

2.将总体目标分解为几个主要组成部分。例如：

项目管理活动策划宣传推广现场执行后期评估

3.将每个主要组成部分进一步分解为更具体的子任务。例如：

活动策划可以分解为：

确定活动主题设计活动流程选择活动场地宣传推广可以分解为：

设计宣传材料媒体合作社交媒体推广

4.继续分解，直到每个任务都是具体的、可执行的。例如：

设计宣传材料可以分解为：

海报设计宣传视频制作

优点：

结构清晰：自上而下法从整体到细节，结构非常清晰，容易理解。全局观强：这种方法从项目的整体目标出发，确保每个子任务都服务于项目的总体目标。易于管理：分解后的任务更具体，便于分配和管理。

缺点：

可能忽略细节：如果分解不够细致，可能会忽略一些重要的细节任务。需要经验：需要项目负责人对项目有全面的了解和丰富的经验。

5）自下而上法(down-top approach)

1>定义

项目团队成员首先识别尽可能多的与项目有关的具体任务。随后，将这些具体的子任务集中并组织成概要任务或WBS中的较高层次。

自下而上法是从识别具体的、可执行的任务开始，然后将它们组织成更高级别的任务或WBS中的较高层次。这种方法就像是从一堆小积木开始，先把小积木堆成大积木，直到你得到整个项目的结构。

2>步骤

1.项目团队成员首先识别尽可能多的与项目有关的具体任务。例如，团队成员可以列出所有需要完成的具体工作，如“设计海报”、“制作宣传视频”、“邀请媒体”等。

2.将具体的子任务分组。例如，将所有与宣传相关的任务分组在一起：

海报设计宣传视频制作媒体邀请新闻稿发布

3.将分组后的任务组织成更高级别的任务。例如，将上述宣传相关的任务组织成“宣传推广”任务。

4.继续组织，直到形成完整的WBS。例如：

宣传推广

设计宣传材料

海报设计宣传视频制作媒体合作

媒体邀请新闻稿发布社交媒体推广

微信公众号推广微博推广

优点：

细节导向：这种方法从具体的任务开始，确保所有细节任务都被考虑到。团队参与：团队成员可以积极参与，贡献自己的想法和经验。灵活性高：可以根据实际情况灵活调整任务和组织结构。

缺点：

缺乏全局观：如果团队成员只关注具体的任务，可能会忽略项目的整体目标和方向。需要协调：需要有人负责将具体的任务组织成更高级别的任务，并确保任务之间的协调和一致性。

6）图表法

6.8 WBS字典

什么是WBS字典？

WBS字典（Work Breakdown Structure Dictionary）是与工作分解结构（WBS）配套使用的详细说明文档。它为WBS中的每个工作包或任务提供更详细的描述和解释，帮助项目团队成员和相关方更好地理解每个任务的细节和要求。

简单来说，WBS字典就像是一个“任务说明书”，它详细说明了WBS中每个任务的具体内容、目标、负责人、时间要求、资源需求等。通过WBS字典，项目团队可以更清晰地了解每个任务的细节，避免误解和遗漏。

2）WBS字典的主要内容包括

1. 任务编号和名称：

- 每个任务在WBS中的唯一编号和名称。例如，1.2.3 设计活动流程。

2. 任务描述：

- 对任务的详细描述，说明任务的具体工作内容和目标。例如，“设计活动流程：确定活动的时间安排、环节顺序和人员分工。”

3. 负责人：

- 负责完成该任务的个人或团队。例如，“张伟，项目经理”。

4. 时间要求：

- 任务的开始日期、结束日期或持续时间。例如，“开始日期：2023年5月1日，结束日期：2023年5月10日”。

5. 资源需求：

- 完成该任务所需的资源，包括人力、物力、财力等。例如，“需要1名设计师，2名活动策划人员，以及活动场地租赁费用”。

6. 验收标准：

- 任务完成的验收标准，说明如何判断任务是否完成。例如，“完成活动流程设计文档，并通过项目团队审核”。

7. 依赖关系：

- 该任务与其他任务的依赖关系，说明任务的先后顺序和依赖条件。例如，“该任务依赖于1.2.1 确定活动主题的完成”。

8. 备注：

- 其他需要说明的事项，例如特殊要求、注意事项等。

例子：

假设我们有一个“产品发布会”项目，以下是WBS字典中的一个例子：

例子：

假设我们有一个“产品发布会”项目，以下是WBS字典中的一个例子：

任务编号

任务名称

任务描述

负责人

时间要求

资源需求

验收标准

依赖关系

1.2.1

确定活动主题

确定产品发布会的主题和方向

李华

2023年5月1日-5月5日

1名市场分析师，1名品牌经理

完成活动主题确定报告，并通过项目团队审核

无

1.2.2

设计活动流程

确定活动的时间安排、环节顺序和人员分工

张伟

2023年5月6日-5月10日

1名活动策划人员，1名项目经理

完成活动流程设计文档，并通过项目团队审核

1.2.1

1.2.3

选择活动场地

选择合适的活动场地，并签订租赁合同

王强

2023年5月11日-5月15日

1名场地协调员，场地租赁预算

完成场地租赁合同签订，并确认场地可用

1.2.2

1.3.1

设计宣传材料

设计活动宣传海报和宣传视频

李娜

2023年5月16日-5月25日

1名设计师，1名视频制作人员

完成宣传材料设计，并通过市场部审核

1.2.3

1.3.2

媒体合作

邀请媒体记者，并发布新闻稿

王芳

2023年5月26日-5月30日

1名媒体协调员，媒体邀请预算

完成媒体邀请，并发布新闻稿

1.3.1

1.3.3

社交媒体推广

在微信公众号和微博上推广活动

张强

2023年5月16日-5月30日

1名社交媒体运营人员

完成微信公众号和微博的推广活动，并达到预期曝光量

1.3.1

总结

WBS字典是WBS的补充说明文档，它为每个任务提供了详细的描述和解释，帮助项目团队成员和相关方更好地理解任务的细节和要求。通过WBS字典，项目团队可以更清晰地了解每个任务的**具体内容**、**负责人**、**时间要求**、**资源需求**等，从而更有效地管理和执行项目。

6.9 确认范围

导致范围蔓延（scope creep）的原因

1>不清楚的需求定义

例子：

假设一家软件开发公司接到一个项目，客户要求开发一个“客户关系管理（CRM）系统”。在项目初期，客户只是简单地说：“我们需要一个CRM系统，能管理客户信息和销售数据。” 项目团队没有深入挖掘具体需求，也没有与客户确认详细的功能列表。

结果：

在项目进行到一半时，客户突然提出需要增加“数据分析报表”、“客户跟进提醒”和“社交媒体集成”等功能。由于最初的需求定义不清晰，项目团队没有预料到这些额外的工作，导致项目范围扩大，开发时间延长，成本增加。

总结:

如果项目团队没有在项目初期明确和详细地定义需求，客户可能会在项目进行过程中不断提出新的要求，导致范围蔓延。

2>没有正式的变更评议

例子：

在一个建筑项目中，项目团队正在按照最初的计划建设一栋办公楼。施工过程中，客户提出希望增加一个“屋顶花园”。项目团队在没有进行正式的变更评议的情况下，同意了客户的要求，并开始施工。

结果：

增加屋顶花园不仅需要额外的设计和施工工作，还需要重新评估建筑的承重能力和防水设计。由于没有进行正式的变更评议，项目团队没有考虑到这些额外的工作量和成本，导致项目延期和预算超支。

总结：

如果没有正式的变更评议流程，任何需求的变更都可能不经评估就纳入项目，导致范围蔓延。

3>开发和需求的不一致

例子:

在一个电商平台开发项目中，项目团队根据最初的需求文档开发了一个“购物车”功能。然而，在用户验收测试阶段，客户发现“购物车”功能与他们的实际需求不符。例如，客户希望购物车能够支持“批量编辑”，但项目团队开发的版本只支持“单个编辑”。

结果：

由于开发和需求不一致，项目团队需要重新开发“购物车”功能。这不仅导致项目延期，还增加了开发成本。

总结：

如果开发和需求不一致，项目团队可能会在项目后期发现需要返工或修改，导致范围蔓延。

4>缺乏用户的配合

例子：

在一个企业内部管理系统开发项目中，项目团队需要与多个部门合作，收集需求和进行用户验收测试。然而，由于各部门工作繁忙，用户代表经常缺席会议，或者没有及时反馈项目团队的询问。

结果：

由于缺乏用户的配合，项目团队无法及时获得准确的需求和反馈，导致开发的功能不符合用户的实际需求。在项目后期，用户提出大量修改意见，导致项目范围扩大，开发时间延长。

5>项目运行时间过长（市场环境的风云突变）

例子： 一家公司计划开发一款移动应用程序，最初的需求是开发一个简单的电商平台，支持基本的商品浏览和购买功能。项目预计在6个月内完成。然而，由于项目团队的技术选择和开发进度问题，项目运行时间延长到了12个月。

结果： 在项目进行到第9个月时，市场上出现了新的竞争对手，他们推出了具有更多功能的电商应用，如“个性化推荐”、“社交分享”和“实时聊天客服”。客户看到竞争对手的功能后，要求项目团队在他们的应用中增加这些新功能。

总结： 项目运行时间过长，市场环境可能会发生变化，客户会看到竞争对手的新功能或新技术，从而提出新的需求，导致项目范围扩大。

需求变更需要评审

需求变更更需要评审，不可以说用户想让程序员增加什么就增加什么，这样往往会出问题，需求的变更必须经过CCB（变更控制委员会）评审。

6.10范围确认（scope validation）

范围确认是指整个项目可交付成果的正式验收

6.11对于改善用户输入的一些建议

为IT项目开发一个良好的项目选择过程

用户输入（User Input）是指在项目开发、系统设计、产品开发或任何与用户交互相关的过程中，来自最终用户、客户或利益相关者的反馈、需求、建议或意见。这些输入可以涵盖多个方面，包括功能需求、使用体验、问题报告、改进建议等。用户输入是项目成功的关键因素，因为它直接影响到项目的方向、功能设计和最终交付成果。

1>明确项目目标和战略方向

建议：

在项目启动之前，确保项目目标和战略方向已经明确，并与组织的整体战略保持一致。项目选择过程应首先评估项目是否符合组织的长期目标和优先事项。

实施步骤：

高层参与：邀请高层管理人员参与项目选择过程，确保项目目标与组织战略一致。战略评估：使用SWOT分析（优势、劣势、机会、威胁）等工具评估项目对组织的战略影响。

例子： 一家零售公司计划开发一个新的电子商务平台。项目选择过程中，高层管理人员参与评估该项目是否符合公司的数字化转型战略，并确定该项目是公司未来三年的重点战略项目。

2> 建立多层次的用户参与机制

建议：

建立一个多层次的用户参与机制，确保不同层级的用户和利益相关者都能参与到项目选择和需求收集过程中。

实施步骤：

用户访谈和调研：定期进行用户访谈和问卷调查，收集不同用户群体的需求和建议。

用户代表小组：成立用户代表小组，成员包括来自不同部门的用户代表，定期召开会议讨论项目进展和需求变更。

焦点小组讨论：组织焦点小组讨论，邀请关键用户参与，深入探讨项目需求和功能设计。

例子： 在开发一个新的客户关系管理（CRM）系统时，项目团队定期与销售、市场和客户服务部门的用户代表召开会议，收集他们的需求和建议，并邀请他们参与系统测试和反馈。

使用结构化的需求收集工具和方法

建议：

使用结构化的需求收集工具和方法，确保用户输入的完整性和一致性。

实施步骤：

需求规格说明书：编写详细的需求规格说明书，明确项目的功能需求、非功能需求和用户期望。用户故事：使用用户故事（User Stories）方法，将用户需求转化为具体的、可执行的任务。用例图：使用用例图（Use Case Diagram）描述用户与系统之间的交互，帮助项目团队更好地理解用户需求。

例子： 在开发一个新的移动应用程序时，项目团队使用用户故事方法，将用户需求转化为具体的任务，如“作为用户，我希望能够通过社交媒体登录，以便快速注册和登录”。

4>建立有效的变更管理流程

建议：

建立一个有效的变更管理流程，确保用户输入的变更能够被及时评估和处理。

实施步骤：

变更请求表单：使用变更请求表单（Change Request Form），记录用户提出的变更请求，包括变更内容、理由和影响。变更评估委员会：成立变更评估委员会，定期召开会议，评估变更请求的可行性和影响。变更跟踪系统：使用变更跟踪系统（Change Tracking System），记录和跟踪所有变更请求的状态和进展。

例子： 在项目进行过程中，用户提出增加一个新的功能模块。项目团队使用变更请求表单记录该请求，并提交给变更评估委员会进行评估。评估通过后，项目团队更新项目计划和需求规格说明书，并跟踪变更的实施情况。

5>定期反馈和沟通

建议：

建立定期的用户反馈和沟通机制，确保用户输入能够及时反馈给项目团队，并得到有效处理。

实施步骤：

定期会议：定期召开项目会议，邀请用户代表参加，汇报项目进展和用户输入的处理情况。用户满意度调查：定期进行用户满意度调查，收集用户对项目进展和交付成果的反馈。反馈循环：建立反馈循环机制，将用户反馈及时传递给项目团队，并跟踪反馈的处理结果。

例子： 项目团队每月召开一次用户代表会议，汇报项目进展，收集用户反馈，并讨论用户提出的需求变更。在每次会议后，项目团队更新项目计划和需求规格说明书，并跟踪用户反馈的处理情况。

6>使用原型设计和迭代开发

建议：

使用原型设计和迭代开发方法，及时验证用户输入，并进行快速调整。

实施步骤：

原型设计：使用原型设计工具，快速构建系统原型，验证用户需求和功能设计。迭代开发：采用迭代开发方法，将项目分为多个迭代周期，每个周期结束时进行用户验收测试和反馈收集。

例子： 在开发一个新的移动应用程序时，项目团队使用原型设计工具(原型设计工具（Prototyping Tools）是一种用于创建产品、服务或系统原型的软件应用程序。这些工具帮助设计师、开发人员和项目团队快速构建产品的初步模型，以便在实际开发之前进行测试、验证和迭代。原型设计工具可以用于各种类型的项目，包括软件应用、网站、移动应用、硬件产品等。)，快速构建系统原型，邀请用户进行测试和反馈。根据用户反馈，项目团队及时调整设计和功能，并在下一个迭代周期中实现。

对于减少不完善和不断变化的需求的建议

1>制定并遵循需求管理过程，这个过程包括了初始的需求确定程序

建议：

制定一个明确的需求管理过程，并在整个项目生命周期中严格遵循。这个过程应包括初始需求的确定程序。

例子： 一家软件开发公司计划开发一个新的客户关系管理（CRM）系统。为了有效管理需求，项目团队制定了一个需求管理过程：

需求收集：通过用户访谈、问卷调查和焦点小组讨论收集用户需求。需求分析：对收集到的需求进行分析，识别优先级和依赖关系。需求确认：与用户确认最终需求，并签署需求规格说明书。需求变更管理：建立变更管理流程，任何需求变更都需要经过评估和批准。

通过遵循这个过程，项目团队确保所有需求都经过严格的审查和确认，减少了需求不完善和变更的可能性

2>使用诸如原型开发，用例建模和联合应用设计等技术来彻底理解用户需求。

建议：

使用诸如原型开发（Prototyping）、用例建模（Use Case Modeling）和联合应用设计（Joint Application Design, JAD）等技术来彻底理解用户需求。

例子： 在开发一个电子商务网站时，项目团队使用以下技术：

原型开发：使用Figma创建一个高保真度的网站原型，邀请用户进行测试和反馈。通过原型，用户可以直观地看到网站的界面和交互，从而提供更准确的反馈。用例建模：项目团队与用户一起编写用例（Use Cases），描述用户与系统之间的交互。例如，“用户登录”、“添加商品到购物车”、“结算”等。联合应用设计：组织JAD会议，邀请用户代表、开发人员和设计人员共同参与，讨论和确定系统需求。

通过这些技术，项目团队能够更深入地理解用户需求，减少需求误解和不完善。

3>让所有的需求用书面文件体现出来，并保持它们实时更新并一直有效：

建议：

将所有需求用书面文件记录下来，并保持这些文件实时更新和有效。

例子： 项目团队在项目初期编写了一份详细的需求规格说明书（Requirements Specification Document），并将其作为项目的基础文档。在项目进行过程中，任何需求变更都需要更新这份文档。例如：

需求变更：用户提出增加一个新的功能模块，项目团队在需求规格说明书中添加该功能，并更新相关文档。版本控制：使用版本控制工具（如Git）管理需求文档的不同版本，确保所有团队成员都能访问到最新的需求信息。

通过书面记录和实时更新，项目团队确保所有需求都被准确记录和跟踪，减少了需求遗漏和变更混乱。

4>创建一个需求管理数据库用以管理文档和控制需求。

建议：

创建一个需求管理数据库，用以管理文档和控制需求。

例子： 项目团队使用一个需求管理工具（如JIRA或Trello）创建一个需求管理数据库：

需求条目：将每个需求作为一个条目录入数据库，标明需求的描述、优先级、负责人和状态。跟踪和监控：通过数据库跟踪每个需求的进展和状态，例如“待确认”、“进行中”、“已完成”。变更记录：记录每个需求的变更历史，包括变更内容、变更原因和变更批准人。

通过需求管理数据库，项目团队能够更好地管理和控制需求，确保所有需求都被有效跟踪和执行。

5>提供足够的测试来说明项目的产品都可以像预期的那样。在项目周期内一直坚持进行测试

建议：

提供足够的测试，说明项目的产品都可以像预期的那样。在项目周期内一直坚持进行测试。

例子： 项目团队在项目开发过程中坚持进行持续的测试：

单元测试：开发人员编写单元测试，确保每个功能模块都能正常工作。集成测试：测试人员进行集成测试，确保不同模块之间的接口和交互正常。用户验收测试：邀请用户进行验收测试，验证系统是否符合用户需求和期望。回归测试：在每次需求变更后，进行回归测试，确保新的变更没有引入新的问题。

通过持续的测试，项目团队能够及时发现和解决潜在的问题，确保最终产品符合用户需求和预期。

6>以系统化的视角采用一种流程来评审提交的变更请求

建议：

以系统化的视角，采用一种流程来评审提交的变更请求。

例子： 项目团队建立了一个变更管理流程，用于评审和处理所有变更请求：

变更请求提交：用户或项目团队成员提交变更请求，填写变更请求表（Change Request Form），包括变更内容、理由和影响。变更评估：变更管理委员会（Change Control Board, CCB）定期召开会议，评估每个变更请求的可行性和影响。变更批准：变更请求经过评估后，由CCB批准或拒绝。批准的变更请求会被分配给相应的团队成员进行实施。变更实施和验证：实施变更后，进行相应的测试和验证，确保变更不会引入新的问题。变更记录：所有变更请求的评估结果、实施情况和验证结果都会被记录在变更管理数据库中。

通过系统化的变更管理流程，项目团队能够有效地控制需求变更，确保所有变更都经过评估和批准，减少了需求不完善和变更混乱。