周进展落地方案：项目经理开展进度跟踪的入门指南案例解析

我第一次意识到“周进展跟踪”可能是项目管理里最被低估的一项基本功，是在一个跨部门项目上。那个项目第 6 周被判定为严重延期，关键路径整整滑了 11 天，但翻回去看前三周的周报，所有任务状态都写着“进行中”，没有一条红灯，没有一条阻塞被记录。问题不在于团队不努力，而在于我把“收集进度”当成了“跟踪进度”。这篇文章我想把这几年自己踩过的坑、改过的字段、开废过的周会，拆成一套项目经理可以直接照做的周进展落地方案：状态字典怎么定、周会议程怎么排、行动项怎么闭环、风险什么时候升级，以及一个四周把“流水账周会”改成决策会的完整案例。

一、先把结论摊开：周进展跟踪是决策闭环，不是汇报动作

我见过太多团队把“周进展”等同于“写周报”。周报写完发出去，项目经理读一遍，心里大概有数，然后该延期的继续延期。这套流程之所以失效，是因为它只完成了信息搬运，没有完成信息加工和决策转化。

1. 结论一：跟踪的对象是偏差，不是进度

“任务 A 进行中”这句话本身不包含任何可执行信息。真正值得被记录的是偏差：原计划周三完成，现在还在等第三方接口，预计推迟两天。偏差才需要决策，进度只需要存档。

所以周进展的第一个动作，不是问“做到哪了”，而是问“和你上周承诺的相比，哪里不一样了”。这个问法上的小改动，会让收集到的信息质量产生数量级的差别。

2. 结论二：状态口径不统一，换什么工具都救不了

我在一个项目里做过一次抽样核对：让三位成员分别描述同一个任务的当前状态，得到的回答是“基本做完了”“还差联调”“卡在测试环境”。这三种描述在管理含义上完全不同，一个是 90%，一个是 70%，一个是 0% 但被外部阻塞。

当口径不统一时，任何看板、甘特图、燃尽图都只是在把模糊信息可视化得更漂亮一点。状态字典的优先级，永远高于工具的选型。

3. 结论三：周进展的产出不是一份文档，而是四类可执行对象

我要求团队的周进展必须产出四样东西：当前状态（含偏差）、需要拍板的事项、下周的承诺、需要向上要的资源。没有这四样，周会就默认是失败的，不管开了多久。

4. 一套最小可用的周节奏

落地不需要复杂机制，一条时间线就够：周一上午发收集表，周三中午截止，周三下午项目经理做偏差清洗，周四上午开 45 分钟周会，周四下午发出行动项和向上同步的一页纸，下周一复盘上周行动项关闭率。

我实测过这个节奏在 8 到 30 人项目上的可行性：整个流程里项目经理的净投入大约是每周 3.5 小时，其中收集表催办 0.5 小时、偏差清洗 1 小时、周会 0.75 小时、行动项跟踪 0.75 小时、向上同步 0.5 小时。这个投入量是可以长期维持的，而“每天站会 + 每周两小时周会 + 随时问进度”的组合，通常在第三周就会因为疲劳而崩掉。

二、真实场景复盘：一个跨部门项目怎么连续三周“进展正常”却延期了

为了让后面的方法不至于变成空谈，我先把那个延期 11 天的项目完整讲一遍。它是这篇文章所有方法论的来源，也是我后来所有模板的验证场景。

1. 背景：四个部门、两个外部供应商、一条关键路径

项目规模不算大，内部涉及业务、研发、测试、运维四个部门，外部有两个供应商分别负责数据接口和短信通道。总工期 14 周，关键路径上有 9 个任务，其中 3 个依赖外部供应商交付。

团队规模 22 人，其中真正需要每周更新状态的只有 11 人。按说这是一个管理复杂度可控的项目，但它在我手上失败了。

2. 第一周：所有人的状态都是“进行中”

周五收上来的周报里，11 个任务有 9 个写着“进行中”，2 个写着“已完成”。我当时的处理方式是：读一遍，觉得没问题，转成汇总表发给相关方。

现在回看，这份周报里有三个致命的信息缺失：没有写“和上周承诺相比的偏差”，没有写“完成标准是什么”，没有写“有没有依赖别人的东西”。一份不包含偏差、完成标准和依赖的周报，信息量接近于零。

