项目周报面向管理层，读者通常只有几分钟浏览时间，因此结构要服务于快速判断：开头用一段状态摘要给出整体健康度和本期变化，正文按进度、成本、质量、风险四块用目标与实际对照说明偏差，末尾把需要上级拍板的事项单独列出。编写前由项目经理汇总各工作流负责人提交的进展数据，写完后按清单核对口径与结论再发出。下文按这个顺序给出字段、写法、角色分工、填写示例和发出前检查项，适用于项目层面的综合状态汇报。
要点总览（TL;DR）
- 项目周报采用“结论先行”的结构：开头半页状态摘要给出整体健康度和本期变化，正文用进度、成本、质量、风险四块做目标与实际对照，末尾单列管理层待决策事项。
- 四块正文统一按“目标—实际—偏差—原因与影响—下一步动作与责任人”写，数据分别来自任务与里程碑状态、工时与支出记录、缺陷与评审记录、风险跟踪表，并注明统计时间范围。
- 待决策事项只放超出项目经理权限且有明确时间压力的事项，每条写清问题、背景、选项、建议和需要的决定时间，与团队自行跟踪的风险条目分开。
- 角色分工按“工作流负责人提交数据—项目经理汇总撰写—审核人把关口径与结论—发出并归档”四步执行，团队规模小时可合并角色，审核环节建议保留。
- 发出前逐项核对数据口径、偏差解释、待决策事项完整性、摘要与正文一致性，发现数据缺口先向负责人确认，不用估算值填充。
周报先写什么：一页状态摘要的结构
状态摘要承担“让读者在第一屏做出判断”的任务，写法是先给结论，再给依据。摘要控制在半页以内，超过这个长度，读者会直接跳过进入正文，摘要就失去了作用。
摘要建议包含四个字段：
- 整体健康度结论：用“正常 / 需关注 / 高风险”三档之一，并附一句判断依据，例如“进度偏差在可接受范围内，但测试环境交付延迟已影响联调窗口”。
- 本期关键变化：只写与上周相比发生实质变化的事项，例如里程碑完成、范围变更获批、关键人员变动。
- 主要偏差：列出偏差项、偏差幅度和影响对象，不展开原因分析，原因放到正文。
- 下周重点与关注事项：两到三条，指明下周要推进的关键动作和需要持续盯住的风险。
填写示例：“本周整体状态为需关注。核心开发按计划完成 80%，但接口联调因第三方环境未就绪推迟 3 天，可能压缩测试窗口。下周重点为完成联调并确认测试环境交付时间，需关注供应商侧的响应速度。”这段摘要约 100 字，管理层读完即可知道项目在哪、卡在哪、下周看什么。
健康度结论要有判断标准，不能凭感觉。常见做法是预先约定几条规则，例如进度偏差超过 10% 降一档、出现影响里程碑的外部依赖未闭环降一档。规则写进周报模板的说明页，每期按同一口径判断，读者才能横向比较不同周的状态。
进度、成本、质量、风险四块的写法
四块正文是摘要的支撑材料，统一采用“目标—实际—偏差—原因与影响—下一步动作与责任人”的句式，读者可以逐块对照，不必在每块里重新适应写法。
进度
数据来源是各工作流负责人提交的任务完成情况、里程碑状态和计划基线。写法上先写计划值，再写实际值，最后写偏差。例如：“计划本周完成 12 个开发任务，实际完成 9 个，偏差 3 个（25%）。原因是接口文档延迟两天交付，影响下游三个任务。下一步由后端负责人协调文档方在周三前补齐，受影响任务顺延至下周完成。”偏差要写清影响范围，是只影响本工作流，还是波及里程碑。
成本
数据来源是工时记录、采购与外包支出、资源投入情况。写法上对照预算或计划投入与实际发生额，说明偏差方向和金额量级。例如：“本月计划投入 320 人时，实际 356 人时，超支 11%，主要来自联调阶段的加班投入。若下周环境问题解决，预计月末累计偏差可收窄至 5% 以内。”成本数据口径要在周报中注明，例如是否含外包人力、是否按标准工时折算，避免不同周之间数字不可比。
质量
数据来源是缺陷记录、测试通过率、评审结论、返工情况。写法上给出本期新增与关闭数量、遗留缺陷趋势和关键质量问题。例如：“本周新增缺陷 18 个，关闭 21 个，遗留 34 个，其中高优先级 5 个。高优先级缺陷集中在支付模块，已安排专项修复，计划周五前清零。”质量块要避免只报数字，需说明数字背后的趋势和处置安排。
风险
风险条目描述尚未发生但可能影响目标的不确定性，每条写清触发条件、可能影响、应对措施和责任人。例如：“风险：第三方接口稳定性不足，若连续两天出现超时，将影响联调进度。应对：已准备降级方案，由技术负责人评估切换成本。”风险与待决策事项分开，风险是团队自行跟踪和应对的，待决策事项才进入下一节。
四块的数据在编写前应完成汇总。使用 ONES 的团队可以在项目列表中查看项目状态、资源投入和当前进展，设置项目计划和里程碑基线后对比计划与执行的偏差，工时日历与饱和度报表可用于核对资源投入情况，这些数据构成进度与成本两块的输入。数据口径以系统内记录为准，周报中注明统计时间范围。
管理层待决策事项怎么单列
待决策事项是周报中唯一需要读者采取动作的部分，单独成节，放在正文之后、附录之前。识别标准有两条：一是事项超出项目经理权限，必须由上级或跨部门负责人拍板；二是事项有明确的时间压力，拖延会导致偏差扩大。团队内部可以自行处理的问题不进入这一节。
每条待决策事项包含五个字段：
- 问题：一句话说明需要决定什么，例如“是否接受测试周期压缩两天”。
- 背景：两到三句说明来龙去脉和当前状态，引用正文中的数据。
- 选项：列出两到三个可选方案，每个方案写明代价和收益。
- 建议：项目经理给出倾向性意见及理由，便于上级快速判断。
- 需要的决定时间：写明截止日期及原因，例如“需在周四前决定，否则无法调整下周排期”。
待决策事项与风险条目的区别在于：风险描述“可能发生什么”，由团队持续跟踪；待决策事项描述“需要谁在何时选择哪个方案”，必须有明确的决策人和时间点。同一件事可以先作为风险跟踪，当它演变为需要取舍时，再转为待决策事项，并在周报中注明来源。
谁提供数据、谁汇总、谁审核：周报角色分工
周报的质量取决于数据提交是否及时、口径是否统一。角色分工按四步设置，团队规模小时可以合并角色，审核环节建议保留。
| 角色 | 动作 | 交付物 | 时点 |
|---|---|---|---|
| 工作流负责人 | 整理本工作流本周任务完成情况、偏差、风险和质量数据 | 进展数据条目，含目标、实际、偏差原因 | 每周固定截止时间前提交，例如周四下班前 |
| 项目经理 | 汇总各工作流数据，判断整体健康度，撰写摘要与正文，整理待决策事项 | 周报初稿 | 数据截止后半个工作日内完成 |
| 审核人 | 核对数据口径、时间范围、偏差解释和结论一致性 | 审核意见或确认发出的周报 | 初稿完成后当天 |
| 项目经理 | 按确认版本发出，并归档到项目文档库 | 已发出的周报及归档记录 | 固定发送日，例如周五上午 |
工作流负责人提交的内容要有固定格式，避免每人写法不同导致汇总困难。可以约定每条进展包含任务名称、计划完成时间、实际状态、偏差说明四个字段。项目经理汇总时重点做两件事：统一口径，例如工时是否含加班、缺陷是否含已关闭；判断健康度，对照预设规则给出结论。审核人通常由项目发起人或 PMO 担任，把关的是结论与数据是否矛盾、待决策事项是否完整可执行，不代替项目经理改写内容。
数据汇总环节可以借助工具减少手工整理。ONES 支持从项目到任务的多层级管理，实现自下而上的进度反馈和自上而下的进度监控，各工作流负责人在系统中更新任务状态后，项目经理可在项目列表查看整体进展，结合基线对比识别偏差；效能管理可自动收录系统内流转的研发数据并形成分析指标，预置的仪表盘模板可供项目经理视角直接使用，仪表盘还支持共享给其他角色并配置读写权限。周报正文仍由项目经理撰写，工具承担的是数据汇集和状态呈现。
一份填写示例：从数据到周报段落
以下示例为演示情景，数据为虚构，用于说明写法。
背景与输入数据：某系统升级项目，本期为第 8 周。计划完成 15 个开发任务，实际完成 11 个；计划投入 280 人时，实际 302 人时；新增缺陷 12 个，关闭 15 个，遗留 28 个，高优先级 3 个；第三方支付接口联调因对方环境未就绪推迟 4 天。
状态摘要写法：“本周整体状态为需关注。开发任务完成 11/15，偏差主要来自支付接口联调推迟 4 天；工时超支 8%，缺陷遗留数持续下降。下周重点为完成联调并启动集成测试，需关注第三方环境交付时间，相关取舍见待决策事项第 1 条。”
四块正文写法：进度块写“计划完成 15 个开发任务，实际完成 11 个，偏差 4 个（27%）。其中 3 个任务因支付接口联调推迟受阻，1 个任务因需求澄清延迟。下一步由开发负责人跟进联调排期，需求澄清由产品负责人周三前闭环。”成本块写“计划投入 280 人时，实际 302 人时，超支 8%，主要来自联调等待期间的重复验证。若下周联调完成，预计累计偏差收窄至 4%。”质量块写“新增缺陷 12 个，关闭 15 个，遗留 28 个，高优先级 3 个，集中在支付模块，已安排专项修复。”风险块写“风险：第三方环境若下周仍未就绪，集成测试窗口将被压缩。应对：已准备模拟环境先行验证，由测试负责人评估覆盖度。”
待决策事项写法：“问题：是否接受集成测试周期由 10 天压缩至 7 天。背景：联调推迟 4 天，按原计划测试窗口不足。选项一，压缩测试周期，风险为覆盖度下降；选项二，顺延上线日期 3 天，影响对外承诺。建议选择选项二，理由是支付模块缺陷密度较高，压缩测试的返工风险更大。需在周四前决定，以便调整发布计划。”
发出前的完成检查
周报发出前逐项核对以下清单，全部通过再发送。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 数据口径与时间范围 | 各块数据是否来自同一统计周期，工时、缺陷、成本口径是否与上期一致 | 周报中注明统计起止时间，口径变化有说明 |
| 偏差均有原因和动作 | 每条偏差是否写了原因、影响范围和下一步动作及责任人 | 无只报数字不解释的条目 |
| 待决策事项完整可执行 | 每条是否含问题、选项、建议和决定时间，决策人是否明确 | 读者读完知道要做什么决定、何时决定 |
| 结论与正文一致 | 摘要中的健康度和关键偏差是否能在正文找到对应数据 | 摘要不出现正文未支撑的判断 |
| 风险与待决策分开 | 团队自行跟踪的事项是否误列入待决策，需上级拍板的是否遗漏 | 两类条目边界清晰 |
| 长度与格式 | 摘要是否在半页以内，正文四块是否齐全，待决策事项是否单独成节 | 结构完整，无缺块 |
检查中发现数据缺口时，先向对应工作流负责人确认再补写，不用估算值填充。审核人确认后的版本即为发出版本，归档时保留本期数据来源和审核记录，便于后续追溯和跨周对比。
常见问题
周报里的健康度结论怎么定，才能让不同周之间可比？
健康度结论需要预先约定判断规则，而不是每期凭感觉给。常见做法是在周报模板说明页写几条降档条件，例如进度偏差超过 10% 降一档、出现影响里程碑的外部依赖未闭环降一档、高优先级缺陷连续两周未清零降一档。每期按同一套规则判断，读者才能横向比较不同周的状态。
规则本身可以随项目阶段调整，但调整要在周报中注明生效时间，避免前后口径混用。摘要里的健康度结论还要附一句判断依据，让读者知道是哪条规则触发了降档。
工作流负责人提交的数据格式不统一，汇总时怎么处理？
先约定最小字段集，再要求按格式提交。可以规定每条进展必须包含任务名称、计划完成时间、实际状态、偏差说明四项，缺项退回补充。项目经理汇总时先做口径统一，例如工时是否含加班、缺陷是否含已关闭、成本是否含外包人力，把口径写进周报的统计说明。
如果某位负责人连续几期提交质量不稳定，可以在角色分工表里明确提交截止时间和退回机制，把数据质量纳入周报流程的固定环节，而不是每次临时沟通。
风险条目和待决策事项容易混在一起，边界怎么划？
风险描述尚未发生的不确定性，由团队持续跟踪和应对，条目里写触发条件、可能影响、应对措施和责任人。待决策事项描述需要上级或跨部门负责人在某个时间点做出选择的事项，条目里写问题、背景、选项、建议和需要的决定时间。
同一件事可以先作为风险跟踪，当它演变为需要取舍、且超出项目经理权限时，再转为待决策事项，并在周报中注明来源。检查时看两条：团队能否自行处理，是否有明确的时间压力，两条都指向上级动作的才进入待决策节。
项目数据分散在多个系统里，周报汇总有没有省力的做法？
思路是让日常流转的数据先沉淀到同一处，再从中取数。ONES 支持从项目到任务的多层级管理，实现自下而上的进度反馈和自上而下的进度监控；设置项目计划和里程碑基线后，可在项目列表对比计划与执行的偏差。工时日历与饱和度报表可用于核对资源投入，效能管理可自动收录系统内流转的研发数据并形成分析指标，预置仪表盘模板支持共享给其他角色并配置读写权限。
工具承担的是数据汇集和状态呈现，周报正文的判断和撰写仍由项目经理完成。具体能力范围以团队实际配置和版本为准。
周报篇幅多长合适，内容多的时候要不要都写进去？
摘要控制在半页以内，正文四块齐全即可，待决策事项单独成节。内容多的时候优先保留与目标偏差相关的事项，把过程性细节放到附录或项目文档库，正文只写影响判断的信息。
判断标准是读者能否在几分钟内知道项目在哪、卡在哪、需要他做什么。与本周目标无关的进展、已经闭环且无后续影响的事项，可以合并成一句带过，不必逐条展开。
