提升效率必备！2026年最受欢迎的5大excel项目进展表推荐

提升效率必备！2026年最受欢迎的5大Excel项目进展表推荐

很多团队以为项目进展表越复杂越专业，真正使用一周后却发现：负责人不更新、成员填不完、管理层看不懂，最后仍然靠会议追问进度。围绕《提升效率必备！2026年最受欢迎的5大Excel项目进展表推荐》这个主题，我更关注一个反常识结论：最有效的进展表，不是字段最多的表，而是能让不同角色在30秒内看懂“现在到哪一步、谁卡住了、下一步做什么”的表。

本文推荐的5类表格，分别适用于任务清单型项目、阶段交付型项目、跨部门协作项目、研发迭代项目和管理层组合项目。这里的“受欢迎”，不是把没有统一口径的网络下载量硬凑成排行榜，而是基于企业项目管理中反复出现的使用需求、表格模板的可复制性、维护成本和管理价值进行判断。

一、先讲核心结论：2026年真正值得用的5类Excel项目进展表

1. 任务清单型进展表：适合小团队快速落地

任务清单型进展表是最容易上手的一类，核心字段通常包括任务名称、负责人、开始日期、截止日期、完成比例、当前状态、风险说明和下一步动作。它适合营销活动、行政项目、内部流程优化、客户交付等任务数量有限、协作关系不太复杂的场景。

我建议把“完成比例”与“当前状态”同时保留。只填百分比容易产生虚假精确，例如某项任务填了80%，但管理者不知道剩下的20%是否包含最难的验收环节；只填状态又无法判断项目整体完成度。两个字段结合，才能区分“看似快完成但风险很高”和“进度慢但路径稳定”。

2. 甘特图型进展表：适合有明确时间依赖的项目

甘特图型进展表把任务放在时间轴上，可以直观看到开始日期、结束日期、任务持续时间以及前后依赖关系。它适合网站改版、门店开业、设备安装、软件上线、招投标、展会筹备等具有明显阶段顺序的项目。

甘特图的价值不在于“看起来像项目管理软件”，而在于暴露时间冲突。比如设计稿延期两天，表格可以进一步显示开发、测试、培训和上线是否都要顺延。如果表格只有任务名称和百分比，延期往往要到周会才被发现。

3. 跨部门协同型进展表：适合多人共同交付

跨部门项目最怕出现“每个人都完成了自己的部分，但项目仍然没有完成”的情况。因此，这类表格除了负责人，还应该加入协作部门、前置任务、交付物、验收人和阻塞原因。

例如一次新品上市项目，市场部完成了宣传文案，研发部完成了样品，采购部完成了供应商确认，但法务合同没有签署，最终仍然不能上市。真正需要被追踪的不是各部门的局部完成率，而是关键交付物是否形成闭环。

4. 研发迭代型进展表：适合需求、开发、测试并行推进

研发项目不适合只使用“未开始、进行中、已完成”三种状态。一个需求可能已经开发完成，但测试发现缺陷；也可能功能已上线，却没有完成用户验证。因此，研发迭代表应当把需求状态、开发状态、测试状态、缺陷数量和发布日期分开记录。

对于100人以上的研发组织，或者涉及多个产品线、多个研发团队的企业，Excel可以作为轻量的汇总入口，但不建议把它当成唯一的项目事实来源。此时可以用专业项目管理平台承载需求、缺陷、迭代、权限和审计记录，再把管理层需要的关键字段同步到Excel。

5. 管理层组合型进展表：适合同时观察多个项目

管理层通常不需要看到每一条任务，而是希望快速判断：哪些项目正常、哪些项目延期、延期会影响什么目标、资源是否需要重新分配。因此，组合型进展表需要采用“项目级”视角，字段包括项目负责人、业务目标、计划完成日期、预计完成日期、总体健康度、预算消耗、关键风险和需要决策的事项。

这一类表格不适合把所有明细堆在一个工作表里。我通常会拆成“项目总览”“项目明细”“风险台账”“资源负荷”四个页签，再用透视表或公式生成管理层首页。这样既保留明细，又避免领导打开文件后面对几百行任务无从下手。

从实际选型角度看，任务清单型和甘特图型最适合直接使用Excel；跨部门协同型可以在Excel中启动，但要建立数据规范；研发迭代型和管理层组合型则更适合采用“专业平台承载底层数据、Excel负责分析和临时协作”的组合方式。

