收益：
- 了解范围说明书和工作分解结构 (WBS) 的概念，并使用 AI 生成划分为工作包的 WBS 草案
- 通过人工智能支持澄清超出范围的项目、交付和验收标准，并尽早发现范围蔓延
- 能够理解项目经理有责任通过团队和利益相关者验证来确认人工智能生成的 WBS 与组织环境的完整性、现实性和适用性。
当你开始一个项目时，会问“我们要做什么？”从这开始就像在黑暗中行走。项目常常失败不是因为管理不善，而是因为从一开始就没有正确定义。本单元的主题是两个基本工具，它们概述了项目的边界并将工作划分为可管理的部分：范围说明书和工作分解结构。当这两个文件设置正确时，进度、预测、风险和预算就牢牢地位于它们之上；如果设置不正确，整个项目的一切都会发生晃动。人工智能在这两份文件中都是强大的起草伙伴：它在几分钟内提出范围框架和工作包细分。但请记住：人工智能会产生一般模式；只有您和您的团队知道您组织的实际可交付成果、约束条件和验收标准。
什么是范围说明书？
范围是项目包含的内容和不包含的内容。范围说明书是书面文件，通常包括：项目的目的、关键可交付成果、验收标准、范围外的项目、假设和约束。这里最关键和最容易被忽视的部分是超出范围的列表：“我们不会在这个项目中做 X”阻止了稍后的“但我认为这已包括在内”的争论。
当范围失去控制时，称为范围蔓延：添加到项目中的未经批准的小工作会随着时间的推移而使其膨胀。 “只要再加一点点”，如果重复的话，就会导致预算和时间表都被炸毁。良好的范围声明和明确的验收标准是防止范围蔓延的第一道防线。验收标准是可衡量的条件，交付成果必须满足才能被视为“完整”（例如“在 2 秒内完成加载”）。
提示：在编写范围声明时，在“我们不会做的事情”列表中投入与“我们将做的事情”同样多的精力。排除项目是该项目最便宜的保险。
什么是工作分解结构（WBS）？
工作分解结构（WBS）是一个层次树，它将项目的总工作划分为从上到下逐渐变小的逻辑部分。顶部是项目，下面是主要可交付成果/阶段，下面是工作包。工作包是可以分配给个人/团队的最低级别的工作，并且足够小以估计其持续时间和成本。一个好的WBS遵循两个规则：100%规则（下部部分的总和包括整个上部部分，不多也不少）和相互排他性（没有两个包包含相同的工作，没有重叠）。
为什么 WBS 如此重要？因为预测、进度、预算和风险始终是在工作包级别完成的。 “我们要做一个网站”是不可预测的；但“登录页面设计”、“用户注册表”、“支付集成测试”等包是可以预见的。 WBS 也是分配责任 (RACI)、进度监控和沟通的框架。
一步一步：使用 AI 生成 WBS 草稿
- 明确范围。匿名向人工智能提供项目的目的、关键可交付成果和已知的限制。良好的 WBS 并非来自不明确的目的。
- 要求草稿细目。向 AI 请求一个分为阶段和工作包的层次结构；要求提供一行范围描述以及每个包的建议交付方式。
- 测试 100% 规则。检查生产包总数是否完全符合范围；标记丢失和不必要的物品。
- 添加验收标准。要求为每个关键可交付成果起草可衡量的验收标准，然后根据实际情况对其进行完善。
- 澄清超出范围。向 AI 询问“可能超出该项目范围的项目”列表，并与团队讨论。
- 团队和利益相关者验证。与工作包所有者一起审查草稿。 WBS 绝不是未经团队批准的“计划”。
注意：人工智能生成的 WBS 可能经常会错过看似合乎逻辑但特定于您的组织的关键包（例如“法律批准”、“数据迁移”、“用户培训”）。丢失的数据包会让你的预测从一开始就是错误的。请务必从人的角度应用 100% 规则。
三个迷你箱子
案例 1 — 节省时间的蓝图。 PMO 专家没有为新的内联网项目从头开始构建 WBS，而是向 YZ 提供了匿名范围摘要并要求提供草稿。 YZ提出了6个阶段、34个工作包。在与团队进行的 45 分钟研讨会中，专家删除了 5 个软件包并添加了 3 个缺失的软件包（SSO 集成、可访问性测试、内容迁移）。原本需要一天时间的工作，半天就完成了，变得更加完整。
案例 2 — 捕捉范围蔓延。项目经理向 AI 提出了客户的 12 个小请求，并询问“根据当前范围声明，这些请求是否在范围内或超出范围？”他将其分类为：YZ 7 将该请求标记为“可能超出范围”。 PM 将这些变成正式的变更请求；否则，额外的 3 周工作将悄无声息地渗透到项目中。
情况 3 — 丢失数据包陷阱。一个团队未经验证就批准了 YZ 生产的 28 包 WBS。项目进行到一半的时候，发现没有“数据迁移”和“上线预演”套餐；这两次失误使日程延长了 4 周。教训：人工智能草案不应该在没有经过 100% 规则的人工测试的情况下获得批准。
弱提示/强提示
弱提示：
为移动应用程序项目编写 WBS。
这个提示非常笼统：人工智能通常会生成一个模板，但与项目的实际可交付成果、约束和验收标准几乎没有相关性。
强力提示：
您的角色：高级项目规划专家。背景：零售客户的库存跟踪移动应用程序（姓名被屏蔽）。限制：4 个月，与现有 ERP 强制集成，iOS+Android，可用数据迁移。任务：生成分为阶段和工作包的 WBS 草案。规则：- 遵守 100% 规则；每个阶段下的包应完全覆盖该阶段。- 对于每个工作包：单行范围+主要可交付成果+可衡量的验收标准。- 在末尾给出单独的“可能超出范围”列表。- 用“[与团队确认]”标记您不确定的机构特定包，适合。输出：降价表（阶段|包装|范围|交付|验收标准）。
该请求很强烈，因为上下文、约束、100% 规则、接受标准和超出范围的请求都很明确；还通过“[与团队确认]”来强制不确定性。
附加模板：
# 超出范围查找器阅读下面的范围声明。将常见但此处未明确提及的任务列为“范围外候选”任务（例如培训、文档、支持、迁移、安全测试）。对于每一个，询问为什么应该包含/排除它。
# 验收标准制造商建议以下交货的 3-5 个可衡量的验收标准（以 SMART 格式）：[交货]。不要编写无法衡量的标准（例如“它应该运行良好”）。
# 100% 规则检查器检查下面的 WBS。范围声明中的哪个可交付成果在任何工作包中都没有对应项？哪些包超出了范围声明？列出差距。
常见错误
- 不写超出范围：如果“我们不会做什么”不清楚，范围蔓延是不可避免的。
- 包裹太大或太薄：一个月的巨型包裹难以预测；短短一小时的套餐让管理层不知所措。包裹必须是可预测和可追踪的。
- 批准人工智能蓝图而不验证它：不完整的企业特定包（数据迁移、监管审批、培训）从一开始就伪造了计划。
- 跳过验收标准：如果没有标准，“完成”的讨论就会无休无止。
- 不将 WBS 重点放在产出而不是活动上：好的 WBS 显示可交付成果（名称），而不是“召开会议”之类的活动。
提示：不要写完WBS 就放着不管。当批准的变更到达时，更新 WBS，然后更新进度表和预算。 WBS 是一个动态文件。
综上所述
范围说明书定义了项目的边界，而 WBS 定义了工作的可管理部分。一份好的范围说明书包括明确的验收标准和强有力的“超出范围”清单；良好的 WBS 遵循 100% 规则和相互排斥性。人工智能可以为两者生成快速且完整的蓝图，但可以跳过特定于机构的软件包。项目经理有责任从人的角度应用 100% 规则，澄清超出范围的问题，并获得团队验证。
应用任务
对于您当前的项目，通过 AI 生成工作分解结构草案，分为阶段和工作包（匿名数据）。然后，与您的团队成员一起应用 100% 规则：哪些包裹丢失，哪些包裹是不必要的，哪些交付没有验收标准？纠正至少 3 个缺失/不正确的点并保存纠正后的 WBS。
清单
- [ ] 我的范围说明书有目的、可交付成果、验收标准、超出范围、假设和约束。
- [ ] 我故意填写了“超出范围”的列表。
- [ ] WBS 遵循 100% 规则（无丢失/多余数据包）。
- [ ] 每个工作包都是可预测和可追溯的。
- [ ] 每个重要的交付成果都有可衡量的验收标准。
- [ ]我和团队验证了AI草案；我添加了机构特定的包。