研发项目综合计划模板可以拆成六张表：计划信息与范围、活动清单、依赖关系、里程碑、资源与责任、计划基线与变更记录。活动按可交付成果逐层拆到能排期的粒度；依赖只记录真实约束，并标注类型和提前滞后量；里程碑锚定关键评审或交付节点，本身不承担工期。三部分排定并确认后形成基线，后续调整写入变更记录。
要点总览（TL;DR）
- 研发项目综合计划模板由六张表组成：计划信息与范围、活动清单、依赖关系、里程碑、资源与责任、计划基线与变更记录。
- 活动按可交付成果逐层拆到能排期、可指派单一负责人的粒度，工期通常落在数个工作日到两周之间。
- 依赖只记录真实约束，标注完成-开始等类型和提前滞后量，并区分硬依赖与软依赖。
- 里程碑锚定评审、交付或决策节点，工期为零、不分配工作量，判定标准写成可核验条件。
- 活动、依赖、里程碑排定并确认后建立基线，后续日期、范围、依赖的变化登记变更记录。
可复制空白模板：研发项目综合计划表
下面六张表可以直接粘贴到文档或表格工具中填写。表头保持固定，行数按项目规模增减。建议一个项目使用一份文件，六张表放在同一文件中，用编号互相引用。
表1 计划信息与范围
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 项目编号 | |
| 计划版本 | |
| 编制人 / 日期 | |
| 项目经理 | |
| 计划起止时间 | |
| 项目目标 | |
| 交付范围（纳入） | |
| 范围外事项 | |
| 关键假设 | |
| 主要约束（时间、人力、技术） | |
| 审批人 / 审批日期 |
表2 活动清单
| 活动编号 | 活动名称 | 所属交付物 / 阶段 | 层级 | 负责人 | 计划开始 | 计划完成 | 工期（天） | 完成标准 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
表3 依赖关系
| 依赖编号 | 前置活动 | 后置活动 | 依赖类型 | 提前 / 滞后量 | 约束说明 | 是否硬依赖 |
|---|---|---|---|---|---|---|
表4 里程碑
| 里程碑编号 | 里程碑名称 | 类型（评审 / 交付 / 决策） | 计划日期 | 判定标准 | 责任人 | 关联活动编号 |
|---|---|---|---|---|---|---|
表5 资源与责任
| 角色 | 姓名 / 团队 | 投入比例 | 负责活动编号 | 可用时间窗口 | 技能或权限要求 | 备份责任人 |
|---|---|---|---|---|---|---|
表6 计划基线与变更记录
| 基线版本 | 建立日期 | 基线范围（活动 / 里程碑） | 确认人 |
|---|---|---|---|
| 变更编号 | 变更日期 | 变更对象（编号） | 变更前 | 变更后 | 变更原因 | 影响评估 | 审批人 |
|---|---|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么判断
六张表里最容易填错的是活动粒度、依赖类型和里程碑判定。下面按表逐项说明填写口径，与表1至表6的字段一一对应。
活动粒度与拆解层级
活动清单按可交付成果逐层分解：第一层是阶段或主要交付物，第二层是交付物的组成部分，第三层拆到可排期、可指派单一负责人的活动。判断粒度是否合适，看三条：活动有明确的完成标准；工期通常落在数个工作日到两周之间；一个活动对应一个主要负责人。工期明显偏长的活动继续往下拆，短到无法单独跟踪的合并到上级活动。层级字段填1、2、3，便于筛选和汇总。
依赖类型与提前滞后量
依赖关系表只记录活动之间真实存在的约束，不把“希望先做”写成依赖。依赖类型常用四种：完成-开始（前置完成后后置才能开始）、开始-开始（前置开始后后置才能开始）、完成-完成（前置完成后后置才能完成）、开始-完成（前置开始后后置才能完成）。提前滞后量用正负天数表示：滞后为正，表示前置完成后需等待若干天；提前为负，表示后置可提前介入。硬依赖指由技术或合同决定、不能调整的约束，软依赖指由资源或偏好形成、可协商的约束，在“是否硬依赖”字段标注，便于压缩工期时判断先动哪一条。
里程碑与活动的区别
里程碑标记重要时间点、事件或决策点，工期为零，不分配工作量；活动是实际执行的工作，有工期和负责人。判断一个节点该不该设为里程碑，看它是否对应一次需要确认的评审、交付或决策：例如需求评审通过、架构方案确认、版本提测、上线发布。普通任务完成不单独设里程碑。里程碑的判定标准要写成可核验的条件，例如“评审纪要签署完成”，避免写成“基本完成”。
资源与责任字段口径
角色按项目实际分工填写，如产品、开发、测试、运维；投入比例用百分比或人天表示，同一人在多个项目间分配时按项目分别记录；负责活动编号与表2的活动编号对应，便于反查工作量；可用时间窗口写明该角色在本项目中的可用区间，休假、借调等已知占用在此体现；备份责任人用于关键角色缺位时的交接。
基线字段含义
基线是经确认、作为后续对比基准的计划版本。基线版本按V1、V2递增；基线范围写明本次基线覆盖哪些活动和里程碑；确认人是批准该版本的责任人。变更记录中的“变更前 / 变更后”填写具体日期、工期或依赖关系的变化，“影响评估”写明对后续活动、里程碑日期和资源的影响，审批人记录同意该变更的人。
必填与选填：哪些字段不能空
模板分两档使用：小团队或短周期项目用最小可用版本，跨团队、周期长或需要对外承诺的项目用完整版本。两档的差别在字段覆盖范围，六张表的结构都保留。
| 表 | 必填字段 | 选填字段 |
|---|---|---|
| 计划信息与范围 | 项目名称、项目经理、计划起止时间、项目目标、交付范围 | 项目编号、关键假设、主要约束、审批人 |
| 活动清单 | 活动编号、活动名称、负责人、计划开始、计划完成、完成标准 | 所属交付物 / 阶段、层级、工期、备注 |
| 依赖关系 | 前置活动、后置活动、依赖类型 | 提前 / 滞后量、约束说明、是否硬依赖 |
| 里程碑 | 里程碑名称、计划日期、判定标准、责任人 | 类型、关联活动编号 |
| 资源与责任 | 角色、姓名 / 团队、负责活动编号 | 投入比例、可用时间窗口、技能要求、备份责任人 |
| 计划基线与变更记录 | 基线版本、建立日期、确认人；变更编号、变更对象、变更前后、审批人 | 基线范围、变更原因、影响评估 |
最小可用版本适用于周期在一个季度内、团队规模小、活动间依赖简单的项目，保留上表必填字段即可开始排期。完整版本适用于多团队协作、有外部交付承诺或需要阶段评审的项目，建议把选填字段一并填写，尤其是依赖的提前滞后量、资源的投入比例和变更的影响评估，这些字段在计划调整时提供判断依据。
填写示例：一个研发迭代计划的完整填法
以下为演示情景，用于说明六张表的填写方式，数值仅作示例。
示例背景与范围
某研发团队计划用八周完成订单模块重构，目标是替换旧结算逻辑并保持线上功能可用。范围包含接口改造、数据迁移脚本、回归测试和灰度发布；范围外包含移动端适配和报表改版。主要约束为两名后端、一名测试可投入，灰度发布窗口由运维排期决定。
活动清单填写
| 活动编号 | 活动名称 | 所属交付物 | 层级 | 负责人 | 计划开始 | 计划完成 | 工期 | 完成标准 |
|---|---|---|---|---|---|---|---|---|
| A01 | 结算接口现状梳理 | 接口改造 | 3 | 后端甲 | 第1周周一 | 第1周周五 | 5天 | 接口清单与调用关系文档评审通过 |
| A02 | 新结算接口设计与评审 | 接口改造 | 3 | 后端甲 | 第2周周一 | 第2周周四 | 4天 | 设计文档签署 |
| A03 | 接口编码与自测 | 接口改造 | 3 | 后端乙 | 第2周周五 | 第4周周三 | 8天 | 自测用例全部通过 |
| A04 | 数据迁移脚本编写 | 数据迁移 | 3 | 后端乙 | 第3周周一 | 第4周周五 | 10天 | 脚本在测试库执行成功 |
| A05 | 回归测试 | 测试 | 3 | 测试丙 | 第5周周一 | 第6周周五 | 10天 | 回归用例通过率达标，缺陷关闭 |
| A06 | 灰度发布 | 发布 | 3 | 后端甲 | 第7周周一 | 第7周周五 | 5天 | 灰度流量稳定，监控无异常 |
依赖关系填写
| 依赖编号 | 前置活动 | 后置活动 | 依赖类型 | 提前 / 滞后量 | 约束说明 | 是否硬依赖 |
|---|---|---|---|---|---|---|
| D01 | A01 | A02 | 完成-开始 | 0 | 设计需基于现状梳理结果 | 是 |
| D02 | A02 | A03 | 完成-开始 | 0 | 设计评审通过后编码 | 是 |
| D03 | A03 | A05 | 完成-开始 | 0 | 接口自测通过后进入回归 | 是 |
| D04 | A04 | A05 | 完成-开始 | 0 | 迁移脚本就绪后测试数据准备 | 是 |
| D05 | A05 | A06 | 完成-开始 | 2 | 回归通过后等待运维窗口 | 是 |
里程碑填写
| 里程碑编号 | 里程碑名称 | 类型 | 计划日期 | 判定标准 | 责任人 | 关联活动 |
|---|---|---|---|---|---|---|
| M1 | 接口设计评审通过 | 评审 | 第2周周四 | 设计文档签署完成 | 后端甲 | A02 |
| M2 | 提测 | 交付 | 第4周周五 | 接口与迁移脚本均提交测试环境 | 后端乙 | A03、A04 |
| M3 | 灰度发布决策 | 决策 | 第6周周五 | 回归报告通过，缺陷关闭 | 项目经理 | A05 |
资源与基线填写
资源表按角色记录：后端甲投入50%，负责A01、A02、A06；后端乙投入80%，负责A03、A04；测试丙投入60%，负责A05；运维作为发布窗口的协作方列入可用时间窗口。基线表记录V1在第1周周五建立，覆盖A01至A06和M1至M3，由项目经理确认。第3周因运维窗口后移，A06计划日期调整，在变更记录中登记变更编号C01，写明变更前后日期、原因和影响评估，由项目经理审批。活动、依赖与里程碑排定后，团队可以把这些表落到具体工具中执行。在ONES中，可用「项目计划」创建工作分解结构，按目标、交付物或阶段分解计划和工作；为任务设置前后置依赖，用里程碑标记重要时间点、事件或决策点；设置计划和里程碑基线后对比计划与执行的偏差，并通过版本细节追溯变更。工时日历和饱和度报表可用于核对资源投入是否与资源表一致。
调整与维护方法：基线之后怎么改
基线建立后，计划仍然会变，关键是让每次变化有记录、可追溯，模板才能长期使用。
基线建立时点
活动、依赖、里程碑排定并经项目关键角色确认后建立基线，通常在项目启动会或计划评审会后。基线建立前可以自由调整；建立后，日期、范围、依赖的变化进入变更流程。一个项目可以有多条基线，重大范围调整后建立新版本，旧版本保留。
变更记录填写方式
每次变更登记一条记录：变更编号连续编号；变更对象写活动或里程碑编号；变更前后写具体日期、工期或依赖关系；变更原因写触发因素，如资源变动、外部窗口调整、需求变化；影响评估写对后续活动、里程碑日期和资源的影响；审批人记录同意变更的责任人。只改表2或表4而不登记变更，会让基线失去对比意义。
活动与依赖的增删规则
新增活动先确认它属于哪个交付物、由谁负责、完成标准是什么，再补进活动清单并检查是否引入新依赖；删除活动前检查是否有后置活动依赖它，有则先调整依赖关系再删除；修改依赖类型或提前滞后量，同样登记变更。依赖关系表保持“一条约束一行”，避免把多条约束写进同一行。
里程碑调整条件
里程碑日期调整需要满足明确条件：关联活动的计划发生实质变化，或外部评审、发布窗口变更。调整时同步更新判定标准和关联活动编号，并在变更记录中说明原因。里程碑只改日期、判定标准不变的情况，也要登记，便于后续复盘时区分“节点推迟”和“标准放宽”。
模板定期复盘
建议在阶段结束时复盘一次模板使用情况：哪些字段实际没填、哪些字段反复引发歧义、活动粒度是否合适、依赖记录是否遗漏。复盘结论用于修订模板本身，例如增删选填字段或调整完成标准的写法。模板版本与项目计划版本分开管理，模板修订不影响已建立的项目基线。
常见问题
活动拆到多细才算合适？拆过头了怎么办？
判断标准有三条：活动有明确的完成标准；工期通常落在数个工作日到两周之间；一个活动对应一个主要负责人。满足这三条即可停止拆解。
如果拆得过细，会出现大量一两天甚至半天的活动，跟踪成本高于管理收益。这时可以把同一负责人、同一交付物下连续的小活动合并为一条，在完成标准里写清合并后的验收条件。反过来，工期明显偏长的活动继续往下拆，避免一条活动横跨数周、无法判断进度。
依赖关系表里的提前滞后量什么时候必须填？
当前置完成后后置需要等待一段时间（如运维发布窗口、外部评审排期），或后置可以在前置完成前提前介入（如测试用例设计与开发并行）时，提前滞后量必须填写，否则排出的日期与实际不符。
前置完成即可立即开始、没有等待和提前介入的情况，填0即可。提前滞后量属于选填字段，但在多团队协作或依赖外部窗口的项目中建议填写，它是计划调整时判断可压缩空间的重要依据。
里程碑和阶段评审是什么关系，每个评审都要设里程碑吗？
里程碑标记重要时间点、事件或决策点，工期为零；阶段评审是常见的里程碑类型之一。是否设里程碑，看该节点是否需要一次明确的确认动作，例如需求评审通过、架构方案确认、版本提测、上线发布。
并非每个评审都要单独立里程碑。例行的小范围评审可以并入关联活动的完成标准；只有需要跨角色确认、影响后续多个活动排期的评审，才值得单独设为里程碑，避免里程碑表被稀释成任务清单。
基线建立后，发现原计划排错了，能直接改表吗？
基线建立后，日期、范围、依赖的变化应进入变更流程：在变更记录中登记变更编号、变更对象、变更前后内容、原因、影响评估和审批人，再修改活动清单或里程碑表。只改表不登记，基线就失去对比意义。
如果错误涉及范围或关键节点，影响面较大，可以建立新版本基线，旧版本保留，便于复盘时区分计划调整和执行偏差。基线建立前的调整不受此限制，可以自由修改。
小团队用这套模板，六张表都要填吗？
六张表的结构建议保留，字段可以按最小可用版本填写。周期在一个季度内、团队规模小、依赖简单的项目，保留各表的必填字段即可开始排期，例如活动清单只填编号、名称、负责人、计划起止和完成标准。
多团队协作、有外部交付承诺或需要阶段评审的项目，建议把选填字段一并填写，尤其是依赖的提前滞后量、资源的投入比例和变更的影响评估。这些字段在计划调整和资源协调时提供判断依据。
