项目活动清单要回答三个问题：做什么、做多久、在谁之后。本文用一个“会员中心改版”的演示项目，给出一份填好的活动清单表格，并逐字段说明活动名称、工期和依赖的写法。示例情景为演示设定，不对应真实客户或实测效果；方法聚焦计划建立阶段，不展开执行偏差分析与排期算法。
要点总览（TL;DR）
- 活动名称用“动词+对象”写到可交付，例如“编写接口文档”“完成视觉稿设计”，避免“负责XX”式笼统表述。
- 完成标准与名称一一对应，写成可核验的产出物或状态，如“评审通过”“回执收到”。
- 工期以工作日计并写明估算依据，区分工期与持续时间，外部等待单独说明。
- 依赖写清前置活动编号和依赖类型，先内部后外部、先硬依赖后软依赖，外部依赖标注来源方。
- 换项目时从WBS末级节点出发，按名称、完成标准、工期、依赖四步填写，再用自检清单核对。
示例目标：这份活动清单要解决什么问题
本文的示例情景设定为：某团队计划在两个月内完成一次“会员中心改版”，范围包括登录注册流程优化、会员等级展示和个人资料页重构。团队已经用工作分解结构（WBS）把项目拆到末级节点，现在需要把这些节点转成可排期的活动清单。这个背景是演示设定，用于说明填写方法。
一份可排期的活动清单，需要让每个执行者看懂三件事：这项活动要产出什么、预计占用多少工作日、必须等哪些活动完成后才能开始。三个问题对应活动名称与完成标准、工期、前置依赖三类信息。缺少任何一类，清单就只能算任务备忘，无法直接进入排期。
活动清单与WBS、里程碑的关系是：WBS回答“项目由哪些可交付成果组成”，活动清单回答“为交付这些成果要做哪些动作、按什么顺序做”，里程碑则标记关键时间点或决策点。示例中把“需求评审通过”设为里程碑，它本身不消耗工期，但作为后续活动的依赖起点。本文只讲计划建立阶段的填写，执行中的进度跟踪、偏差纠正和具体排期算法不在范围内。
完整示例：一份填好的项目活动清单
下表是“会员中心改版”示例项目的活动清单。编号A开头为活动行，M开头为里程碑行。表中包含串行（A02依赖A01）、并行（A03与A04同时依赖A02、彼此无依赖）、汇合（A05同时依赖A03和A04）三类依赖关系。
| 编号 | 活动名称 | 完成标准 | 工期（工作日） | 前置依赖 | 依赖类型 | 责任人角色 |
|---|---|---|---|---|---|---|
| M01 | 需求评审通过（里程碑） | 评审纪要归档，关键需求无未决项 | — | — | — | 产品负责人 |
| A01 | 编写会员中心需求说明书 | 说明书通过评审并归档 | 3 | — | — | 产品经理 |
| A02 | 完成交互原型设计 | 原型覆盖全部页面，评审通过 | 4 | A01 | 完成—开始 | 交互设计师 |
| A03 | 编写接口文档 | 接口文档评审通过，字段与原型一致 | 3 | A02 | 完成—开始 | 后端开发 |
| A04 | 完成视觉稿设计 | 视觉稿交付并确认，标注齐全 | 5 | A02 | 完成—开始 | 视觉设计师 |
| A05 | 开发会员中心前端页面 | 页面联调通过，覆盖视觉稿全部页面 | 8 | A03、A04 | 完成—开始 | 前端开发 |
| A06 | 开发会员中心后端接口 | 接口按文档实现并通过自测 | 8 | A03 | 完成—开始 | 后端开发 |
| A07 | 执行会员中心集成测试 | 测试报告出具，遗留缺陷已分级 | 4 | A05、A06 | 完成—开始 | 测试工程师 |
| A08 | 完成上线前安全评审 | 评审结论为通过，问题清单闭环 | 2 | A07 | 完成—开始 | 安全工程师 |
| A09 | 提交第三方短信服务开通申请 | 服务开通回执收到 | 5 | — | 外部依赖 | 运维工程师 |
里程碑行M01与活动行的区别在于：里程碑不填工期，只标记时间点或决策点，示例中它作为A01之后评审通过的标志；活动行则必须有工期和可核验的完成标准。A09是外部依赖，由第三方服务商响应，团队只能提交申请并等待回执，因此单独标注依赖来源，不与其他内部活动混排在同一依赖链上。
逐项解释：活动名称、工期、依赖分别怎么填
活动名称：用动宾结构写到可交付
活动名称建议采用“动词+对象”的结构，例如“编写接口文档”“完成视觉稿设计”，读者一眼能看出动作和产出物。示例中A01到A09都遵循这一写法。需要避免的是“负责会员中心”“跟进需求”这类笼统表述，它们没有说明具体产出，无法判断何时算完成，也无法估算工期。粒度标准是：一项活动对应一个可交付成果，能分配给一个角色，能独立验收。
完成标准：与名称一一对应的验收条件
完成标准是活动名称的验收注脚。A03“编写接口文档”的完成标准写成“接口文档评审通过，字段与原型一致”，把“写完”升级为“评审通过且内容对齐”，避免文档写完但字段与原型不符的情况。填写时让每条标准指向一个可检查的产出物或状态，例如“评审通过”“报告出具”“回执收到”，而不是“基本完成”“大致就绪”这类无法核验的描述。
工期：以工作日计并写明估算依据
工期按工作日填写，示例中A02交互原型设计为4个工作日，估算依据是页面数量乘以单页设计耗时，再留出评审修改的余量。工期与持续时间要区分：工期是实际投入的工作日，持续时间是日历上跨越的天数，中间可能包含等待、周末或外部响应时间。A09提交第三方申请工期填5个工作日，指的是等待回执的响应周期，这类外部等待应在备注中说明，避免被误读为团队投入。
依赖：写前置编号、标类型、单独标外部
依赖字段至少写清前置活动的编号和依赖类型。示例中A05依赖A03和A04，类型为“完成—开始”，即两个前置活动都完成后才能开始；A03与A04之间没有依赖，可以并行。外部依赖如A09，在依赖类型中标注“外部依赖”，并写明来源方是第三方短信服务商，便于后续跟踪时区分团队可控与不可控的部分。依赖梳理的顺序建议先内部后外部、先硬依赖后软依赖，硬依赖是产出物之间客观存在的先后关系，软依赖是资源或偏好造成的顺序，可以调整。
示例中每一行的填写理由可以归纳为：名称回答做什么，完成标准回答做到什么程度算完，工期回答占多少工作日，依赖回答在谁之后。四类信息齐全，这一行才能进入排期。
可迁移规律：换一个项目怎么套用
换项目时，填写方法可以抽象为四个步骤。第一步，取WBS末级节点作为输入，每个末级节点通常对应一项或几项活动；如果节点仍然过大，继续拆分到可估算、可分配、可验收的粒度。第二步，为每项活动写动宾结构的名称和对应的完成标准，名称与标准一一对应。第三步，估算工期并注明依据，区分工期与持续时间，外部等待单独说明。第四步，梳理依赖：先找产出物之间的硬依赖，再补资源或偏好造成的软依赖，最后把外部依赖单独列出并标注来源方。
填写完成后，用下面的清单自检：
- 每项活动是否都有明确的动词和产出物，能否分配给一个角色；
- 完成标准是否可核验，能否用“通过/未通过”“收到/未收到”判断；
- 工期是否以工作日计，是否写明了估算依据；
- 工期与持续时间是否区分，外部等待是否单独说明；
- 每项依赖是否写了前置编号和依赖类型；
- 外部依赖是否单独标注来源方；
- 里程碑是否只标记时间点，没有混入工期。
这套方法在计划建立阶段使用。活动清单填好后，通常需要在项目管理工具中承载字段和依赖关系。以ONES为例，其项目计划支持创建工作分解结构、为任务设置前后置依赖，并用里程碑标记重要时间点或决策点；活动清单中的名称、工期、依赖可以对应到工作项字段和依赖设置中，形成从项目到任务的多层级计划。字段的具体名称和配置方式以实际使用版本为准。
适用边界：哪些情况需要调整写法
本文方法适用于计划建立阶段，即把WBS末级节点转成可排期活动清单的环节。执行阶段的进度跟踪、偏差分析和纠偏不在本文范围；活动清单填好后进入执行，进度反馈和基线对比是后续环节的工作。
采用滚动式规划时，远期活动信息尚不充分，可以只填活动名称和粗略工期，完成标准和精确依赖留到临近执行时再补。此时清单的作用是保留范围轮廓，不追求一次填全。外部依赖和跨团队交付的标注需要更明确：写明来源团队或供应商、约定的交付时间，以及回执或验收方式，避免把外部等待混入团队工期。
活动清单在工具中承载时，字段映射的思路是：活动名称对应工作项标题，完成标准对应验收条件或描述字段，工期对应预计工时，前置依赖对应任务间的依赖设置，里程碑单独建为里程碑类型。不同工具的字段命名和依赖类型选项存在差异，迁移或新建清单时以工具实际提供的字段为准，先确认依赖类型是否覆盖“完成—开始”等常用关系，再批量录入。
常见问题
活动清单里的里程碑要不要填工期？
里程碑只标记时间点、事件或决策点，不填工期。示例中M01“需求评审通过”作为里程碑，本身不消耗工作日，但可以作为后续活动的依赖起点。活动行则必须有工期和可核验的完成标准，两者在清单中分行呈现，避免把决策点误当成需要投入人力的任务。
工期和持续时间有什么区别，填写时怎么处理？
工期是实际投入的工作日，持续时间是日历上跨越的天数，中间可能包含等待、周末或外部响应时间。填写时工期按工作日计，并在备注中说明估算依据；遇到外部等待，例如提交第三方服务开通申请，应把等待回执的响应周期单独说明，避免被误读为团队投入。
外部依赖和内部依赖在清单里怎么区分？
外部依赖由团队之外的供应商或跨团队方响应，团队只能提交申请并等待回执。填写时在依赖类型中标注“外部依赖”，写明来源方和约定的交付时间，不与其他内部活动混排在同一依赖链上。内部依赖则写前置活动编号和“完成—开始”等类型，便于后续跟踪时区分可控与不可控部分。
采用滚动式规划时，远期活动信息不全怎么填？
远期活动信息尚不充分时，可以只填活动名称和粗略工期，完成标准和精确依赖留到临近执行时再补。此时清单的作用是保留范围轮廓，不追求一次填全。临近执行前再按名称、完成标准、工期、依赖四类信息补齐，使活动具备进入排期的条件。
活动清单填好后，在工具里怎么承载这些字段？
字段映射的思路是：活动名称对应工作项标题，完成标准对应验收条件或描述字段，工期对应预计工时，前置依赖对应任务间的依赖设置，里程碑单独建为里程碑类型。以ONES为例，其项目计划支持创建工作分解结构、为任务设置前后置依赖，并用里程碑标记重要时间点或决策点；具体字段名称和配置方式以实际使用版本为准。
