从工作包识别活动，关键是先把工作包拆到可交付成果层面，再逐项写出为完成该成果必须执行的动作，最后按依赖关系排出先后顺序。本文按识别、排列、分工、示例和检查五个环节展开，适用于项目计划建立阶段；执行偏差处理和具体日历排期不在本文范围内。
要点总览（TL;DR）
- 先确认工作包边界与完成标准，再围绕每个可交付成果列出必须执行的动作，活动描述统一写成“动词+对象+结果”。
- 排列顺序时先固定强制依赖，把软依赖标注为可调整项，再叠加资源约束，用前置活动字段和初步网络图两种形式表达结果。
- 项目经理统一模板与评审，工作包负责人提供边界说明和初版活动列表，执行成员补充工期与资源条件，接口方确认跨工作包依赖。
- 进入排期前用覆盖度、粒度、命名、依赖无循环、责任人唯一、工期完整六类检查逐项核对，不通过则回到对应环节修正。
- 执行偏差处理归项目进度管理，具体日历排期归任务排期与依赖管理，本文只覆盖计划建立阶段。
从工作包到活动清单：识别活动的四个步骤
工作包是WBS分解到最底层的可管理单元，它描述“要交付什么”，活动描述“用什么动作交付”。识别活动的任务，就是把工作包的交付责任翻译成一组可执行、可估算、可分配的动作。整个过程可以拆成四个步骤，每一步都有明确的输入和输出。
第一步：确认工作包边界与完成标准
输入是WBS中的工作包说明。动作是逐条确认三件事：该工作包覆盖哪些可交付成果、成果的验收条件是什么、哪些内容明确不属于该工作包。输出是一份边界清晰的说明，包含完成标准和排除项。完成标志是：工作包负责人能够用一两句话说明“做到什么程度算完成”，且不存在与其他工作包重叠的交付内容。边界不清的工作包先退回分解环节，不进入活动识别。
第二步：逐项识别活动并统一命名规则
输入是确认过边界的工作包说明。动作是围绕每个可交付成果，列出为产出它必须执行的动作，包括准备、执行、检查、交接等环节。活动描述建议统一采用“动词+对象+结果”的结构，例如“编制接口测试用例并通过评审”“完成设备到货验收并签署记录”。这种写法把动作和产出绑在一起，便于后续判断粒度和分配责任人。输出是工作包下的初版活动列表。
第三步：剔除重复与不可交付的活动
初版列表常见两类问题：同一动作在多个工作包下重复出现，以及某些条目只是状态描述而非可执行动作。动作是逐条核对：该活动是否只归属一个工作包；执行后是否产生可检查的产出；是否可以在一个合理的汇报周期内完成。输出是去重、清理后的活动列表。完成标志是每条活动都能回答“谁做、做什么、交出什么”。
第四步：形成活动清单字段
活动清单需要固定字段，才能支撑后续排列和排期。建议至少包含下表所列内容，字段可按项目复杂度增减。
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 活动编号 | 唯一编号，与所属工作包关联 | 后续引用依赖关系 |
| 活动名称 | 动词+对象+结果 | 统一粒度与检查口径 |
| 所属工作包 | 对应WBS节点 | 保持分解结构可追溯 |
| 完成标准 | 可验证的产出或验收条件 | 判断活动是否结束 |
| 责任人 | 唯一负责人 | 分配与跟进 |
| 工期估算 | 带单位的时间估计 | 支撑排列与排期 |
| 前置活动 | 必须先完成的活动编号 | 表达依赖关系 |
| 备注/假设 | 资源、外部条件等约束 | 记录排列依据 |
字段填齐后，活动清单即成为排列顺序的工作底稿。在ONES中，工作分解结构可通过「项目计划」按目标、交付物或项目阶段等维度建立，活动可承载为项目任务，责任人、工期和前后置依赖可以在任务上设置，使活动清单与依赖关系在同一处维护。
活动排列：依赖关系与顺序的确定方法
活动清单解决“有哪些活动”，排列解决“先做哪个、后做哪个”。排列的依据是活动之间的依赖关系，而不是凭经验把列表从头排到尾。判断顺序时，先识别依赖类型，再标注前置与后续关系，最后把资源约束叠加进去。
区分强制依赖与软依赖
强制依赖来自工作本身的物理或逻辑要求，例如“基础验收合格”必须先于“设备安装”，这类顺序通常不可调整。软依赖来自管理选择、习惯做法或最佳实践，例如先做模块A再做模块B，调整顺序不会破坏交付逻辑，但可能影响资源利用或风险暴露。排列时应把强制依赖固定下来，把软依赖标注为可调整项，避免把管理偏好误当成硬约束，压缩后续排期的腾挪空间。
标注前置活动与后续活动
每条依赖至少记录两个方向的信息：某活动的前置活动是谁，某活动的后续活动是谁。标注时使用活动编号而非名称，避免重名混淆。对于跨工作包的依赖，额外注明涉及的工作包和接口责任人，便于交接时核对。完成标志是：任取一条活动，都能沿前置关系追溯到起点，沿后续关系找到受其影响的活动。
把资源约束叠加到顺序上
逻辑顺序确定后，还要检查资源条件。同一责任人被安排同时执行两项无依赖关系的活动时，需要明确串行处理还是调整分配；关键设备、测试环境、外部审批等稀缺资源也会改变实际先后。资源约束不改变强制依赖，但会在软依赖区域形成新的排序理由。处理方式是在活动清单的备注中记录约束来源，并在排列结果中体现调整后的顺序。
排列结果的表达形式
排列结果建议用两种形式同时表达：一是活动清单中的前置活动字段，逐条记录直接依赖；二是初步网络图，用节点表示活动、用箭头表示先后关系，直观暴露并行分支和汇聚点。网络图不要求精确到日历日期，它的作用是让依赖结构可检查。ONES支持为项目任务设置前后置依赖，使任务关联清晰可见，也可用里程碑标记重要时间点、事件或决策点，作为排列结果中的检查节点。
角色分工与各环节交付物
活动识别与排列涉及三类角色，分工不清时最容易出现两种结果：工作包负责人只交成果不交活动，项目经理凭印象补全清单。明确每个角色在什么环节交付什么，可以让清单的来源和确认过程都可追溯。
| 角色 | 主要职责 | 交付物 | 参与节点 |
|---|---|---|---|
| 项目经理 | 组织识别与排列，统一命名规则和字段口径，主持评审 | 活动清单模板、排列规则说明、评审结论 | 启动、评审、定稿 |
| 工作包负责人 | 确认工作包边界与完成标准，提出本工作包的活动及依赖 | 工作包边界说明、初版活动列表、依赖说明 | 识别、排列 |
| 执行成员 | 核对活动可执行性，补充工期估算和资源条件 | 活动工期估算、资源约束说明 | 识别复核、排列复核 |
| 相关接口方 | 确认跨工作包或跨团队的依赖 | 接口依赖确认意见 | 排列确认 |
评审与确认设置两个节点即可。第一个节点在活动清单初稿完成后，由项目经理组织工作包负责人核对覆盖范围和粒度，确认每条活动都有责任人和完成标准。第二个节点在排列结果形成后，重点确认强制依赖是否完整、跨工作包依赖是否双方认可、资源冲突是否有处理结论。两个节点都通过后，活动清单和排列结果进入排期环节。在ONES中，项目计划可关联迭代和研发任务，项目下可管理需求范围与研发任务，评审结论和活动清单可以作为项目文档与任务记录同步维护，减少清单版本分散。
示例：一个工作包如何拆成活动并排序
以下示例为演示情景，用于说明识别与排列的判断过程，不代表特定行业的实际项目。
示例工作包及其完成标准
工作包名称：用户登录模块开发。完成标准：登录、登出、密码重置三项功能通过测试环境验证，接口文档更新完毕，代码合并至主干并通过代码评审。排除项：不包含第三方短信服务采购。
识别出的活动列表
- A1 编写登录模块接口设计说明并通过评审
- A2 完成登录与登出功能编码
- A3 完成密码重置功能编码
- A4 编写登录模块单元测试并执行通过
- A5 更新接口文档并提交评审
- A6 完成代码合并并组织代码评审
- A7 在测试环境完成三项功能验证并记录结果
依赖关系与排列结果
A1是设计与编码的共同前置；A2、A3可并行，均以A1为前置；A4依赖A2和A3完成；A5依赖A1，可与A2、A3并行推进；A6依赖A4和A5；A7依赖A6。按此排列，关键路径为A1→A2/A3→A4→A6→A7，A5处于并行分支，若文档评审延迟会直接影响A6。
示例中体现的常见判断
第一，A2与A3之间没有强制依赖，拆成两条活动是为了并行分配和独立跟踪，属于软依赖层面的管理选择。第二，A5放在A1之后而非A6之前，是因为文档更新只需要设计输入，提前完成可以缩短整体周期。第三，A7作为验证活动单独列出，而不是并入编码，是为了让完成标准有独立的检查动作。这些判断都记录在活动清单的备注中，便于评审时复核。
完成检查：活动清单与排列结果是否可用
进入排期前，用以下清单逐项核对。任何一项不通过，回到对应环节修正，不带问题进入排期。
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 活动覆盖完成标准 | 逐条对照工作包完成标准，确认每项验收条件都有对应活动 | 无验收条件落空 |
| 活动粒度一致 | 抽查活动工期估算，比较同一层级活动的规模差异 | 粒度差异在可接受范围内，无过粗或过细条目 |
| 命名规则统一 | 检查活动名称是否均为“动词+对象+结果”结构 | 名称可直接判断产出 |
| 依赖无循环 | 沿前置关系逐条追溯，检查是否回到起点 | 不存在闭环依赖 |
| 依赖无遗漏 | 核对跨工作包接口和外部输入是否都有前置记录 | 每条外部输入都有对应前置活动或假设说明 |
| 责任人完整 | 检查每条活动是否只有一个明确责任人 | 无空白、无多人共同负责 |
| 工期字段完整 | 检查工期估算是否带单位、是否有依据说明 | 全部活动可估算，异常值有备注 |
检查通过后，活动清单和初步网络图即可作为排期输入。ONES提供从项目到任务的多层级管理能力，活动清单、依赖关系和责任人字段可以在项目计划中统一维护，检查结论也可随项目文档留存，便于后续排期和执行阶段回溯识别依据。
常见问题
工作包边界一直谈不拢，活动识别要不要先停下来？
建议先停下来，把边界问题退回WBS分解环节处理。边界不清时识别出的活动往往与其他工作包重叠，后续排列会出现重复依赖和责任人争议。可以先用一句话写出该工作包的完成标准和明确排除项，由工作包负责人确认后再继续。若确实存在跨工作包共享的交付内容，把它单独列为接口事项，注明双方接口责任人，不必强行塞进某一个工作包。
活动拆到多细才算合适？
判断粒度是否合适，可以看三个条件：活动执行后能产生可检查的产出；能在一个合理的汇报周期内完成；能分配给唯一责任人。粒度太粗时，工期估算跨度大、进度难以判断；粒度太细时，清单条目膨胀、管理成本上升。同一层级活动的规模应大致可比，抽查工期估算差异明显偏大的条目，通常就是需要再拆或合并的对象。
软依赖和强制依赖判断错了会有什么影响？
把软依赖当成强制依赖，会压缩排期的调整空间，资源冲突时缺少腾挪余地；把强制依赖当成软依赖，则可能在排期中被随意调换顺序，造成返工。判断时问一句：调换顺序是否会破坏交付逻辑或验收条件。会破坏的按强制依赖固定，不会破坏但出于管理习惯选择的，标注为软依赖并写明调整条件，评审时由工作包负责人和执行成员共同确认。
活动清单和排列结果评审通过后，还需要维护吗？
需要。活动清单是排期的输入，范围变更、设计调整或外部条件变化都可能带来新增活动或依赖变化。建议把变更记录在活动清单的备注或假设字段中，注明变更原因和影响的活动编号，并在下一次评审节点统一确认。这样执行阶段回溯时，能看清当前顺序是怎么形成的，而不是只看到一份与最初版本脱节的清单。
跨团队的活动依赖由谁确认？
由涉及的两个工作包负责人共同确认，项目经理主持。确认内容包括：依赖的方向、需要对方交付的具体产出、交付时间要求和验收方式。确认结论写入活动清单的前置活动字段和备注，双方各留一份记录。只由一方单方面登记依赖，容易出现对方并不知情、排期时无法兑现的情况。
