项目周报要让人一眼看懂项目现在怎么样、下周要做什么、哪里可能出问题。本文给出一份假设情景下的完整周报范例，按“本周进展、下周计划、风险与问题、需协调事项”四块填写，并逐条解释写法依据，最后说明换项目时哪些地方需要调整。示例仅用于说明写法，不代表真实客户案例。
要点总览（TL;DR）
- 项目周报示例按四块固定结构填写：本周进展、下周计划、风险与问题、需协调事项，读者能在五分钟内完成阅读和判断。
- 每条进展写清交付物与完成状态，每条计划写清可验证的完成标志，避免“推进中”“继续跟进”这类无法核对的表述。
- 风险条目写明影响、概率、责任人和应对措施；协调事项写明请谁做什么、期望结论和需要的时间点。
- 健康度结论从条目事实汇总得出，并写明升级或降级的条件，先写条目再定颜色。
- 这份示例适用于周期明确、交付物可分解的综合管理类项目；探索型项目、多团队协作项目需调整条目颗粒度和分组方式。
示例目标：这份周报要解决什么
先设定一个假设情景：某公司内部系统改造项目，周期为三个月，团队包含产品、开发、测试三方，项目经理每周五向部门负责人和协作方发送周报。这个情景是虚构的，用来演示一份周报从头部信息到健康度结论的完整写法。
这份周报的读者有两类。部门负责人关心整体进度是否可控、是否需要他出面协调资源；协作方关心自己依赖的事项有没有被推进、需要配合的时间点在哪。周报承担的管理任务是：用可核对的事实替代口头询问，让读者在五分钟内完成三件事——确认本周交付了什么、判断下周计划是否可信、决定自己要不要采取行动。
本文聚焦综合管理视图下的周报写法，覆盖结构、条目颗粒度、状态口径和健康度判断。进度纠偏的具体方法、跨团队研发效能指标设计、工具产品选型对比不在本文展开，这些内容需要单独讨论。
完整示例：一份项目周报范例
以下为示例周报的完整正文，可直接对照填写。项目名称、人名、日期均为虚构。
| 字段 | 内容 |
|---|---|
| 项目名称 | 内部审批系统改造（示例） |
| 报告周期 | 第 6 周（周一至周五） |
| 汇报人 | 项目经理 张示例 |
| 整体状态 | 黄色——存在一项进度偏差，已制定追赶计划 |
本周进展
- 审批流配置模块完成开发并提交测试，交付物为配置页面与流程引擎对接代码，状态：已完成，测试已排期至下周二。
- 历史数据迁移脚本完成 60%，交付物为迁移脚本与校验报告初稿，状态：进行中，剩余部分依赖数据源接口开放。
- 权限模型评审完成，输出评审纪要与修订后的权限矩阵，状态：已完成，两条修订意见已纳入下周开发范围。
下周计划
- 完成审批流配置模块的测试用例执行，输出测试报告，完成标志为用例通过率达到约定阈值。
- 完成历史数据迁移脚本剩余 40%，输出全量校验报告，完成标志为抽样数据比对无差异。
- 启动移动端适配方案设计，输出方案文档并组织一次评审。
风险与问题
| 风险/问题 | 影响 | 概率 | 责任人 | 应对措施 |
|---|---|---|---|---|
| 数据源接口开放时间晚于计划 | 迁移脚本无法完成联调，可能影响第 7 周整体进度约 3 天 | 中 | 李示例 | 本周已发出接口需求单，下周一前确认开放时间；若延迟，先完成可离线部分 |
| 测试环境资源紧张 | 测试执行可能排队，测试报告延后 | 低 | 王示例 | 已与运维约定错峰使用时段 |
需协调与决策事项
- 请部门负责人确认数据源接口的优先级，期望在下周一前给出结论，以便决定是否调整迁移排期。
- 请协作方在周三前提供移动端适配涉及的终端型号清单，用于方案设计。
整体健康度结论
本周整体状态为黄色。判断依据：三项计划交付物中两项已完成，一项完成 60%；存在一项中等概率的进度风险，影响范围约 3 天，已有应对措施和责任人；需协调事项集中在接口开放时间，若下周一前确认，进度可回到计划轨道。若接口确认延迟超过一周，状态将调整为红色。
逐项解释：每条为什么这样写
示例中的每条内容都对应一个可核对的对象，下面拆解关键写法。
进展条目：交付物加状态
进展条目的写法是“做了什么 + 交付了什么 + 现在什么状态”。例如“审批流配置模块完成开发并提交测试”，交付物是配置页面与对接代码，状态是已完成。读者据此可以判断这条进展是否真的结束，而不是停留在“推进中”这类无法核对的描述。百分比只在有明确计算口径时使用，如“迁移脚本完成 60%”对应已覆盖的脚本范围。
计划条目：可验证的完成标志
计划条目要写清完成标志，让下周的读者能判断计划是否达成。“输出测试报告”是动作，“用例通过率达到约定阈值”是完成标志。缺少完成标志的计划容易在下一周变成模糊的“继续推进”，周报的连续性就断了。
风险条目：影响、概率、责任人三件套
风险写法要回答三个问题：影响什么、有多大可能发生、谁负责。示例中“数据源接口开放时间晚于计划”写明影响为进度约 3 天、概率为中、责任人为李示例，并附应对措施。只写“有风险”而不写影响和责任人，读者无法判断是否需要介入。概率用高、中、低即可，不必编造精确百分比。
协调事项：决策请求加时间点
协调事项的本质是请对方做一个决定或提供一个输入。写法包含三要素：请谁做什么、期望的结论是什么、什么时候需要。“请部门负责人确认数据源接口的优先级，期望在下周一前给出结论”就是完整的一条。没有时间点的协调事项容易被搁置，周报也就失去了推动力。
健康度判断：来自可核对的事实
健康度结论要能追溯到前面的条目。示例中黄色状态的依据是交付物完成比例、风险等级和协调事项的时间窗口，并写明升级为红色的条件。健康度是条目汇总后的判断，先写条目再下结论，避免先定颜色再找理由。
可迁移规律：换项目也能套用的写法
示例中的结构可以迁移到多数综合管理类项目，关键是把规则固定下来。
- 四块结构固定：本周进展、下周计划、风险与问题、需协调事项作为固定栏目，读者形成阅读习惯后能快速定位信息。项目阶段变化时调整条目内容，栏目本身保持稳定。
- 状态口径统一：全篇使用同一套状态词，如已完成、进行中、延期、未开始。同一状态在不同条目中表述一致，读者才能横向比较。团队可以在项目启动时约定这套词并写入周报模板。
- 颗粒度按读者决策需要取舍：一条进展对应一个可交付的结果，不按人天或任务数罗列。条目数量控制在读者五分钟能读完的范围，细节留在任务系统里，周报只呈现结论和需要关注的部分。
- 与会议和任务系统衔接：周报中的风险与协调事项可以直接成为周会讨论议程；进展条目对应任务系统中的工作项状态，周报写结论，系统存明细，两者口径保持一致，避免周报和系统数据对不上。
当周报中的进展、风险和协调事项需要长期沉淀并跟踪状态变化时，可以把它们放到项目协作工具中管理。以 ONES 为例，项目列表可用于查看项目状态、资源投入和当前进展；设置项目计划和里程碑基线后，可以对比计划与执行的偏差，帮助在周报中更早识别风险；任务的前后置依赖和里程碑标记也能让周报里的计划条目有明确来源。周报本身仍是汇总视图，明细在系统中流转，两者配合可以减少每周重复整理信息的工作。
适用边界：哪些情况需要调整
这份示例适用于周期明确、交付物可分解、有固定汇报节奏的综合管理类项目。遇到以下情况需要调整写法。
- 项目类型与阶段差异：探索型或预研型项目在早期难以给出确定的交付物和完成标志，进展条目可以改为记录验证结论和下一步假设；运维类项目以事件和稳定性为主，周报重心可放在问题清单和响应时效上。
- 多团队协作项目：涉及多个团队时，需协调事项会明显增多，建议按团队分组列出，并明确每个团队的对接人和期望时间，避免协调事项混在一起无人认领。
- 进度纠偏与效能指标的归属：周报负责呈现偏差和风险，具体的纠偏方案、资源重新分配属于项目管理动作，应在周会或专项讨论中处理；研发效能指标的设计与统计口径需要单独定义，不宜直接塞进周报条目。
- 示例与真实案例的区别：本文的项目、人名、数据均为虚构，用于说明写法。真实项目填写时应使用实际交付物、实际状态和可核对的数据，健康度结论也应以本项目的事实为依据，不照搬示例中的颜色和判断。
换项目套用时，保留四块结构和状态口径，按项目实际调整条目颗粒度和协调事项的分组方式，就能得到一份读者愿意读、也读得懂的周报。
常见问题
周报里的进展条目要不要写百分比？
百分比只在有明确计算口径时使用。比如“迁移脚本完成 60%”，前提是能说清 60% 对应哪些脚本范围、剩余部分是什么。如果无法界定分母，用“已完成”“进行中”“待测试”这类状态词更可靠。读者关心的是这条进展是否真的结束、还差什么，精确到小数点的百分比反而容易造成误解。
周报和任务系统里的状态对不上怎么办？
先统一状态口径，再谈同步。团队可以在项目启动时约定一套固定状态词，例如已完成、进行中、延期、未开始，周报和任务系统使用同一套词。周报写结论，任务系统存明细，两者出现差异时以任务系统中可核对的工作项为准，并在下一期周报中修正。若差异反复出现，说明状态更新责任没有落到具体人，需要明确谁在什么时间点更新状态。
项目刚启动、交付物还不确定，周报怎么写？
早期阶段可以把进展条目改为记录验证结论和下一步假设，例如“完成三套技术方案对比，结论是方案 B 在扩展性上更符合要求，下周输出详细设计”。计划条目写清下周要验证什么、产出什么文档，完成标志可以是“评审通过”或“方案定稿”。健康度判断依据相应调整为关键假设是否被验证、关键决策是否按期做出，而非交付物完成比例。
多团队协作时，需协调事项怎么组织才不混乱？
按团队分组列出，每条写明对接人、期望提供的输入和需要的时间点。例如“请基础架构组李示例在周三前确认接口开放时间”。分组后读者能快速定位与自己相关的条目，也便于在周会上按团队逐项过。协调事项数量多时，可以在周报中只列本周新增和临近截止的条目，历史条目转到跟踪清单中管理，避免周报越写越长。
健康度颜色由谁定、依据什么定？
健康度通常由项目经理在汇总各条目后给出，依据是可核对的事实：计划交付物的完成比例、风险的数量与等级、协调事项是否在时间窗口内得到回应。写法上先列条目再下结论，并写明颜色变化的条件，例如“若接口确认延迟超过一周，状态调整为红色”。这样读者能理解判断逻辑，也便于下一期周报对照检查条件是否触发。