3. 第三周：关键路径上的阻塞没人说

真正的问题出现在第三周。外部供应商的数据接口任务，负责人在周报上一直填“进行中”，直到第三周周三他才在群里说了一句“对方说要下周才能给测试账号”。这条信息如果第三周周一就被识别出来，我还有两周时间切换备选方案。

结果是：这条依赖直接导致联调任务被推迟，关键路径滑了 11 天，后续三个任务被迫压缩工期，测试阶段从 10 天压到 6 天，最终上线后一周内出现两个生产问题。

4. 复盘：问题不在人，在机制

事后我问那位负责人，为什么不在周报里写“被外部阻塞”。他的回答很典型：“我不知道这个算不算阻塞，而且我觉得还在推进，就没写。”

这句话点出了机制上的两个缺口：第一，没有定义什么叫“阻塞”；第二，没有给成员一个低成本表达阻塞的方式。当成员不确定自己的问题该不该上报时，他默认的选择永远是不上报。

三、常见误区拆解：六种让周进展失效的做法

下面这六种做法，我在不同团队里反复见到。它们的共同点是：看起来在管理进度，实际上在消耗团队的耐心。

1. 误区一：把周报当成进度跟踪的全部

周报是单向的信息输出，进度跟踪是双向的决策过程。周报只能回答“做了什么”，回答不了“和计划比差在哪、要不要调整、谁来拍板”。

我做过一个小实验：把同一个项目的周报发给五位没参与项目的同事，请他们判断项目是否有风险。五个人里有四个给出了“看起来正常”的结论，而实际上当时已经有一个里程碑确定要延期。如果一份周报让外部读者无法识别风险，它对项目经理本人的价值同样有限。

2. 误区二：用百分比代替完成标准

“完成了 80%”是项目管理里最有欺骗性的一句话。剩余 20% 可能是最后一天就能收尾的收尾工作，也可能是需要重新设计的技术方案，两者对项目的影响相差十倍。

我现在的做法是彻底禁止在周进展里填百分比，改为填两件事：已经交付了什么可验证的产物、还差什么条件才能判定为完成。

3. 误区三：周会逐条念进度

11 个任务逐条念，每条 2 分钟，就是 22 分钟。加上讨论，一场周会轻松超过 90 分钟，而其中真正产生决策的时间不到 15 分钟。团队成员会迅速学会“周会就是坐着听”，参与感消失之后，信息质量也会同步下降。

4. 误区四：各部门各有一套状态口径

研发说的“完成”是代码合并，测试说的“完成”是跑完一轮回归，运维说的“完成”是上线到生产环境。当三个部门在同一条进度线上汇报时，项目经理看到的是一个拼凑出来的假象。

5. 误区五：行动项没有验收人

“请测试同学尽快确认环境”，这句话里没有负责人、没有截止时间、没有验收标准。下周复盘时，所有人都记得说过这件事，但没人能判断它到底完成没有。

6. 误区六：工具先行，流程靠后

这是我最想劝退的一种做法。先买了平台，再让团队上去填数据，结果填出来的还是“进行中”，只是从 Excel 的“进行中”变成了平台里的“进行中”，管理成本反而上升了。工具放大流程的有效性，也放大流程的无效性。

四、专业判断逻辑：跟什么、跟多细、谁来跟

误区讲完，接下来的问题是：如果不用百分比、不逐条念，那到底该怎么跟？我的判断逻辑分三层。

1. 第一层：跟踪对象分三类，关注点完全不同

• 任务层：关注完成标准是否达成，而不是动作是否在发生。判断口径是“交付物 + 验收人 + 日期”。
• 里程碑层：关注偏差天数与关键路径影响。里程碑只报两件事：当前预计日期、与原计划的差值。
• 风险与阻塞层：关注是否需要外部资源或更高层决策。这一层不追求完整，追求及早。

这三类的更新频率也应该不同。任务层每周更新，里程碑层每周核对但只在偏差超过阈值时上报，风险层随时上报、周会集中处理。

2. 第二层：粒度由项目类型决定，不存在通用答案

敏捷迭代项目适合以迭代为单位跟踪，粒度到用户故事；传统交付项目适合以里程碑为单位跟踪，粒度到工作包；多项目组合适合以组合健康度为单位跟踪，粒度到项目级。把这三类项目的跟踪方式统一成一套，是很多 PMO 落地失败的根本原因。