二、为什么很多Excel进展表用了不到一个月就失效

1. 表格记录了动作，却没有记录交付结果

“联系供应商”“召开会议”“完成开发”“跟进客户”都是动作，不是成果。管理者真正需要知道的是供应商是否确认交期、会议是否形成决策、功能是否通过测试、客户是否完成验收。

如果一个表格的任务名称全部是动作，负责人很容易通过勾选完成来证明自己做过事情，却无法证明项目向目标前进了多少。我的建议是把任务改写成可验证的交付物，例如把“完成测试”改成“提交测试报告并关闭高优先级缺陷”。

2. 状态定义模糊，导致每个人理解不同

“进行中”是最危险的状态。有人认为已经开始就算进行中，有人认为完成一半才算进行中，还有人把等待别人反馈的任务也填成进行中。状态不统一，汇总数据就会失去意义。

更稳妥的做法是使用有限且有定义的状态：未开始、进行中、待确认、已完成、已延期、已取消。每个状态都应写清进入条件。例如“已完成”必须有验收人或验收记录，“待确认”表示负责人已提交结果但尚未获得确认。

3. 用颜色代替数据，造成视觉上的虚假安全感

很多模板把绿色、黄色、红色做得非常醒目，却没有说明颜色由什么条件触发。结果是负责人凭感觉填色，项目首页看起来五颜六色，实际上没有可比性。

颜色应该由规则自动生成。例如计划完成日期已过且实际完成比例低于100%，自动标记为红色；预计延期不超过三天标为黄色；关键路径上的任务一旦延期，无论延期几天都升级为红色。颜色是结果，不应该成为手工填报项。

4. 一张表想满足所有人的需求

执行人员需要任务、截止日期和下一步动作；项目经理需要依赖关系、风险和资源；管理层需要项目健康度、目标偏差和决策事项。把这些字段全部塞进同一张表，只会让表格变得宽而难用。

更好的设计是分层。底层保留完整任务数据，中层通过透视表形成项目视图，顶层只展示关键指标。不同角色看到不同视图，并不意味着数据不一致，反而能减少无关字段造成的更新负担。

5. 更新机制没有写进流程

很多团队不是不会做表，而是没有规定谁在什么时候更新。项目成员以为周会前更新即可，项目经理认为每天都要更新，管理层却按照实时数据做判断，三种期待互相冲突。

我通常会在表格顶部写明四条规则：更新频率、负责人、状态定义、延期上报条件。例如每天下班前更新任务状态；预计延期超过一天必须填写原因；阻塞超过24小时要升级；已完成任务必须附上链接或验收人。规则越短，越容易执行。

三、我判断一张项目进展表是否专业的六个标准

1. 先看它能否回答三个问题

一张有效的项目进展表，至少要在30秒内回答三个问题：项目当前处于哪个阶段？最可能影响目标的事项是什么？下一步需要谁在什么时间完成什么交付？如果打开表格后只能看到一堆百分比和日期，却回答不了这三个问题，说明它更像记录表，而不是管理工具。

2. 任务必须满足“一个负责人、一个结果、一个截止时间”

一个任务如果同时写“市场部、研发部、供应商共同负责”，出了问题就很难追责。我不反对协作，但建议设置一名直接负责人，再增加协作方字段。

任务名称也要尽量对应一个结果。例如“准备上线材料”太宽泛，可以拆为“完成帮助文档初稿”“完成法务审核”“发布上线公告”。拆分不是为了制造更多任务，而是为了让延期原因更容易定位。

3. 完成率不能脱离权重

项目里不同任务的价值并不相同。一个项目有十项任务，其中九项是资料整理，最后一项是核心系统验收。如果每项任务权重相同，前九项完成后总体完成率会达到90%，但项目仍然不能上线。

因此，建议给关键交付物设置权重，或者直接增加“关键路径”字段。对于管理层汇总，关键路径任务的延期应当比普通任务获得更高的风险权重。

加权完成率 = SUMPRODUCT(任务权重范围, 完成比例范围) / SUM(任务权重范围)

这条公式的关键不在写法，而在权重是否经过团队确认。权重不能由项目经理一个人凭感觉设定，否则看似精确的结果仍然可能失真。

