5 过程4-创建WBS
5.1 问题
| 4W1H | 过程 |
|---|---|
| 做什么 | 把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程作用：为所要交付的内容提供0架构 |
| 为什么做 | WBS代表着项目范围说明书所规定的工作，可以针对WBS 的工作包安排进度，估算成本和实施监控 |
| 谁来做 | 项目管理团队/项目团队（如果项目规模比较小） |
| 什么时候做 | 制定项目范围说明书后 |
| 如何做 | 分解、专家判断 |
| 主要成果 | 最好是准备一个分解到5层了的WBS，在写作时如果需要写WBS分解到5层的结果，那么直接列表格或画图就可以了。如果没有要求我们写具体的WBS，那么我们可以写一下WBS分解的原则和注意事项，然后将某个系统或模块以文字叙述的方式分解个1-2层即可，不用列表格。 |
5.2 输入输出和工具技术
| 组 | 过程 | 输入 | 工具和技术 | 输出 |
|---|---|---|---|---|
| 计划 | 4.创建WBS | 1.项目管理计划（范围管理计划）2.项目文件（需求文件、项目范围说明书）3.事业环境因素4.组织过程资产 | 1.专家判断2.分解 | 1.范围基准2.项目文件更新（假设日志、需求文件） |
5.3 WBS词典
5.4 WBS范例
5.4.1 范例1
| 工作项 | 工期 | 负责人 |
|---|---|---|
| 1革命文物数字化保护利用项目 | 6月 | 朱工 |
| 2.1可移动革命文物数字化采集 | 1月 | 李工 |
| 2.2可移动革命文物数字化保护利用系统 | 5月 | 王工 |
| 2.2.1文物动态大数据库 | 1月 | 黄工 |
| 2.2.2文物信息资源共享系统 | 1月 | 李工 |
| 2.2.2.1工作门户 | 1月 | 李工 |
| 2.2.2.1.1个人门户 | 0.2月 | 李工 |
| 2.2.2.1.2单位门户 | 0.2月 | 李工 |
| 2.2.2.1.3系统管理 | 0.2月 | 李工 |
| 2.2.2.1.4系统接入等等 | 0.4月 | 李工 |
3.2 范例2
5.5 论文示例
【范例1】
创建WBS是将项目的可交付成果和项目工作分解成较小的易于管理的组件的过程。它对所交付成果提供了一个结构化的视图。基于项目范围说明书和需求文件，我和团队骨干成员、用户代表和主要干系人代表共同进行了WBS的创建。我们将项目的生命周期各阶段作为分解的第二层，产品和可交付物作为第三层。第二层包含需求调研、分析设计、程序设计、软件测试；第三层是第二的进一步细化，如需求调研细化为用户调研、需求分析、用户确认；软件测试细化以单元测试、集成测试、验收测试等。最底层的工作包按照8/80的原则，划分成合理的大小。另外对于项目管理和外包的AP部署，也一并纳入WBS中，逐层分解。在分解的同时制作WBS词典，对工作单元的细节信息进行描述。根据滚动式的规则和自上而下逐层细化分解的办法，我们最终做出了干系人认可并确认的WBS，项目范围基准也随之确定。
【范例2】
创建WBS是将项目可交付成果和项目工作分解成较小的，更易于管理的组件的过程，对所要交付的内容提供一个结构化的视图。本项目中我们依据范围管理计划、项目范围说明书、需求文件的内容，通过专家判断和分解的技术来创建WBS，我们采用的是按照子系统做为第二层的方式来建立WBS，我们严格遵守三个标准来分解WBS：可估算、可分工、可控制。我们把各子系统按照功能模块逐级分解，最终分解的工作包控制在8-80小时，并明确了责任人，对于互联网医院，医院需求不明确，我们先作为规划包，等需求明确后再分解。对WBS进行了编码工作，WBS创建完成后我们组织内部审查，然后交给院方各干系人，通过会议的方式讨论各阶段的工作内容，经过三次的修正，最终完成了确认的WBS，形成了范围基准，为后续的项目管理提供依据。
【范例3】
【范例3】创建WBS是把项目可交付成果和项目工作分解为较小、更易于管理的组件的工作。主要作用为所交付的内容提供框架。在本项目中，基于项目范围说明书和需求文件，我和我的团队开始对本项目的工作进行分解，使得原来非常笼统、模糊的项目目标一下子清晰起来，使得项目管理有依据，项目团队的工作目标变清晰。由于WBS分解涉及到将要开展的具体工作，我组织各组长、骨干成员等召开会议，参与到WBS的分解中。我们使用表格形式的WBS，进行WBS分解时应注意以下几点：1、WBS必须符合项目的范围。我将项目涉及的各模块都一一列出，避免遗漏。2、一个工作单元只从属于某个上层工作单元，避免交叉从属。比如基本界面设计这一工作单元只能从属于它上层工作单元程序设计，不能从属于其他上层工作单元。3、WBS中的元素必须有人负责，而且只能有一个人负责。对于项目的每个工作包，我都指定唯一的负责人负责相关的工作内容。4、WBS的编制需要主要项目干系人的参与。我组织他们进行讨论，以便编制出一份大家都能接收的WBS。同时，我也强调，WBS分解不可能一步到位，根据滚动式规划，逐步达到客户的需求。因此，我们将WBS分为四层，第一层是按照子系统来划分的，包括10个子系统和项目管理；第二层是按照产品需求、设计、编码、测试、验收等项目生命周期来划分的；第三层是对第二层的进一步细化，比如软件测试包含单元测试、集成测试、系统测试等。第四层是对第三层的进一步细化，比如集成测试又分为功能性测试和非功能性测试。在这一过程中，我们发现了范围说明书中存在不明确的地方，通过WBS分解得到明确。WBS分解完成后，项目范围基准。