3. 第三层：项目经理负责组织与升级，不负责替人更新

我接手新项目时会明确三个角色的边界：任务负责人负责如实更新状态和提前暴露依赖；项目经理负责统一口径、清洗偏差、组织决策、跟踪行动项；决策人负责在资源冲突和优先级冲突上拍板。

一个常见错误是项目经理为了“数据好看”，替成员把状态改成合理值。这样做短期让周报漂亮了，长期会让团队成员认为自己不需要对状态准确性负责。状态的第一责任人是任务的执行者，不是项目经理。

4. 完成标准的写法可以直接抄

我给团队的定义是：一个任务只有在同时满足三个条件时才能标记为已完成，有可验证的交付物、有明确的验收人确认、有完成日期。三者缺一，状态只能填“进行中”或“待验收”。

状态字典示例（可直接改写为团队规范）
未开始：尚未分配或尚未排期

进行中：已开始，未达到完成标准

待验收：交付物已提交，等待验收人确认

阻塞：无法自主推进，需要外部资源或决策

已完成：交付物 + 验收人确认 + 完成日期三者齐备

已取消：经决策人确认不再执行

完成标准模板：

[交付物] 由 [验收人] 在 [日期] 前确认达到 [具体判定条件]

五、六步周进展落地方案

接下来是我目前正在用的六步方案。它不是理论框架，而是把上面所有判断变成具体动作的顺序。

1. 第一步：会前异步收集，把会议时间留给决策

周三中午前，所有人填写收集表。字段固定为七项：任务、负责人、上周承诺、当前状态、本周实际产出、阻塞与依赖、需要谁支持。前四项是事实，后三项是判断和诉求。

关键细节是“上周承诺”这一栏必须由系统或表格自动带出，不能让人手填。承诺的对比是周进展的全部价值来源，一旦靠回忆填写，偏差就会被人为抹平。

2. 第二步：数据清洗，把噪声过滤掉再进会

周三下午我做三件事。第一，检查所有标记为“已完成”的任务是否满足完成标准，不满足的直接退回为“待验收”。第二，把所有标记为“阻塞”的任务按影响范围排序，判断哪些必须当周决策。第三，检查关键路径上的任务是否都按时更新，未更新的单独催。

这一步大约花 1 小时，但它把周会从 90 分钟压到 45 分钟。我自己的经验是：会议效率的提升，八成来自会前的清洗，两成来自会中的议程控制。

3. 第三步：周会只谈例外

45 分钟的议程我固定这样分配：状态同步 8 分钟（只说明整体健康度变化）、偏差与阻塞 22 分钟、决策与行动项 12 分钟、收尾确认 3 分钟。

状态同步环节不逐条念，项目经理提前把整体情况写成一页，会上只用一句话说明变化趋势。偏差环节按影响排序，只讨论前三到五项。

4. 第四步：行动项必须写满四个要素

会上形成的行动项，我要求当场写清：谁负责、做什么、何时完成、怎么算完成。四个要素缺一个，就不算形成行动项，只能算记录了一个话题。

我会在会后两小时内把行动项发出来，并标注每条对应的上周行动项编号。让行动项和上周形成可见的对应关系，是提升关闭率最有效的单一手段。

5. 第五步：定义清晰的升级规则

升级规则的价值不在于惩罚，而在于让成员知道“什么时候可以不用自己扛”。如果没有这条规则，成员会选择沉默或延迟上报，两种情况都会让项目经理失去纠偏窗口。

6. 第六步：向上同步一页纸

向上汇报不需要长篇大论。我固定用一页纸，包含五块内容：整体健康度（红黄绿及判断依据）、里程碑状态与偏差、本周主要风险、需要上级支持的事项、下周关键动作。

其中“需要上级支持的事项”最多写三条，每条必须写清希望对方做什么、什么时候之前。向上同步的目标是获得资源和清除障碍，不是让领导了解我有多忙。

六、案例解析：四周把“流水账周会”改成决策会

下面这个案例来自我参与陪跑的一个项目，背景和第二章的失败项目类似，但这次我们用了四周时间逐周修复跟踪机制。为保护信息，人员与业务细节做了模糊处理，数据为我记录的区间值。

1. 项目背景与初始问题