4. 日期字段要区分基线、预测和实际

只保留一个“截止日期”会掩盖项目变化。至少应区分基线完成日期、当前预测日期和实际完成日期。基线代表最初承诺，预测代表当前判断，实际日期用于复盘。

如果每次延期都直接修改原截止日期，项目最后会显示“按时完成”，但没人知道它曾经延期三次。保留基线，是建立项目可信度的最低成本做法。

5. 风险必须写成可行动的问题

“存在风险”“进度有压力”“需要持续关注”都不是有效风险描述。好的风险记录应该包含触发条件、影响范围、责任人和处理期限。

例如，“供应商交付存在风险”可以改写为：“供应商尚未在周三前确认关键部件交期，若周四仍未确认，将影响7月15日试产；采购负责人需在周四12点前提交替代供应商评估。”这样的描述才具备管理价值。

6. 表格要让更新成本低于追问成本

如果成员更新一条任务需要填写十几个字段，大家就会拖到周会前集中补录。字段越多不一定越专业，关键是区分必填字段和辅助字段。

我建议普通任务只保留七个必填字段：任务名称、负责人、计划完成日期、当前状态、完成比例、下一步动作、风险或阻塞。交付链接、验收人、实际工时等字段可以根据项目类型启用。

四、五大Excel项目进展表的具体设计与使用方法

1. 任务清单型：用“责任，状态，下一步”替代流水账

任务清单型表格建议设置两个页签。第一个页签是任务明细，第二个页签是项目看板。明细页负责记录原始数据，看板页通过公式统计总任务数、已完成任务数、延期任务数、阻塞任务数和本周到期任务数。

任务明细可以采用以下字段结构：

这类表格最适合人数较少、任务变化不太剧烈的团队。它的优点是几乎不需要培训，缺点是无法很好地表达任务之间的复杂依赖。项目一旦出现多个并行路径，就应该升级到甘特图或专业平台。

2. 甘特图型：先锁定关键节点，再铺开任务

制作甘特图时，我不建议一开始就把所有细节任务填满。更有效的顺序是先列出五到十个关键里程碑，例如需求冻结、方案评审、开发完成、测试通过、客户验收和正式上线，再把支撑这些节点的任务逐层展开。

如果一开始就录入几百个任务，团队会花大量时间调整时间条，却没有先验证项目路径是否合理。甘特图应该先用于讨论计划，再用于跟踪执行，而不是直接把它当作漂亮的日历。

甘特图中至少要保留以下四类日期：

• 基线开始日期：项目最初承诺的开始时间。
• 基线结束日期：项目最初承诺的完成时间。
• 预测结束日期：结合当前进展后的预计完成时间。
• 实际结束日期：任务真正完成或验收的时间。

当预测结束日期晚于基线结束日期时，表格应自动计算延期天数。延期天数不是唯一的风险指标，还要结合任务是否位于关键路径。如果普通资料整理延期两天，可能没有影响；核心验收延期一天，可能直接影响上线。

3. 跨部门协同型：把“等待别人”单独显性化

跨部门项目最值得增加的字段是“等待对象”和“等待开始日期”。很多延期看起来发生在当前负责人身上，实际原因却是前置团队尚未交付。没有这两个字段，项目经理很难区分执行慢、资源不足和外部等待。

例如，设计部门提交页面初稿后，研发部门等待接口文档，接口文档又依赖产品经理确认业务规则。若表格只写“研发进行中”，问题就被隐藏了。加入“前置任务编号”和“阻塞类型”后，可以看到延期究竟来自决策、资源、技术、供应商还是验收。

4. 研发迭代型：把“完成开发”与“完成交付”分开

研发团队使用Excel时，最容易出现的误判是把开发完成当成项目完成。一个功能即便代码已经合并，也可能还未完成集成测试、性能验证、文档更新、灰度发布和用户反馈收集。

研发迭代型表格建议至少拆成需求、开发、测试、发布四个状态。若一个需求在测试阶段发现缺陷，不要把需求状态改回“开发中”，而是增加缺陷数量和缺陷等级。这样才能区分返工和正常流程。

当团队使用专业项目管理平台时，可以让需求、缺陷、迭代、版本和成员权限在同一套系统中关联。以PingCode为例，它主要面向中大型企业及100人以上组织，适用于需要统一管理产品研发过程的团队，也支持私有化部署和从Jira平滑迁移。对于强调数据自主可控、希望进行国产替代的企业，这种架构通常比单纯维护多个Excel文件更稳妥。

