研发工作日历模板的字段可以按三层组织：日历基本信息、日期类型与例外规则、可用工时计算。第一层确定这份日历适用于哪个团队、哪段时间、按什么口径统计；第二层逐日标注工作日、休息日、法定节假日、调休补班和团队例外；第三层把日期折算成可分配的人力。本文提供可直接复制填写的三张空白表、逐字段填写说明、必填与选填对照、一份研发小组月度日历示例，以及版本调整与维护规则。
要点总览（TL;DR）
- 研发工作日历模板按三层字段组织：日历基本信息、日期类型与例外规则、可用工时计算，三张表通过日历编号和统计周期关联。
- 日期类型使用固定枚举值：工作日、休息日、法定节假日、调休补班、团队例外；调休补班必须填写关联原日期，团队例外必须填写例外说明和影响范围。
- 可用工时=标准工时合计−扣除项工时，扣除项逐项列出培训、值班、休假、冻结期等占用，单位统一为人时，再按折算规则换成人天。
- 日历编号、统计周期、统计口径、标准工时、版本号以及表2的日期与日期类型属于必填字段，缺失会导致日历无法用于容量测算。
- 日历变更采用版本号加变更记录表留痕，临时例外以追加行方式写入，测算表引用时注明日历编号和版本号。
可复制空白模板：研发工作日历字段表
以下三张表构成一份完整的研发工作日历。表1记录日历的身份与统计前提，表2逐日记录日期类型和例外，表3按人员或团队汇总可用工时。三张表通过“日历编号”和“周期”关联，填写时保持编号一致。
表1 日历基本信息
| 字段名 | 填写内容 | 示例 |
|---|---|---|
| 日历编号 | 团队内唯一的日历标识 | RD-CAL-2025-06 |
| 日历名称 | 便于识别的名称 | 平台研发组2025年6月工作日历 |
| 适用团队 | 使用该日历的团队或项目组 | 平台研发组 |
| 适用人员范围 | 纳入统计的岗位或人员清单 | 后端工程师6人、测试工程师2人 |
| 统计周期 | 起止日期，精确到日 | 2025-06-01至2025-06-30 |
| 统计口径 | 工时单位与折算规则 | 人天，1人天=8人时 |
| 标准工时 | 单个工作日的基准工时 | 8人时/人/工作日 |
| 编制人 | 负责填写与维护的人 | 项目助理 |
| 审核人 | 确认口径的人 | 研发经理 |
| 版本号 | 按修改次数递增 | V1.0 |
| 生效日期 | 该版本开始使用的日期 | 2025-05-28 |
| 备注 | 特殊说明 | 含端午假期调休 |
表2 日期类型与例外规则
| 日期 | 星期 | 日期类型 | 是否工作日 | 标准工时（人时） | 例外说明 | 影响范围 | 关联原日期 |
|---|---|---|---|---|---|---|---|
表3 可用工时计算
| 人员/角色 | 周期内工作日数 | 标准工时合计（人时） | 扣除项 | 扣除工时（人时） | 可用工时（人时） | 折合可用人天 | 备注 |
|---|---|---|---|---|---|---|---|
字段说明：每个字段记录什么、怎么填
字段说明的目标是让不同团队按同一口径填写，避免同一份日历在不同人手里算出不同的人力数。以下按三张表逐项说明。
日历基本信息表
“适用人员范围”要写到可核对的粒度，例如列出岗位和人数，或引用一份人员清单。范围写得含糊，后续可用工时汇总就无法与人员对应。“统计口径”需要同时写明工时单位和折算规则，例如“人天，1人天=8人时”，这样表3中的人时与人天才能互相换算。“标准工时”是后续所有扣除计算的基准，同一份日历内应保持一致；如果团队存在弹性工时或部分岗位工时不同，应在备注中说明，或拆分为多份日历。
日期类型与例外规则表
“日期类型”建议使用固定枚举值，便于筛选和汇总：
- 工作日：正常上班的周一至周五，标准工时按日历基本信息中的基准填写。
- 休息日：周末或团队约定的休息日，标准工时记0。
- 法定节假日：按国家或地区公布的节假日安排填写，标准工时记0。
- 调休补班：因节假日调整而上班的周末，标准工时按工作日填写，并在“关联原日期”中注明被调整的休息日。
- 团队例外：培训、值班、冻结期、加班安排等团队层面的特殊日期，通过“例外说明”和“影响范围”描述具体影响。
“例外说明”承担记录具体事件的作用。培训写清主题和参与范围，例如“全员安全培训，后端组8人参加半天”；值班写清值班人数和是否占用可用工时；冻结期写清起止日期和禁止变更的范围，例如“版本冻结，6月24日至6月26日不接受需求变更”；加班安排写清加班日期和预计投入人数。“影响范围”用于限定例外作用于哪些人员，避免把局部例外套用到整个团队。“关联原日期”用于调休补班场景，记录被调换的原休息日，便于追溯。
可用工时计算表
可用工时的计算口径为：标准工时合计减去扣除项工时。标准工时合计等于周期内工作日数乘以单人每日标准工时，再乘以该角色人数；扣除项包括培训、值班占用、已批准的休假、冻结期内无法投入的工时等。单位统一使用人时，最后一行折算为人天时按日历基本信息中的折算规则换算。扣除项建议逐项列出名称和工时，而不是只填一个合计数字，这样复核时能看出扣减依据。
必填与选填：哪些字段不能空
必填字段缺失会直接导致日历无法用于容量测算，选填字段则按团队管理精细度决定是否填写。下表给出对照。
| 表 | 字段 | 必填/选填 | 说明 |
|---|---|---|---|
| 表1 | 日历编号、日历名称、适用团队、统计周期、统计口径、标准工时、版本号 | 必填 | 缺少任何一项，日历无法被唯一识别或无法折算工时 |
| 表1 | 适用人员范围 | 条件必填 | 需要按人员汇总可用工时时必填；仅做团队整体日历时可填团队人数 |
| 表1 | 编制人、审核人、生效日期、备注 | 选填 | 用于责任追溯和版本管理，建议填写 |
| 表2 | 日期、日期类型、是否工作日、标准工时 | 必填 | 逐日记录的基础，缺失会导致工作日数统计错误 |
| 表2 | 例外说明、影响范围 | 条件必填 | 日期类型为团队例外时必填，普通工作日可空 |
| 表2 | 关联原日期 | 条件必填 | 日期类型为调休补班时必填 |
| 表3 | 人员/角色、周期内工作日数、标准工时合计、扣除项、扣除工时、可用工时 | 必填 | 构成可用工时的完整计算链 |
| 表3 | 折合可用人天、备注 | 选填 | 便于阅读和说明特殊扣减 |
条件必填字段的判断依据是日期类型：只要某天被标记为团队例外或调休补班，对应说明字段就必须填写，否则该天的影响无法被后续测算识别。
填写示例：一个研发小组的月度日历
以下示例为演示情景，用于展示字段之间的联动关系，人员与日期均为虚构设定。
示例团队为平台研发组，统计周期为2025年6月1日至6月30日，统计口径为人天、1人天=8人时，标准工时为8人时/人/工作日。该月含端午节假期及调休，团队另安排一次集中培训和一次版本冻结。
示例：日历基本信息
| 字段名 | 填写内容 |
|---|---|
| 日历编号 | RD-CAL-2025-06 |
| 日历名称 | 平台研发组2025年6月工作日历 |
| 适用团队 | 平台研发组 |
| 适用人员范围 | 后端工程师6人、测试工程师2人，共8人 |
| 统计周期 | 2025-06-01至2025-06-30 |
| 统计口径 | 人天，1人天=8人时 |
| 标准工时 | 8人时/人/工作日 |
| 版本号 | V1.0 |
示例：日期类型与例外规则（节选）
| 日期 | 星期 | 日期类型 | 是否工作日 | 标准工时（人时） | 例外说明 | 影响范围 | 关联原日期 |
|---|---|---|---|---|---|---|---|
| 2025-06-02 | 一 | 法定节假日 | 否 | 0 | 端午节假期 | 全员 | |
| 2025-06-07 | 六 | 调休补班 | 是 | 8 | 端午调休上班 | 全员 | 2025-06-02 |
| 2025-06-13 | 五 | 团队例外 | 是 | 4 | 集中培训半天，下午恢复工作 | 后端工程师6人 | |
| 2025-06-24 | 二 | 团队例外 | 是 | 8 | 版本冻结开始，不接受需求变更 | 全员 | |
| 2025-06-28 | 六 | 团队例外 | 是 | 8 | 上线值班，测试工程师2人 | 测试工程师2人 |
示例：可用工时计算
按该月日历，周期内工作日共21天，其中6月13日为半天培训。以后端工程师为例：标准工时合计为21天×8人时×6人=1008人时；扣除培训半天6人×4人时=24人时，扣除已批准休假1人×8人时=8人时，可用工时为976人时，折合122人天。测试工程师标准工时合计为21×8×2=336人时，扣除值班占用的调休补偿8人时，可用工时为328人时，折合41人天。团队合计可用工时为1304人时，折合163人天。
| 人员/角色 | 周期内工作日数 | 标准工时合计（人时） | 扣除项 | 扣除工时（人时） | 可用工时（人时） | 折合可用人天 |
|---|---|---|---|---|---|---|
| 后端工程师（6人） | 21 | 1008 | 集中培训、已批准休假 | 32 | 976 | 122 |
| 测试工程师（2人） | 21 | 336 | 值班调休补偿 | 8 | 328 | 41 |
| 团队合计 | 21 | 1344 | — | 40 | 1304 | 163 |
这份结果可以直接作为容量测算的供给侧输入：把163人天与同期需求预估的人天投入对比，就能看出人力缺口或余量。日历中的例外说明同时解释了缺口来自哪些日期和事件。
当团队规模扩大、日历需要按项目或季度反复使用时，可以把上述三张表落到研发管理工具中维护。ONES 支持在工作项和项目计划中设置工作日历与可用工时口径，将人员可用工时与需求、任务的预估工时放在同一套数据里对照，减少日历表与排期表各算一套的情况。是否需要在工具中维护，取决于团队是否已有稳定的容量测算节奏；单次测算用表格即可完成。
调整与维护方法：日历变更如何留痕
日历一旦用于容量测算，任何变更都会影响供给数字，因此需要固定版本和变更记录方式，避免多份口径并存。
版本号与变更记录
每次修改日历内容时递增版本号，并在日历之外维护一张变更记录表，至少包含：变更日期、变更字段、变更前内容、变更后内容、变更原因、变更人、审核人。版本号建议采用“主版本.次版本”格式，日期类型或统计口径调整记主版本，例外说明补充记次版本。变更记录与日历同编号存放，便于回溯某次测算使用的是哪一版。
临时例外的追加方式
突发调休、临时集中培训、紧急值班等临时例外，按“追加行”的方式写入表2，不覆盖原有记录；同时在变更记录中登记追加原因和影响范围。若临时例外改变了已发布的可用工时结果，应同步更新表3并递增版本号，而不是只在备注中口头说明。
复核与归档
建议每月初复核上月日历的实际执行情况，核对实际工作日、实际扣除项与计划是否一致；每季度对统计口径、标准工时和适用人员范围做一次整体检查。周期结束后将日历与变更记录一并归档，保留至少与项目考核周期相同的时长，便于后续复盘人力投入。
与容量测算的口径同步
日历是容量测算的供给输入，测算表引用日历时应注明日历编号和版本号。日历更新后，引用它的测算表需要同步刷新，并在测算记录中写明所用版本。团队若同时维护多份日历，例如按项目组和按职能各一份，应明确哪一份是测算基准，其余日历只作参考，避免同一周期出现两个可用工时数字。
常见问题
研发工作日历模板和普通考勤日历有什么区别，能不能直接拿考勤表改？
考勤日历记录的是个人出勤事实，研发工作日历模板服务于容量测算，需要把日期折算成可分配人力。直接改用考勤表通常会缺少三类字段：一是统计口径与标准工时，导致人时和人天无法换算；二是团队例外的影响范围，例如培训只影响部分岗位，考勤表难以体现；三是扣除项明细，容量测算需要看到扣减来自哪些事件。建议在考勤数据之外单独维护一份工作日历，两者口径对齐但用途分开。
团队存在弹性工时或部分岗位每日工时不同，模板要怎么调整？
有两种处理方式。若差异只涉及少数人员，可在日历基本信息表的备注中说明差异，并在可用工时计算表中按角色分行，分别填写各自的标准工时合计。若差异覆盖多个团队或岗位体系，建议拆分为多份日历，每份日历使用独立编号和统一的标准工时，避免同一份日历内出现多个基准导致汇总失真。拆分后需在容量测算中明确以哪份日历为基准。
调休补班和法定节假日落在同一天时，日期类型怎么填？
以实际是否上班为准。当天实际安排上班的，日期类型填“调休补班”，是否工作日填“是”，标准工时按工作日填写，并在关联原日期中注明被调换的休息日；当天实际休息的，按法定节假日或休息日填写，标准工时记0。同一天只保留一条主记录，补充说明写入例外说明字段，避免同一日期出现两条互相矛盾的记录影响工作日数统计。
日历做好后，月中出现临时调休或集中培训，已发布的可用工时要不要重算？
需要重算。临时例外按追加行写入日期类型表，同时在变更记录中登记原因和影响范围；若该例外改变了已发布的可用工时结果，应同步更新可用工时计算表并递增版本号。测算表引用日历时注明所用版本，日历更新后同步刷新测算结果。只在备注中口头说明、不更新计算结果，会让后续复盘无法判断缺口来自计划变化还是执行偏差。
多个项目组共用一份团队日历，还是各自维护一份更合适？
取决于测算的基准层级。若容量按团队整体测算，维护一份团队级日历作为基准，各项目组在测算时引用同一编号和版本，可以减少口径冲突。若各项目组的假期安排、培训节奏差异明显，可各自维护项目组日历，但需明确团队级日历为测算基准，项目组日历只作参考。无论哪种方式，同一统计周期内用于测算的可用工时数字应只有一个来源。