项目规模 18 人，跨三个部门，工期 12 周，关键路径上有 7 个任务，其中 2 个依赖外部服务商。接手时的问题清单是：周报没人认真写、周会平均 95 分钟、行动项连续三周有超过一半未关闭、关键路径上有两个任务的真实状态和汇报状态不一致。

2. 第 1 周：只做一件事，统一状态字典

第一周我们没动任何工具，只做了一次 40 分钟的口径对齐会。会上逐条确认了六个状态的定义，并且重点明确了“完成”的判断标准。会后我把定义写成文档，贴在项目首页。

效果在第一周就出现了：周报里“已完成”的比例从 34% 下降到 12%，但这不是退步，而是原来被错误标记为完成的任务被还原为“待验收”。状态数据短期变差，往往是数据变真实的第一步。

3. 第 2 周：重构周会议程

第二周开始执行 45 分钟议程。变化最大的是取消了逐条汇报环节，改为会前提交、会中只谈偏差。第一次执行时超时到 62 分钟，主要原因是偏差项太多，有 11 项。

第二周会后我们做了个调整：偏差按“是否影响关键路径”和“是否本周必须决策”两个维度排序，只讨论同时满足条件的项。第三周会议时间降到 43 分钟。

4. 第 3 周：建立行动项表和升级规则

第三周我们把所有行动项搬进一张统一的表，字段是编号、行动描述、负责人、截止日期、验收标准、状态、关联上周编号。同时公布了升级规则，明确什么情况必须升级、升级给谁、多久必须反馈。

这一周出现了案例中最关键的一次转折：一个外部依赖任务的负责人主动在周三就上报了供应商可能延期的风险，比原计划暴露时间提前了 6 天。我们因此有时间启动了备选方案，最终没有影响关键路径。

5. 第 4 周：一页纸向上同步与机制复盘

第四周开始输出一页纸的向上同步材料。第一次发出后，项目决策人在当天就回复了其中两条资源诉求，这在之前是从未发生过的。

第四周末我们做了一次 30 分钟的复盘，重点回答三个问题：哪些机制真的减少了偏差暴露时间、哪些环节还在被绕过、下周要砍掉什么动作。复盘结论是砍掉了每日站会，因为它和周会的信息高度重叠。

6. 四周后的数据观察

四周后我整理了几个可对比的指标。这些数值是我在同一项目内的前后测量，属于小样本观察，不能当作行业基准，但方向性足够清晰。

7. 复盘反思：哪些机制最有效，哪些是安慰剂

如果只保留一个动作，我会保留“上周承诺自动带出”。它让偏差无法被遗忘，也让每个人在写下承诺时更谨慎。

相比之下，每日站会在这类跨部门项目中的价值被高估了。它的信息增量与周会高度重叠，却占用了每天的注意力和沟通成本。频率不等于效果，反馈质量才是关键变量。

七、工具怎么选：从表格到平台，什么时候该升级

机制跑通之后，工具的选择才有意义。我的判断原则是：工具要匹配当前的流程成熟度，而不是领先于它。

1. 最小可用组合：表格 + 会议 + 行动项清单

10 人以下、单项目、周期不超过三个月的团队，一张在线表格加一份行动项清单足够。此时的瓶颈在执行力，不在工具能力，上平台反而会增加填表负担。

2. 什么时候必须升级到项目管理系统

出现以下三个信号中的任意两个，我就建议考虑平台化：跟踪的任务数长期超过 150 条；同时进行的项目超过 3 个且有共享资源；需要向外部或上级提供权限隔离可视化的进度视图。

这三个信号的共同点是“人工维护成本超过了工具成本”。在这条线之前上工具，是在给自己增加负担。

3. 中大型组织的三个硬性要求

对于 100 人以上的组织，我建议在选型时把三个条件放在功能列表之前：数据权限能否细到项目级和字段级；是否支持私有化部署以满足数据合规；能否平滑迁移已有的历史项目数据。

以 PingCode 为例说明这类需求的处理方式。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，这一点对数据不能出内网的研发型组织是硬门槛。同时它支持从 Jira 平滑迁移，对于已经积累了大量历史项目和缺陷数据的团队，迁移成本往往是选型时最容易被低估的一项。

在这个背景下，PingCode 常被作为国产替代方案之一来评估，原因不是功能数量的对比，而是迁移路径和部署形态更贴近国内中大型组织的实际约束。