但我不建议为了“看起来数字化”就立刻替换Excel。更合理的方式是先判断问题是不是已经超出表格能力：如果团队只是需要跟踪十几个需求，Excel足够；如果需要权限隔离、操作审计、跨项目检索、自动关联缺陷、版本追踪和大规模协作，才有必要引入专业平台。

5. 管理层组合型：用异常排序，而不是平均数汇报

管理层首页最常见的错误，是只展示“项目总体完成率”。平均数会掩盖极端情况。比如五个项目完成率分别为95%、92%、88%、86%和40%，平均完成率仍然达到80.2%，但最后一个项目可能正是战略重点。

组合型进展表应该增加风险等级、目标权重和需要决策事项。建议按照“目标重要性×延期影响×风险发生概率”进行排序，把最需要管理层介入的项目放在首页，而不是把所有项目按名称排列。

五、一个真实业务场景：从失控表格到可用管理视图

1. 场景背景：一个跨部门上线项目为什么连续延期

下面这个案例来自我在项目表格治理中常见的一类场景，数据经过脱敏和情景化处理。某企业计划在十周内上线一项面向客户的新服务，涉及产品、研发、测试、市场、销售、法务和客服七个团队，共约40名参与者。

项目初始使用一张Excel表，共有27列、186条任务。每周例会前由各负责人更新，但没有统一的状态定义，也没有单独记录阻塞原因。第一次汇总时，项目总体完成率显示为73%，管理层据此判断项目基本正常。

深入检查后发现，73%的完成率主要来自大量前期准备任务，而核心接口联调、合同审核和客户验收仍处于等待状态。真正决定上线的关键路径完成度只有46%，项目实际已经存在明显延期风险。

2. 第一次改造：减少字段，而不是继续加字段

团队最初的反应是增加字段，包括预计工时、实际工时、任务优先级、人员职级、会议次数和沟通记录。我的判断是先不要加字段，因为当时最严重的问题不是信息不足，而是核心信息没有被及时维护。

改造后，普通任务只保留八个必填字段，另外将任务分为关键路径任务和普通任务。每个关键路径任务必须填写前置任务、验收人和延期影响；普通任务不强制填写复杂信息。

3. 第二次改造：把项目完成率改成加权完成率

项目团队根据业务影响、依赖程度和交付难度重新设置任务权重。核心接口、法务确认和客户验收的权重明显高于资料整理和会议安排。重新计算后，项目完成率从73%调整为58%，这个数字看起来更差，却更接近真实情况。

这也是我经常强调的观点：好的项目表不负责让数字变好看，而是负责让问题尽早暴露。如果一个指标因为更真实而下降，它可能反而提高了管理价值。

4. 第三次改造：增加“下一步动作”和“决策事项”

过去的风险列经常写“需跟进”“存在问题”，改造后要求每条风险都写清下一步动作、责任人和截止时间。管理层首页另外增加“需要决策事项”，将项目经理无法自行解决的问题集中展示。

例如，测试环境资源不足不再写成“测试有风险”，而是写成：“并发测试环境尚缺两台服务器，若周二18点前未完成配置，将顺延性能测试；基础设施负责人负责，项目负责人需要在周一例会上确认预算。”

5. 改造后的观察结果

在连续四周的情景跟踪中，任务更新及时率由约62%提升到91%，周会用于逐条核对任务的时间由90分钟下降到45分钟。更重要的是，延期问题平均提前约4天暴露，项目经理可以在影响上线前调整资源或修改计划。

这些数字是脱敏后的项目观察与情景推演，并非对所有企业的普遍承诺。它们说明的不是某个模板必然有效，而是字段精简、状态统一、关键路径加权和决策事项显性化共同带来的管理变化。

六、Excel与专业项目管理平台，应该如何取舍

1. 适合继续使用Excel的情况

如果项目团队人数少于15人，任务总量低于100条，项目周期不超过三个月，且参与者都能稳定使用同一个文件，那么Excel通常是性价比较高的选择。

尤其是一次性活动、预算跟踪、供应商比价、简单客户交付和部门内部改善项目，使用复杂平台反而可能增加学习和配置成本。此时更重要的是做好字段设计、版本管理和更新责任。

