项目周报要能直接填写、跨角色读懂，关键在字段固定、口径一致。本文提供一张可复制的空白周报表格，覆盖项目基本信息、本周进展、下周计划、偏差与原因、风险与问题、健康度判断、需协调事项七组内容，并配套字段说明、必填选填规则、一份填满的示例和维护方法。周报中的进展与状态数据通常来自任务系统，例如在ONES中可由工作项状态和项目文档汇总而来，本文只讨论模板本身。
要点总览（TL;DR）
- 模板按“先事实、后判断、再请求”排列：基本信息、本周进展、下周计划、偏差与原因、风险与问题、健康度判断、需协调事项七组字段，单页可读。
- 项目名称、报告周期、汇报人、已完成事项、下周计划、健康度结论与判断依据为必填；关键数据、计划依赖、报告版本按项目阶段和汇报对象取舍。
- 健康度结论必须由本周事实支撑，判断依据列2–3条可核对事实，与偏差、风险字段一一对应；阈值由团队自行约定。
- 需协调事项写清对象、动作、时间三要素并给出期望回复时间，接收方可直接据此安排工作。
- 模板维护设定调整触发条件，字段增删经周会对照评审后更新版本号并登记调整记录，历史周报按周期归档不改写。
可复制的项目周报空白模板
下表可直接复制到文档或电子表格中使用。方括号内为填写提示，正式使用时替换为实际内容。表格按“先事实、后判断、再请求”的顺序排列：进展与计划是事实，偏差、风险与健康度是判断，需协调事项是请求。
| 分区 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 项目名称 | [项目全称] |
| 报告周期 | [YYYY-MM-DD 至 YYYY-MM-DD] | |
| 汇报人 / 审核人 | [姓名 / 姓名] | |
| 报告版本 | [V1.0，修订时递增] | |
| 项目阶段 | [启动 / 规划 / 执行 / 收尾] | |
| 本周进展与完成项 | 已完成事项 | [事项描述 + 完成标志 + 完成日期] |
| 进行中事项 | [事项描述 + 当前完成比例 + 预计完成时间] | |
| 关键数据 | [如完成需求数、缺陷关闭数、里程碑达成情况] | |
| 下周计划 | 计划事项 | [事项描述 + 负责人 + 计划完成时间] |
| 计划依赖 | [依赖的外部输入或前置事项] | |
| 偏差与原因 | 偏差描述 | [计划与实际的时间、范围或质量差异] |
| 原因与影响 | [原因分类 + 对后续计划的影响] | |
| 风险与问题 | 风险 / 问题描述 | [描述 + 触发条件或已发生事实] |
| 影响评估 | [影响范围 + 可能后果] | |
| 应对措施与责任人 | [措施 + 责任人 + 完成时间] | |
| 健康度判断 | 健康度结论 | [绿 / 黄 / 红] |
| 判断依据 | [支撑结论的 2–3 条事实] | |
| 需协调事项 | 协调事项 | [需要谁在什么时间做什么] |
| 期望回复时间 | [日期] |
表格保持单页可读，字段总数控制在二十个以内。项目规模较大时，进展与风险部分可按工作流拆成多行，但分区结构不变，便于不同项目的周报横向对比。
每个字段填什么：周报字段说明
同一份模板被多人填写时，歧义主要出现在时间口径和数据来源上。下表逐字段给出定义、填写口径和示例写法，填写前先约定统一口径，能减少周会上反复澄清。
| 字段 | 含义 | 填写口径 | 示例写法 |
|---|---|---|---|
| 报告周期 | 本周报覆盖的时间范围 | 固定为周一至周日或团队约定的周期，与上期首尾相接不重叠 | 2025-03-03 至 2025-03-09 |
| 项目阶段 | 项目当前所处阶段 | 按团队阶段定义填写，阶段变更需在周报中注明 | 执行阶段（第 2 个迭代） |
| 已完成事项 | 周期内真正完成的工作 | 以完成标志为准，如已上线、已评审通过、已交付；数据取自任务系统或交付记录 | 订单查询接口联调完成，3 月 7 日通过测试 |
| 进行中事项 | 已开始未完成的工作 | 写清完成比例和预计完成时间，比例以可核对的计数为准 | 支付模块开发完成 60%，预计 3 月 14 日提测 |
| 关键数据 | 反映进度的量化指标 | 只列与本周判断相关的数据，注明统计口径 | 本周关闭缺陷 12 个，剩余未关闭 5 个 |
| 计划事项 | 下周拟完成的工作 | 每项带负责人和计划完成时间，避免只写方向 | 完成支付模块提测，负责人张某，3 月 14 日 |
| 偏差描述 | 计划与实际的差异 | 对照上周计划逐项核对，写差异的量级 | 联调计划 3 月 5 日完成，实际 3 月 7 日完成，延后 2 天 |
| 原因与影响 | 偏差的成因及后续影响 | 原因归入需求变更、资源、技术、外部依赖等类别；影响写到具体事项 | 第三方接口文档延迟提供，导致联调顺延，提测时间相应后移 2 天 |
| 风险与问题 | 尚未发生或已发生的阻碍 | 风险写触发条件，问题写已发生事实，两者分开列 | 风险：测试环境容量不足，若下周压测前未扩容将影响性能验证 |
| 健康度结论 | 项目整体状态判断 | 按团队约定的阈值判断，结论必须由本周事实支撑 | 黄 |
| 判断依据 | 支撑健康度结论的事实 | 列 2–3 条可核对的事实，与偏差、风险字段对应 | 关键路径延后 2 天；1 项高风险未关闭；范围未变更 |
| 需协调事项 | 需要他人配合的动作 | 写清对象、动作、时间三要素，并给出期望回复时间 | 请运维团队 3 月 11 日前完成测试环境扩容，3 月 10 日前回复确认 |
进展类字段与计划类字段的区别在于时态和责任：进展描述周期内已经发生的事实，用完成标志和日期约束；计划描述下一周期拟发生的动作，用负责人和时间约束。两者混写会让读者无法判断哪些是承诺、哪些是结果。
健康度字段的判断依据需要团队事先约定。常见做法是按进度偏差天数、未关闭高风险数量、范围变更次数设定阈值，例如关键路径延后超过三天或存在未关闭高风险即判为黄。阈值由团队自行确定，周报中只呈现结论和依据，不在模板层面规定统一标准。
必填与选填：按项目阶段取舍字段
模板字段齐全不等于每次都要填满。必填项保证周报可被独立读懂，选填项按项目阶段和汇报对象取舍。
| 字段 | 属性 | 理由与适用情形 |
|---|---|---|
| 项目名称、报告周期、汇报人 | 必填 | 缺少任一项，周报无法归档和追溯 |
| 已完成事项、下周计划 | 必填 | 周报的核心信息，缺失则失去汇报意义 |
| 健康度结论与判断依据 | 必填 | 让读者快速定位项目状态，依据保证结论可核对 |
| 偏差描述与原因 | 有偏差时必填 | 无偏差可写“本周无偏差”，不建议整段省略 |
| 风险与问题 | 有则必填 | 无风险时写“无”，明确表态优于留空 |
| 需协调事项 | 有则必填 | 涉及跨团队配合时必须写清对象与时间 |
| 关键数据 | 选填 | 数据类项目、迭代型项目建议填写；探索型早期项目可省略 |
| 计划依赖 | 选填 | 存在外部依赖时填写，独立推进的工作可不填 |
| 报告版本、审核人 | 选填 | 需要正式归档或对外提交时填写 |
小型项目人员少、沟通链路短，可只保留基本信息、进展、计划、健康度四组字段，偏差和风险并入一段文字说明。跨团队项目涉及多方交接，需协调事项和计划依赖应作为必填，避免依赖在周会上才被发现。
向上汇报与团队内部同步的取舍不同。向上汇报侧重结论和请求：健康度、偏差影响、需协调事项要写足，过程细节可压缩。团队内部同步侧重动作：进行中事项、下周计划、风险应对措施要具体到人，健康度可简写。两种场景共用一张模板，通过字段详略区分即可。
完整填写示例：一个迭代型项目的周报
以下示例为演示情景：某订单系统改造项目处于第二个迭代执行阶段，周期为 2025 年 3 月 3 日至 3 月 9 日。示例中的名称和数据均为虚构，用于展示字段如何协同表达。
| 分区 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 项目名称 | 订单系统查询性能改造 |
| 报告周期 | 2025-03-03 至 2025-03-09 | |
| 汇报人 / 审核人 | 李某 / 王某 | |
| 报告版本 | V1.0 | |
| 项目阶段 | 执行阶段（第 2 个迭代） | |
| 本周进展与完成项 | 已完成事项 | 订单查询接口联调完成，3 月 7 日通过测试；查询缓存方案评审通过，3 月 6 日定稿 |
| 进行中事项 | 支付模块改造完成 60%，预计 3 月 14 日提测 | |
| 关键数据 | 本周关闭缺陷 12 个，剩余未关闭 5 个；接口平均响应时间由 800ms 降至 420ms | |
| 下周计划 | 计划事项 | 完成支付模块改造并提测，负责人张某，3 月 14 日；完成压测脚本编写，负责人赵某，3 月 12 日 |
| 计划依赖 | 压测需测试环境扩容完成，依赖运维团队 | |
| 偏差与原因 | 偏差描述 | 接口联调计划 3 月 5 日完成，实际 3 月 7 日完成，延后 2 天 |
| 原因与影响 | 第三方接口文档延迟提供，导致联调顺延；支付模块提测时间相应后移 2 天 | |
| 风险与问题 | 风险 / 问题描述 | 风险：测试环境容量不足，若 3 月 11 日前未扩容，压测无法按期开展 |
| 影响评估 | 影响性能验证进度，可能推迟整体上线时间约 3 天 | |
| 应对措施与责任人 | 提前提交扩容申请，运维团队评估资源，责任人赵某，3 月 10 日跟进 | |
| 健康度判断 | 健康度结论 | 黄 |
| 判断依据 | 关键路径延后 2 天；存在 1 项未关闭高风险；范围未发生变更 | |
| 需协调事项 | 协调事项 | 请运维团队 3 月 11 日前完成测试环境扩容，保障压测按期开展 |
| 期望回复时间 | 3 月 10 日 |
这份示例中，健康度结论“黄”与判断依据一一对应：延后 2 天来自偏差字段，未关闭高风险来自风险字段，范围未变更说明结论不是由范围问题导致。需协调事项写明了对象（运维团队）、动作（完成测试环境扩容）、时间（3 月 11 日前）和回复时间，接收方可以直接据此安排工作。
模板的调整与长期维护方法
模板用久了容易出现两种问题：字段只增不减，周报越写越长；字段与实际汇报脱节，填了没人看。维护的关键是设定调整触发条件，并让增删经过评审。
常见的调整触发条件包括：连续三期出现某字段留空或填写“无”，说明该字段与当前阶段不匹配；周会上反复口头补充模板外的信息，说明缺少对应字段；项目类型变化，如从迭代型转为交付型，字段侧重需要调整；汇报对象变化，向上汇报增加结论类字段，内部同步增加动作类字段。
字段增删建议按以下方式评审：
- 由周报填写人提出增删建议，说明要解决的问题和预期效果。
- 在周会上用一期真实周报做对照，评估新增字段是否有人填写、删除字段是否造成信息缺失。
- 评审通过后更新模板版本号，并在调整记录中登记变更内容和生效日期。
- 新版本试用两到三期后再评估，避免频繁改动导致口径混乱。
版本与归档管理方面，模板文件保留版本号和生效日期，历史周报按周期归档，不随模板更新而改写。调整记录表可采用以下表头：变更日期、变更内容、提出人、评审结论、生效版本、备注。
模板需要与既有节奏衔接。周报的填写截止时间应早于周会，让参会者提前阅读；周会议程按周报分区设置，重点讨论偏差、风险和需协调事项，进展部分以阅读为主；迭代评审的结论回写到下一期周报的健康度判断依据中，形成闭环。周报数据如果来自任务系统，可在ONES中将工作项状态与项目文档关联汇总，ONES Wiki支持周报等文档的沉淀，文档可嵌入任务进度和报表，页面组可关联项目，使周报内容与需求、任务保持对应；文档记录页面版本，支持查看与回滚，便于追溯历次周报的修改。具体可用范围以实际开通的版本和权限为准。
常见问题
周报里没有偏差、没有风险时，对应字段怎么处理？
建议明确写“本周无偏差”“无未关闭风险”，不要整段留空。留空会让读者无法区分“没有”和“忘了填”，向上汇报时尤其容易被追问。若连续多期都写“无”，可参考模板维护方法评估该字段是否与当前项目阶段不匹配，再决定保留或调整。
健康度的绿黄红阈值应该由谁定，能不能直接套用通用标准？
阈值由团队自行约定，模板层面只规定“结论加依据”的写法，不规定统一标准。常见做法是按关键路径偏差天数、未关闭高风险数量、范围变更次数设定阈值，例如关键路径延后超过三天或存在未关闭高风险即判为黄。阈值一旦确定，应在团队内公开并保持稳定，调整时同步更新模板说明，避免同一结论在不同周报里含义不同。
向上汇报和团队内部同步能否共用一张模板？
可以共用，通过字段详略区分。向上汇报侧重结论和请求，健康度、偏差影响、需协调事项写足，过程细节压缩；团队内部同步侧重动作，进行中事项、下周计划、风险应对措施具体到人，健康度可简写。两种场景使用同一分区结构，便于周报归档后横向对比。
周报数据和任务系统里的状态对不上，以哪个为准？
以任务系统中可核对的状态和完成标志为准，周报是对这些事实的汇总表达。填写前先核对工作项状态、缺陷关闭数等数据，再写入周报；若发现系统记录与实际不一致，先修正系统记录，避免周报与系统长期两套口径。周报中引用的关键数据注明统计口径和统计时间，便于后续追溯。
模板调整后，历史周报需要按新模板重写吗？
不需要。历史周报按周期归档，保留当时的模板版本和内容，不随模板更新而改写。模板文件本身保留版本号和生效日期，调整记录登记变更内容、提出人、评审结论和生效版本，这样既能追溯历次周报的原始信息，也能看清模板的演进过程。