4. 工具落地的正确顺序

我自己的顺序永远是：先跑通三周的手工流程，确认状态字典稳定、偏差能识别、行动项能关闭，再把这些字段一比一搬进平台。这样做的额外好处是，团队在平台上看到的是自己参与定义过的字段，接受度会明显高一些。

反过来做，先上平台再定规则，最常见的结局是平台里堆满了没人看的任务，而真正的问题仍然在群里解决。

八、不同情况下的行动建议

同一套方法在不同组织里的落地方式差别很大，下面按我遇到过的五种典型情况分别给建议。

1. 三到十人的小团队

不要建复杂的机制。用一张表加一次 20 分钟周同步即可，重点只盯两件事：上周承诺是否兑现、有没有卡住的地方。状态字典可以从六个状态精简到四个。这个阶段最大的风险是过度管理，把团队的注意力从交付转移到填表上。

2. 跨部门项目

跨部门项目的核心矛盾是口径和优先级。建议把状态字典和完成标准作为项目启动的必交付物，在启动会上当场确认并留档。周会必须有一位能拍板的决策人参加，否则偏差讨论会变成诉苦会。

3. 多项目并行的 PMO 场景

不要再要求所有项目用同一套周报模板。建议分级：重点项目按周跟踪到任务级，一般项目按双周跟踪到里程碑级，观察期项目只在里程碑节点跟踪。同时建立一张跨项目的资源冲突表，把周进展的产出从单项目汇总成组合视图。

4. 远程与外包团队

远程团队要更依赖书面异步信息。建议把会前收集的截止时间提前到会议前 48 小时，并且把“依赖与阻塞”设为必填字段。对外包团队，完成标准必须写得更细，尤其是验收物形态和确认人，避免出现“交付了但不符合预期”的争议。

5. 刚接手项目的项目经理

如果你刚接手一个已经跑了一段时间的项目，前两周不要改流程，只做信息采集。用两周时间核对真实状态与记录状态的差异，找出偏差最大的一到两个环节，然后再启动改造。这样做的好处是改动有事实依据，团队也不会觉得新官上任就折腾。

九、不同情况下的取舍

方法讲完，接下来是更现实的部分：资源永远不够，你必须取舍。下面五组取舍是我在真实项目里做过判断的。

1. 周会频率：每周还是双周

每周的价值在于纠偏窗口短，代价是占用团队固定时间。我的判断标准是看关键路径上任务的单任务时长：如果多数任务在 3 天以内完成，双周跟踪会让偏差累积到无法纠正，必须每周；如果多数任务在两周以上，双周节奏配合异步更新反而更高效。

2. 跟踪粒度：任务级还是里程碑级

任务级跟踪信息丰富但维护成本高，里程碑级跟踪成本低但发现问题晚。折中做法是：关键路径任务按任务级跟踪，非关键路径任务按里程碑级跟踪。把跟踪成本投在关键路径上，是投入产出比最高的选择。

3. 表格还是平台

表格的优势是灵活、零学习成本，劣势是权限、历史和跨项目汇总弱。平台的优势是可追溯、可汇总、权限清晰，劣势是初始配置成本和迁移成本高。我的取舍线是：一旦出现“同一份数据要在三个以上地方重复维护”，就该考虑平台化。

4. 强制更新还是激励更新

强制更新短期有效，长期会造成数据应付；激励更新的问题是见效慢。我的做法是把更新和决策权绑定：只有按时更新并且在会前提交的任务，才能在周会上获得资源支持。这条规则比任何惩罚措施都管用。

5. 完美数据还是可用数据

永远拿不到完美数据。我的判断是：只要关键路径任务的偏差识别率能到 80% 以上，非关键任务的少量失真可以接受。追求 100% 的数据准确度，通常意味着把大量成本花在了对项目结果影响最小的部分。

十、直接可用的模板与话术

这一节我把常用的四张表和两段话术整理出来，可以直接改字段名使用。每个字段我都注明了它为什么存在，不建议无理由删除。

1. 周进展收集表字段

2. 周会议程模板