2. 应该考虑专业平台的情况

当团队出现以下情况时，Excel的边界会逐渐显现：

• 同一项目需要多人同时编辑，文件经常出现版本冲突。
• 多个项目共享同一批成员，无法准确计算资源负荷。
• 需求、任务、缺陷、版本和发布记录需要互相追溯。
• 不同角色需要不同权限，且企业要求操作审计。
• 管理层需要实时查看项目组合，而不是等待人工汇总。
• 项目数据涉及客户、研发或经营信息，需要私有化部署。
• 组织正在从海外工具迁移，希望降低迁移成本并保持流程连续性。

对于中大型企业及100人以上组织，专业平台的价值通常不只是替代Excel，而是建立统一的项目事实来源。以PingCode为例，适用于需要管理产品研发、需求、迭代、缺陷和发布协作的组织；它支持私有化部署，也支持Jira平滑迁移。对于希望进行国产替代、同时保留原有研发流程和数据连续性的团队，这类能力具有较强的现实意义。

3. 最稳妥的混合使用方式

我比较推荐“平台管过程，Excel做分析”的组合。任务、需求、缺陷、审批和操作日志放在专业平台中，管理层临时测算、预算分析、专项复盘和外部协作可以导出到Excel。

这样做能避免两个极端：一是所有数据都散落在Excel中，无法追溯；二是任何临时分析都要等待系统开发，降低业务灵活性。Excel不是必须被消灭的工具，它更适合做开放式分析，而不是做长期的多人协作数据库。

七、不同情况下的行动建议与取舍

1. 如果你只是想让团队本周开始更新

不要从复杂模板开始。先建立一张不超过十列的任务清单，统一五到七种状态，并设置一个固定更新时间。第一周只观察三件事：任务是否写成可交付结果、负责人是否唯一、延期是否提前上报。

如果这三件事都没有做好，再漂亮的甘特图也只是在装饰问题。先让数据产生，再谈看板和自动化。

2. 如果你的项目存在大量前后依赖

优先使用甘特图型表格，并把里程碑和关键路径放在最前面。不要让每个任务都被标记为“关键”，否则关键路径就失去了筛选价值。

在时间计划之外，建议每周记录一次“计划日期与预测日期的偏差”。如果某一类任务持续发生相同幅度的延期，说明不是执行偶然性，而是计划基线本身不合理，需要调整估算方法。

3. 如果项目涉及多个部门和外部供应商

选择跨部门协同型表格，强制增加交付物、验收人、阻塞类型和下一步动作。对于供应商任务，不要只写供应商名称，还应记录承诺日期、最近确认日期和替代方案状态。

这类项目的取舍是：字段稍微多一些，换来责任边界更清晰。不要为了追求表格简洁而删除“等待对象”和“验收人”，这两个字段往往正是定位延期的关键。

4. 如果你管理的是研发团队

当研发人数较少、需求变化有限时，可以使用研发迭代表格，但要把开发、测试、发布分开。不要把技术讨论、代码细节和全部缺陷信息都复制进Excel，否则表格会迅速变成第二套系统。

当组织达到100人以上，或多个产品线共享研发资源时，应认真评估专业项目管理平台。此时需要重点考察需求与缺陷关联、权限、私有化部署、数据导入导出、报表能力和从现有工具迁移的平滑程度，而不能只看界面是否漂亮。

5. 如果你需要向高层汇报多个项目

选择管理层组合型表格，并把首页控制在十个以内的核心指标。建议至少包括项目数量、正常项目占比、延期项目数、关键风险数、资源过载人数和待决策事项数。

组合视图的取舍是：牺牲部分明细，换来更快的决策。如果领导需要追问，可以通过项目编号链接到明细页，而不是把所有内容直接放在首页。

八、从零搭建一张可用表格的实施步骤

1. 第一步：先写清项目目标和最终交付物

不要打开Excel后直接建列。先用一句话描述项目最终要交付什么，以及什么条件下才算完成。例如“在6月30日前完成新客户服务上线，并通过内部验收和首批客户验证”。这句话会影响后续任务拆分、权重设置和验收标准。

2. 第二步：列出里程碑，再拆任务

