交付实施部“8张项目报表”落地方案
0. 已应用到线上
本轮已在“交付实施部-项目管理空间”新增9个可回滚视图，没有删除子表或字段，也没有修改52条项目记录和54条售后记录。
项目管理总表｜6个视图
- PMO｜在手项目：17
- PMO｜管理字段待补：52
- PMO｜需要确认：10
- PMO｜交付阶段未验收：13
- PMO｜已完成未验收：2
- PMO｜初验待终验：2
售后运维台账｜3个视图
- PMO｜售后未填完成时间：11
- PMO｜处理措施待补：6
- PMO｜售后台账字段待补：2
所有视图均启用自动排序、前三列冻结和字段统计；企业微信 CLI 已回读确认筛选和排序配置。
0.1 第一阶段15天交付明细已上线
项目管理总表已增加11个第一阶段字段和3个专用视图，形成“开始日期 → 15天计划日 → 实际完成日 → 当前周期 → 延期天数/程度 → 原因/动作/结论/证据”的完整链路。
字段：第一阶段标准周期（天）、第一阶段计划完成日、第一阶段实际完成日、第一阶段当前周期（天）、第一阶段延期天数、第一阶段延期程度、第一阶段状态、第一阶段延期原因、第一阶段下一动作、第一阶段交付结论、第一阶段证据链接。
当前数据完整性
- 项目总数：52
- 已有开始日期：15
- 缺开始日期：37
- 已完成但缺第一阶段实际日：9
当前暂算状态
- 已逾期待确认：4
- 仍在15天周期内：2
- 暂算严重延期：3
- 暂算轻微延期：1
| 项目 | 开始日期 | 计划完成日 | 暂算延期天数 | 口径 |
|---|---|---|---|---|
| 国信智慧食堂 | 2026-01-23 | 2026-02-07 | 201 | 暂算严重延期 |
| 金斯瑞 | 2026-03-18 | 2026-04-02 | 147 | 暂算严重延期 |
| 中央美院 | 2026-07-31 | 2026-08-15 | 12 | 暂算严重延期 |
| 保康三中 | 2026-08-10 | 2026-08-25 | 2 | 暂算轻微延期 |
以上4个项目均未填第一阶段实际完成日，延期天数按2026-08-27暂算；项目负责人补实际日期后，系统会自动改为正式周期和延期结论。
专用视图：PMO｜第一阶段15天交付明细、PMO｜第一阶段开始日期待补、PMO｜已完成待补第一阶段实际日。
1. 结论
文章的8张报表适合交付实施部，但不应该新建8张需要人工重复填写的表。第一批9个PMO视图和第二批第一阶段15天交付明细已经上线；其余报表必须等任务、容量、验收和复盘事实结构补齐后再生成，不能先做空看板。
现有在线表格已经覆盖了项目总览、项目进度、里程碑和部分项目健康度；延期异常、人员负载、问题闭环和项目复盘仍然偏弱。项目仓库内已有《交付实施部经营与项目管控体系 V1.0》，其底层表设计与文章8张报表高度吻合，应该作为字段和口径设计参考，但不能再形成第二套并行事实源。
2. 证据边界
| 证据 | 等级 | 支撑内容 | 边界 |
|---|---|---|---|
| 2026-08-25 企业微信 CLI 只读核验 | A | 现有项目空间、52条项目、58个项目字段及单项目子表结构 | 本次没有重新读取或修改线上数据 |
| 《交付实施部经营与项目管控体系 V1.0》及字段矩阵 | B/D | 已有项目组合、任务、风险、容量、验收和复用模型 | 管理设计已存在，指标阈值仍需试运行校准 |
| 有道文章《一个项目管理水平高不高，就看这8张报表》 | C | 8类管理问题与报表方法 | 外部营销文章，不构成公司制度或系统事实 |
| 本文落地优先级与节奏 | D | 当前推荐方案 | 需部门负责人、PMO和表格维护人确认 |
3. 现有在线表格基础
已核验的现有结构包括驾驶舱、售前信息采集、项目管理总表、工作排期、售前支撑统计、售后运维台账、项目标签、经营决策看板、个人周报、设备库管和云服务器提醒。
2-项目管理总表 已经具备项目阶段、项目状态、项目完成度、推进状态、本周关键成果、下一交付门槛、最近活动日期、需要确认、验收状态、预期上线日期及多角色负责人等字段；项目名称可跳转到独立项目在线表格。
抽样的单项目表已包含实施计划、项目进展分析、项目采集、软件功能、设备清单和需求池，并已有阶段、任务、交付结果、责任方、状态和里程碑标记。因此问题不是“没有表”，而是跨项目事实没有稳定汇总、部分关键字段没有持续更新、完成和健康状态缺少统一计算口径。
4. 八张报表逐项映射
| 报表 | 要回答的问题 | 现有载体 | 当前判断 | 最小落地动作 | 责任与节奏 |
|---|---|---|---|---|---|
| 1. 项目总览 | 哪些项目正常、关注、延期或暂停 | 驾驶舱、项目管理总表 | 基础较强，但关键管理字段抽样为空 | 固定项目ID、负责人、阶段、承诺/预测日期、健康灯和下一动作 | PMO每日校验，项目负责人周一更新 |
| 2. 项目进度 | 项目和各阶段到底做到哪 | 项目完成度、单项目实施计划与进展分析 | 有状态，缺统一计划/实际/预测口径 | 用有权重且证据合格的任务计算进度，展示四类任务数 | 任务负责人每日，项目负责人周一预测 |
| 3. 里程碑 | 哪些关键节点即将失守 | 下一交付门槛、单项目里程碑标记 | 已有雏形，尚未形成回写闭环 | 记录计划、预测、实际、通过条件、验收人和证据；做未来14天视图 | 节点变化即更新 |
| 4. 延期异常任务 | 今天最值得介入哪些异常 | 单项目实施计划、状态和说明 | 缺跨项目异常视图 | 筛选逾期、临期不足、应开始未启动、长期未更新；补影响和下一动作 | PMO每日查看 |
| 5. 任务负载 | 团队还能否接新项目、谁已超载 | 工作排期表、个人周报 | 难以可靠汇总容量 | 建立人员/周容量：可用、承诺、未完成、本周到期、P0/P1和负荷率 | 周五建立、周一锁定 |
| 6. 问题闭环 | 哪些问题长期未关闭、由谁推进 | 单项目需求池、售后运维台账 | 需求、问题、风险、变更混杂 | 统一类型、严重度、影响、Owner、截止、状态、结论、关闭证据和关联里程碑 | 发现当天登记 |
| 7. 项目健康度 | 哪些项目需要关注或领导决策 | 驾驶舱、项目状态、复杂度、验收状态 | 有看板，缺透明计算口径 | 由进度、关键里程碑、重大问题、资源冲突和客户影响计算 | 系统每日计算，负责人复核 |
| 8. 项目复盘 | 如何避免重复踩坑并沉淀标准能力 | 项目标签、经营决策、周报、售后记录 | 缺正式项目关闭复盘 | 记录周期差、节点变化、重大问题、批准变更、遗留项、复用资产和产品改进 | 关闭后5个工作日 |
5. 不是8张底表，而是6类事实
- 项目主档：一项目一行，保留唯一项目ID、负责人、阶段、承诺与预测。
- 里程碑任务：任务和里程碑共用事实表，通过任务级别和里程碑标记形成不同视图。
- 风险问题变更：统一登记风险、问题、变更和待决策项，但用管理类型与状态严格区分。
- 人员容量：一人一周一行，记录可用、承诺、在制和高优任务。
- 验收回款：记录验收条件、计划/预测/实际、证据、遗留项和回款条件。
- 复盘复用：记录项目经验、复发问题、标准/配置/定制结论和复用资产。
单项目在线表格继续承载现场执行细节；跨项目管理所需的关键事实必须回到统一事实表。项目名称超链接只解决导航，不等于数据已经关联或自动汇总。
6. 四周落地计划
第1周｜项目总览跑真
- 选4个在手项目试点。
- 确认唯一项目ID、负责人和有效链接。
- 补齐承诺/预测、下一里程碑、最近活动和待决策。
- 统一绿黄红定义，暂不用于个人考核。
第2周｜进度、里程碑、异常
- 整理关键任务与里程碑到统一事实表。
- 补计划、预测、实际、完成标准与证据。
- 建立未来14天、逾期、临期和停滞视图。
- 周会只处理异常和决策。
第3周｜容量、问题、验收
- 建立人员/周容量。
- 分类需求、风险、问题、变更和缺陷。
- 增加关闭结论与证据。
- 建立验收清单、遗留项和回款条件。
第4周｜视图与校准
- 从事实生成8个视图。
- 用4个试点项目人工抽样核对。
- 记录一个月基线后再定阈值。
- 通过后扩展到全部在手项目。
7. Use Case：UC-DELIVERY-PMO-001
目标与参与者
主要角色为部门负责人、PMO和项目负责人；次要角色为任务负责人、产品、研发、销售、财务和售后。目标是让管理层不依赖临时询问和人工汇总，即可识别项目状态、关键偏差、资源冲突和待决策事项，并回钻到责任、动作和证据。
主流程
| 步骤 | 行为 | 结果 |
|---|---|---|
| M1 | PMO校验项目主档、项目ID和负责人 | 项目进入唯一组合 |
| M2 | 项目负责人维护基线、预测、阶段和下一里程碑 | 总览具备可预测信息 |
| M3 | 任务负责人更新状态、预测、阻塞和证据 | 进度、里程碑和异常视图更新 |
| M4 | PMO汇总容量、问题、变更和验收 | 负载、闭环和健康度更新 |
| M5 | 系统生成8个管理视图并回钻 | 结论可追溯 |
| M6 | 管理层处理红黄项目、冲突和决策 | 形成责任、截止和结论 |
| M7 | 关闭后复盘并回写模板、产品和知识资产 | 经验可复用 |
分支、异常与恢复
- A1：简单项目保留单项目执行表，只回写关键里程碑和异常。
- A2：复杂项目把全部计划任务纳入统一里程碑任务表。
- E1：链接无效或项目ID缺失时不纳入跨项目统计，修复后重新汇总。
- E2：完成但缺标准或证据时退回“待确认”，不计入真实进度。
- E3：长期未更新时不得继续显示绿色。
- R1：自动汇总失败时保留最后一次已验证结果并显示更新时间。
业务规则
- 8张报表是视图，不是8份人工报表。
- 所有事实使用唯一项目ID关联。
- 进度按有权重且证据合格的结果计算。
- 健康灯必须展示计算原因。
- 每个异常必须有影响、Owner、截止、下一动作和证据。
- 阈值先试运行一个月，再由负责人确认。
- 当前线上空间作为唯一入口，V1.0模板只作字段与口径参考。
验收标准
| 验收标准 | 验证方式 |
|---|---|
| 4个试点项目均有唯一ID、负责人和有效链接 | 逐项目打开核对 |
| 8个视图均能回钻到底层事实 | 每个视图随机抽3条反查 |
| 延期任务视图与原计划一致 | 抽样20条，误报和漏报均为0 |
| 已完成任务均有标准、实际时间和证据 | 缺任一项不得计入完成 |
| 健康灯显示原因、责任人和下一动作 | 逐个红黄项目核对 |
| 人员负荷可解释到具体项目和任务 | 抽样核对承诺与明细 |
| 关闭后5个工作日内形成复盘与改进 | 检查记录与资产链接 |
测试矩阵：字段完整性测试、项目ID唯一性测试、链接有效性测试、任务状态/证据门禁测试、日期边界测试、异常筛选测试、跨表汇总一致性测试、无权限与汇总失败恢复测试。
8. 需要避免的做法
- 新建8张由项目经理每周手工汇总的报表。
- 继续维护多个内容相同但口径不同的项目总表。
- 用完成任务数量计算整体进度，忽略关键任务与证据。
- 由项目负责人凭感觉选择健康灯。
- 用个人周报反推容量，却不记录任务和承诺工时。
- 项目验收后不复盘周期偏差、变更、复发问题和复用资产。
9. 推荐决策
先批准4项目、4周试点，不批准“一次性重建全部在线表格”。试点只做四件事：统一项目ID、统一任务/里程碑事实、统一异常闭环、统一验收与复盘。四类事实稳定后，再生成8个视图并扩展到全部项目。