1. 整体状态回顾（8 分钟）：只讲健康度变化与关键里程碑，不逐条念。
2. 偏差与阻塞（22 分钟）：按影响排序，只讨论前三到五项，每项当场给出处理决定。
3. 决策与行动项（12 分钟）：每条写满谁、做什么、何时、验收标准。
4. 收尾确认（3 分钟）：确认下周关键动作与下次会议时间。

3. 行动项跟踪表结构

行动项表字段（建议直接建表）
编号：AI-2026-014（年份 + 序号，便于引用）

行动描述：完成数据接口联调并提交测试报告

负责人：单一责任人，不允许填两个名字

截止日期：具体到日

验收标准：测试报告经测试负责人确认，覆盖全部 12 个用例

状态：未开始 / 进行中 / 待验收 / 已完成 / 已取消

关联上周编号：AI-2026-009（形成可见的延续关系）

升级标记：是否已触发升级规则

4. 向上汇报一页纸

• 整体健康度：红黄绿 + 一句判断依据，不要只给颜色。
• 里程碑状态：当前预计日期、与原计划的偏差天数、是否在关键路径上。
• 本周主要风险：最多三条，写清影响范围和可能的时间损失。
• 需要支持的事项：最多三条，写清希望对方做什么、什么时候之前。
• 下周关键动作：三条以内，对应到具体负责人。

5. 催更新与升级话术

催更新的原则是降低对方的心理成本，而不是施压。我常用的一句是：“你负责的那条接口任务今天要进周报，你只需要填状态和有没有卡住的地方，两分钟就够，卡住的部分我来协调。”

升级的话术原则是把问题从“人的责任”转移到“需要决策的事项”上：“这条依赖已经阻塞三个工作日，超过了我们约定的阈值，我需要在周四前拿到是否切换备选方案的决策，相关背景我已经整理成一页，随时可以同步。”

十一、高频问题快答

1. 成员长期不更新怎么办？

先降低更新成本，再谈纪律。多数不更新是因为字段太多、入口太深、看不到反馈。把字段压到七项以内，并且保证每次更新都会在周会上被引用一次，情况通常会在两周内改善。

2. 周会容易开成批斗会怎么办？

把顺序调整成“先同步事实、再讨论偏差、最后定行动”。同时明确一条规则：讨论偏差时只问“需要什么才能推进”，不追问“为什么没做到”。这条规则需要项目经理自己先执行，否则没人会信。

3. 多项目并行时，周进展应该报什么？

向 PMO 或管理层只报里程碑级偏差和资源冲突，不报任务级细节。任务级信息留在各自项目内部。把两份数据混在一起报，会让汇报材料既太长又看不出重点。

4. 远程和外包团队的进度怎么核实？

靠交付物和验收标准，不靠口头描述。所有关键节点要求提交可验证产物，验收人必须在约定时间内确认或明确退回，否则默认视为延期。同时把会前收集的截止时间提前到 48 小时。

5. 已经上了项目管理平台，但数据还是不准，怎么办？

这通常不是平台问题，而是状态字典缺失和字段约束太松。建议先在平台内把状态字段改为必填的枚举值，把“完成标准”设为完成状态的必填校验，再观察两周数据质量变化。多数情况下，这两个改动就能解决大部分问题。

十二、结尾：从本周开始的三件事

回到开头那个延期 11 天的项目。如果我当时只做三件事，结果很可能不同：把状态字典写清楚并让所有人确认，在收集表里加上“上周承诺”这一栏，把周会的讨论对象从进度改成偏差。

这三件事都不需要采购任何工具，也不需要团队额外投入多少时间，但它们能把周进展从一个汇报动作，变成一套真正能提前发现问题的决策机制。进度跟踪的核心竞争力，不是记录得多完整，而是发现问题有多早。

如果你打算本周就开始，我建议按这个顺序动手：先用 30 分钟和核心成员对齐状态字典和完成标准；然后在收集表里加上“上周承诺”和“阻塞与依赖”两栏；最后在下一次周会上，把议程改成只谈偏差和决策，把逐条汇报的环节砍掉。等到这三步跑满三周、机制稳定之后，再考虑是否需要把流程搬到项目管理系统上，那时候你才知道自己到底需要平台解决什么问题，而不是先买工具再找需求。

最后留一个判断标准给你：如果某一次周会开完，你手里拿不出至少两条写清了负责人、截止时间和验收标准的行动项，那这次会议大概率只是在同步信息，而不是在管理项目。