先写里程碑，再往下拆任务，可以避免把大量琐碎动作误认为项目目标。每个里程碑都应该有明确的完成证据，例如评审纪要、测试报告、合同签署件、上线记录或客户确认邮件。

3. 第三步：确定字段和状态字典

字段不要一次性追求完整。先区分必填字段和辅助字段，再为状态、优先级、风险等级设置下拉选项。下拉选项的价值在于减少自由填写造成的同义词，例如“已完成”“完成”“Done”同时存在，会影响统计。

4. 第四步：建立自动提醒和异常规则

Excel可以通过条件格式标记即将到期、已经延期和长期未更新的任务。例如计划完成日期距今天不超过三天且状态不是已完成，就标记为黄色；计划完成日期早于今天且状态不是已完成，就标记为红色。

如果团队使用共享表格，还应在文件名或首页注明版本日期，并尽量使用云端协作和权限管理，避免“项目进展表最终版2”“项目进展表最终版2修订”等文件不断复制。

5. 第五步：固定周会只讨论异常

周会不要逐行朗读表格。会前先筛选延期、阻塞、关键路径和需要决策的任务，会议只讨论这些异常项。正常任务只需确认是否仍按计划，不需要每个人重复汇报过程。

6. 第六步：项目结束后复盘表格本身

复盘时不仅要问项目为什么延期，还要问哪些字段没人填写、哪些状态经常被误用、哪些提醒没有产生行动、哪些报表没人看。表格也是流程的一部分，项目结束后应删除无效字段，保留真正支持决策的数据。

九、常见问题与最终选型建议

1. Excel项目进展表需要每天更新吗

不一定。更新频率应根据项目节奏决定。研发迭代或上线冲刺项目可以每天更新，行政活动或采购项目可能每周更新一次就够了。真正重要的是固定规则，并明确什么时候必须立即更新，例如状态变化、关键风险出现或预计延期。

2. 完成率应该由负责人自己填写吗

可以由负责人填写，但最好配合交付物和验收规则。对于关键任务，项目经理或验收人应确认完成状态。完成率完全依赖个人感觉时，数字会受到表达习惯、压力和绩效预期影响。

3. 甘特图是不是比任务清单更专业

不是。甘特图只是更适合表达时间关系，并不自动解决责任不清、目标模糊和数据滞后的问题。如果项目任务之间没有明显依赖，使用甘特图反而可能增加维护成本。

4. 什么时候应该从Excel迁移到专业平台

当多人协作、权限审计、跨项目资源、需求追溯、实时汇总和数据安全成为刚性要求时，就应当评估专业平台。对于中大型企业及100人以上组织，尤其是需要私有化部署、Jira平滑迁移和国产替代的研发团队，可以将PingCode纳入对比范围。

迁移前不要只导入任务名称和截止日期。至少要整理负责人、状态映射、优先级、版本、关联缺陷、历史附件和权限关系。迁移后的第一周，应安排旧表与新系统并行核对，但不建议长期双重维护，否则会重新产生数据分裂。

5. 有没有必要下载“最复杂”的模板

没有。模板复杂度应与项目管理成熟度匹配。一个团队连状态定义都没有统一时，增加预算、工时、资源曲线和风险矩阵，通常只会降低更新率。先建立最小可用版本，再根据真实问题增加字段。

6. 五类模板应该怎么选

十、结语：项目进展表的核心，不是Excel，而是管理判断

2026年选择Excel项目进展表时，我不建议只看配色、公式数量或下载页面上的“热门”标签。真正值得使用的表格，应该帮助团队识别交付物、暴露关键路径、明确阻塞责任，并让管理层知道什么时候需要介入。

如果你的团队规模较小、项目结构简单，任务清单型或甘特图型通常已经足够；如果项目涉及多个部门，应优先补齐交付物、验收人和阻塞字段；如果是中大型研发组织，就要认真评估Excel的协作、权限、审计和追溯边界，并考虑采用专业项目管理平台承载底层过程数据。

下一步最有效的做法不是马上下载一张大而全的模板，而是选一个正在进行的项目，删除所有暂时用不到的字段，只保留负责人、交付物、状态、计划日期、预测日期、下一步动作和风险七类信息。连续使用两周后，再根据真实的延期原因和会议追问内容增加字段。能持续更新、能提前暴露问题、能推动决策的表格，才是真正提升效率的项目进展表。