进度跟踪如何做好周进展？管理层制度设计与操作步骤

周进展做得越勤，管理层反而越看不清项目，这并不少见：周五收到十几页状态材料，所有项目都写着“整体正常”，到了月底却集中暴露延期、依赖未到位和资源冲突。问题通常不在团队没有汇报，而在制度把“写了什么”当成“管住了什么”。我设计周进展机制时，首先要回答的不是“每周填哪些字段”，而是“哪些偏差必须在本周触发决策”。

一、先讲结论：周进展不是周报，而是一套例外管理机制

1. 把目标从“收材料”改成“促成决策”

我对周进展的核心判断是：它不是把一周做过的事整理成文字，而是把计划与现实之间的差异及时暴露出来，并为下一步行动指定责任人、期限和决策路径。管理层不需要每周重读所有项目的工作流水，只需要看清哪些目标偏离、偏离原因是什么、当前由谁采取什么行动，以及哪些问题需要管理层介入。

如果一份周进展没有明确的目标基线、偏差判断和下一步动作，那么它大概率只是工作纪要。即使页面做得漂亮、字段填得齐全，也无法回答“项目是否仍能按期交付”这一管理问题。

制度设计的最低闭环是：承诺基线，实际状态，偏差判断，纠偏行动，责任人和期限，下周验证。少了其中任何一环，管理层得到的就可能是信息，而不是可执行的控制依据。

2. 管理层看组合风险，项目负责人看交付路径

同一份周进展，不能让不同层级的人都看同一堆细节。项目负责人需要掌握任务、依赖、验收条件和执行阻塞；部门负责人要判断人力是否冲突、关键路径是否受影响；高层要看交付承诺、商业影响、重大风险和需要拍板的事项。

因此，我建议用“一套事实、三层视图”代替“三套口径”。底层工作项可以很细，项目视图聚合节点与风险，组合视图只展示超阈值的项目和待决策事项。信息来源一致，但呈现颗粒度不同，才能减少团队反复填报。

3. 周频率适合发现偏差，不适合替代日常协作

周进展是控制节奏，不是任务管理本身。遇到生产事故、重大客户变更、安全事件或关键路径当日失守，不能等到周五才上报。周机制应定义“哪些信息日常同步、哪些偏差即时升级、哪些事项进入例会”，避免团队把所有沟通都塞进周报。

二、背景和真实场景：为什么“每周都报”仍然会失控

1. 延期往往不是突然发生，而是偏差长期没有被解释

我在项目复盘中最常见的情形，不是团队完全没有进展，而是“做了很多事”与“关键交付没有前移”同时存在。开发任务完成了，接口联调却没有环境；测试用例增加了，缺陷关闭率却低于新增率；设计评审结束了，业务验收标准仍未确认。若周报只统计任务完成数，就会把局部活动误当成整体进展。

真实的进度必须绑定可验证的交付物。例如，“完成支付模块开发”需要明确代码合并、自动化测试通过、接口契约确认或业务验收中的哪一个状态。没有验收条件，团队成员对“完成”的理解可能不同，管理层看到的百分比就不能横向比较。

2. 多团队项目的核心难题是依赖，不是填表速度

当一个项目跨越产品、研发、测试、数据、安全和外部供应商时，某个团队的进度并不等于整体进度。上游交付晚两天，可能让下游测试窗口缩短一周；接口字段未冻结，可能同时影响开发、测试和客户验收。周进展如果只按部门汇总“本周完成”，就看不到依赖链上的传导关系。

所以我会要求项目负责人把关键依赖写成可验证的承诺：交付内容是什么、提供方是谁、接收方是谁、约定日期是哪天、验收标准是什么。像“等待对方支持”这样的描述，不是依赖管理，而是尚未定义完整的协作请求。

3. 管理层需要的是异常清单，不是所有人的周记

管理层时间有限，信息密度比信息总量更重要。如果每个项目都按统一篇幅描述背景、会议、任务和问题，真正需要拍板的事项反而埋在正文中。比较有效的办法是让正常项目保持轻量更新，把偏离计划、关键节点受威胁、需要跨部门资源或授权的项目显著标出。

这也解释了为什么周进展制度不能只考核“按时提交率”。按时提交只能说明流程节点被执行，不能说明信息准确、风险及时暴露、决策得到闭环。机制要同时看输入质量与管理结果。

三、常见误区：看起来很忙，实际没有形成控制

1. 把任务完成率当作项目进度

任务完成率最容易计算，也最容易误导。假设项目有100个任务，其中80个是准备、文档和低风险事项，20个是关键路径交付；如果前80个完成而关键路径上的接口和验收仍未通过，显示“完成率80%”并不能说明项目接近完成。

我会把任务进度与里程碑状态分开看：任务用于执行管理，里程碑用于判断承诺是否仍成立。对于关键节点，还要检查验收证据，而不是仅依赖负责人自报百分比。

2. 用颜色替代判断

红黄绿状态适合快速扫描，但颜色本身不构成解释。一个项目标成绿色，仍需要知道它的目标日期、剩余工作、关键路径和风险变化；一个项目标成黄色，也必须说明是轻微波动、缓冲即将耗尽，还是已经需要调整承诺。

如果状态没有对应阈值，不同负责人就会按自己的习惯打色。有的人把“还没延期”当绿色，有的人把“存在不确定性”就标黄色。建议制度明确触发规则，并允许项目负责人说明特殊情况，但不允许只改颜色、不留理由。

3. 每周追问“做了什么”，不追问“原计划是否还成立”

完成事项能说明过去发生了什么，却未必能说明未来能否按期。周进展应同时呈现上周承诺、本周结果、当前预测和下周关键交付。若预测日期发生变化，必须写明变化依据，而不是等实际到期后再宣布延期。

管理者最值得追问的不是“为什么没做完”，而是“哪项证据让你判断原计划不再可信、现在还有哪些可选路径”。前者容易把会议变成追责，后者更可能带来及时纠偏。

4. 风险写成形容词，行动写成愿望

“进度有一定风险”“加强沟通”“尽快协调资源”都无法验收。风险要写清触发条件、影响范围、发生可能性和应对动作；行动要明确负责人、完成日期、交付物以及升级条件。

例如，“供应商响应较慢”可以改为：“供应商须在周三17时前提交可联调版本；若未提交，项目负责人当天通知采购与研发负责人，并评估切换到模拟接口是否能保住周五的联调窗口。”这样管理层才能判断需不需要介入。

5. 用更多字段试图解决责任不清

当材料质量不佳时，常见反应是增加字段：本周计划、下周计划、问题描述、风险等级、影响分析、责任部门、协作部门、备注等。字段越多，填报时间越长，但如果没有清晰的口径、责任边界和复核机制，团队只会把同一件事重复写几遍。

我倾向于先用少量字段跑通闭环，再根据复盘结果增加字段。对大多数项目，管理层初始视图通常只需回答：承诺是否变化、关键节点是否可达、主要偏差是什么、需要什么决策、谁在何时完成纠偏。

四、专业判断逻辑：怎样判断进度数据是否可信

1. 先区分事实、预测、判断和请求

一条高质量周进展最好能让读者看出信息属于哪一类。事实是已经发生并可验证的结果；预测是根据剩余工作估算的日期或状态；判断是负责人对风险和影响的解释；请求是希望管理层作出的决策或提供的资源。

把这四类内容混在一句话里，容易让“我认为能完成”看起来像已经完成。写作时可用固定表达区分：已完成什么、证据在哪里、当前预测是什么、判断依据是什么、需要谁在何时决定什么。

2. 用偏差而非绝对状态识别问题

“剩余任务还有12项”不是天然的风险，“计划完成日期是周三、预测完成日期是下周一”才体现了偏差。建议记录承诺基线、最新预测和变化原因。对于已经批准的范围或日期调整，要保留变更记录，否则原始目标会不断被改写，最后看起来所有项目都按时。

衡量进度质量时，可以同时看计划偏差、关键路径浮动、未解决依赖、验收通过情况和预测稳定性。预测稳定性尤其重要：连续几周反复改日期，说明团队可能低估工作量、需求仍在变化，或风险暴露太晚。

3. 以风险严重程度决定升级路径

不是每个偏差都要送到高层，也不是所有问题都能由项目团队自行消化。我的判断顺序是：先看是否影响关键里程碑，再看项目是否还有时间缓冲，接着看影响是否跨团队、跨预算或跨客户承诺，最后判断决策权限是否超出项目负责人范围。

• 团队内可解决：对里程碑影响较小，责任和资源在项目团队范围内，记录行动并在下周验证。
• 部门级协调：涉及资源竞争、优先级冲突或跨团队依赖，由部门负责人确定责任和资源。
• 管理层决策：涉及目标、范围、预算、客户承诺、安全合规或多个部门之间的重大取舍，应在周会前升级。

4. 把趋势作为预警，把单周状态作为信号

单周异常可能是偶发波动，连续多周预测恶化则往往意味着结构性问题。与其只看本周是否“红灯”，不如观察计划偏差是否扩大、风险是否反复出现、行动是否按期关闭、依赖是否持续失约。趋势数据能降低管理者对一次性波动的过度反应，也能避免把长期恶化当成偶然。

需要注意的是，趋势不能脱离项目规模和生命周期直接比较。早期探索项目的预测变动，可能源于需求尚未验证；临近发布项目的同类变动，则可能意味着验收或上线风险。制度要保留阶段背景，不能拿同一阈值机械评价所有项目。

五、具体案例与数据观察：一份周进展如何从“报喜”变成“可决策”

1. 案例背景：上线日期没变，关键路径却在变窄

下面用一个匿名化的企业内部系统上线项目说明。项目团队约120人，涉及产品、研发、测试、数据和运维。项目计划8周交付，管理层原先主要看各组任务完成率；到了第5周，汇总页仍显示总体进度约70%，但集成测试环境尚未准备好，业务验收口径也有两项待确认。

这里的数字是用于说明制度设计的案例推演，不是某个组织的公开绩效数据。它要呈现的是一种常见错位：任务数量看起来完成不少，但关键交付链上的条件尚未满足，导致“整体完成百分比”对上线判断帮助有限。

2. 先重建交付证据，再修改状态

项目负责人把“开发完成”拆成可核实的证据：代码合并、自动化测试通过、接口联调通过、业务验收通过。随后逐项核对后发现，部分开发任务确已完成，但两项关键接口仍在等待上游数据定义；测试环境也因账号权限未配置，尚不能开展端到端验证。

原先的70%不是故意夸大，而是统计口径把已完成的任务数量直接换算成项目进度。重新梳理后，管理层不再问“怎么从70%掉下来了”，而是看三个关键条件：环境何时可用、接口何时冻结、验收人何时确认。关键不是把数字修得更漂亮，而是让数字反映交付条件。

3. 把问题从描述转成决策请求

项目组把周进展改成一页异常摘要：预计上线日期暂不调整，但发布缓冲已被消耗；数据接口负责人需在周三前确认字段；运维需在周四中午前开放测试账号；业务负责人需在周四评审两项验收口径。若其中任何一项未按时完成，项目负责人将在当天提交延期或缩减首发范围的备选方案。

管理层由此能够作出具体选择：调配环境支持人员，安排业务负责人参加评审，并授权项目组评估首发范围的优先级。问题仍然存在，但它不再只是“有风险”，而是有负责人、期限、验证条件和备选决策。

4. 观察指标要解释行为，不要制造新的绩效游戏

对这个推演案例，我会跟踪纠偏行动按期关闭率、关键依赖逾期数、里程碑预测变动次数、验收一次通过情况和周进展准备耗时。它们分别回答行动是否落地、协作是否可靠、预测是否稳定、交付质量是否满足要求，以及制度本身是否增加了过多行政成本。

如果只考核“红色项目数量下降”，团队可能倾向于不报风险；如果只看“周进展按时提交率”，就会鼓励及时交空表。指标必须与事实核验、复盘和管理决策结合，不能单独变成奖金或问责的机械依据。

六、制度设计：把口径、节奏、权限和复核写清楚

1. 定义适用范围与项目分级

不是所有工作都需要同样强度的周进展。持续运营、探索性研究、固定范围交付、重大客户项目和合规改造的风险结构不同。制度可以按交付复杂度、跨部门数量、预算影响、客户承诺和合规影响分级，决定更新颗粒度、审核人和升级时限。

小型团队可采用轻量更新：关键结果、偏差、下周承诺和阻塞事项。多部门、长周期项目则需要维护基线、里程碑、依赖、风险和决策记录。分级的目的不是增加审批，而是避免用重大项目的管理负担套住所有日常事项。

2. 规定状态阈值，允许解释但不允许无依据变色

可以从组织自身的历史项目开始设阈值，不必照搬别人的红黄绿规则。以下只是制度起点的示意基准：关键里程碑预测偏差不超过2个工作日、且缓冲充足时列为正常；偏差达到3至5个工作日或关键依赖即将逾期时列为关注；偏差超过5个工作日、缓冲耗尽或重大承诺受影响时列为升级。实际阈值要结合项目周期、行业要求和合同约束校准。

制度还应允许负责人说明特殊背景。例如，探索阶段本来就存在较高不确定性，直接套用交付项目的日期偏差阈值会产生大量无效警报。状态规则的价值是统一讨论起点，不是替代专业判断。

3. 明确责任边界和决策时限

项目负责人负责更新事实、预测和行动；工作流负责人确认交付证据；部门负责人协调资源与部门间依赖；项目治理角色负责汇总异常、检查数据口径和追踪决策；管理层负责处理授权范围外的目标与资源取舍。若“谁都能更新，没人负责核验”，数据就会失去可信度。

对管理层待决策事项，应写清最晚决策时间和不决策的影响。比如“需要资源支持”没有可执行性；“请在周二17时前批准借调一名测试工程师两周，否则系统回归窗口将从5天缩短到2天”，才是一个可比较的决策请求。

4. 让复核成为制度的一部分

周进展数据不应只在周会前被动收集。项目负责人应在固定时间更新，相关责任人确认关键依赖和验收证据，项目治理人员抽查异常项目，管理会议只讨论需要协调或决策的事项。会后形成决策记录，并在下一周检查是否按期执行。

没有复核，制度容易退化成自我申报；没有会后追踪，会议容易退化成重复讨论。两者都需要留痕，但留痕的目的不是文书归档，而是让预测、决策和结果可以回看。

七、操作步骤：从周一到周会后，形成可重复的闭环

1. 周一：确认本周承诺，不重新发明一套计划

周初由项目负责人确认本周要交付的关键结果、验收证据、责任人和依赖方。计划应从既有项目基线和工作项中继承，不要每周重新复制粘贴一份清单。若目标变化，先记录变更原因和批准人，再更新预测，避免历史承诺被覆盖。

2. 周中：遇到偏差先更新事实，不等到固定汇报日

关键依赖失约、测试窗口受影响、范围新增或验收口径变化时，应及时更新风险和影响。周中记录不是为了要求所有人每天写周报，而是确保信息在影响扩大前进入正确的处理路径。项目负责人要判断问题是否能在团队内解决，还是需要部门或管理层协调。

3. 周四：收集证据并检查预测

周四或组织约定的会前时间，检查关键工作项是否有可验证结果，核对本周承诺与实际差异，重新估算剩余工作和里程碑日期。预测改变时，记录触发因素，例如需求变化、依赖逾期、缺陷数量超预期或人员不可用。不要因为“已经报过一次日期”就拒绝更新现实预测。

4. 周五：提交异常摘要，普通项目保持轻量

周报首页应优先展示本周承诺完成情况、下周关键目标、里程碑预测、重大风险、待决策事项和逾期行动。正常项目可以只保留简短摘要；异常项目补充影响分析与备选方案。会议材料要让读者快速找到“需要我做什么”，而不是把所有工作记录从头读一遍。

5. 周会：先处理决策，再处理解释

会议可以先核对上周决策是否执行，再讨论新出现的重大偏差和资源冲突，最后确认决策、责任人、期限和失效条件。对于团队内部可以解决的问题，要求项目负责人会后处理，不必占用高层会议时间。对已明确的事项，会议中不要重复争论状态颜色，重点讨论选项、成本和风险。

6. 会后：把决定转成行动，并在下周验证

会议结束后，将资源批准、范围取舍、日期调整和责任分配记录到对应项目或决策台账。下一周检查的不是“有没有开过会”，而是行动是否完成、问题是否消除、预测是否恢复稳定。如果决策没有执行，应继续升级或调整方案，而不是在周报里重复写同一句阻塞描述。

1. 准备：确认本周承诺、里程碑和关键依赖。
2. 更新：记录事实、预测、偏差原因和风险变化。
3. 核验：对关键交付抽查工作项、验收记录或测试证据。
4. 筛选：把需要协调或授权的事项进入管理视图。
5. 决策：形成负责人、截止时间、交付物和未完成时的备选动作。
6. 复盘：下周核对行动闭环与预测准确性，必要时调整机制。

八、工具与数据：让制度可执行，但不要让工具替代判断

1. 先确定统一数据对象，再讨论看板长什么样

周进展通常涉及项目、里程碑、工作项、风险、依赖、决策和负责人。若这些信息分散在表格、邮件、即时消息和会议纪要里，项目负责人就要人工拼接，管理层也难以确认数据是否来自同一口径。工具建设前，应先定义对象关系：风险关联哪个里程碑，依赖由谁承诺，行动对应哪个决策，状态由谁核验。

自动化可以减少重复整理，例如从工作项聚合逾期任务、提醒依赖到期、生成里程碑变化记录。但系统无法自动判断“这次日期变化是否会影响客户承诺”，也无法替管理层决定是否缩减范围。自动化适合处理确定性规则，专业判断仍需要责任人承担。

2. 100人以上组织重点看权限、审计和迁移成本

对中大型组织，周进展工具不只是一个填表页面。需要评估项目之间的数据隔离、角色权限、组织级指标口径、历史记录追溯、单点登录、接口集成、数据导出、部署方式和运维责任。不同业务线若各自维护一套字段和状态，组合层面的汇总就会变成“看似统一、实际不可比”。

例如，PingCode主要面向中大型企业及100人以上组织，可用于项目协作与进度管理场景；涉及敏感数据或内网要求的组织，可将私有化部署纳入评估。若团队已有Jira相关工作流，还要核查迁移前后的字段映射、历史数据保留、权限转换和用户培训，不能仅凭“支持迁移”就认定切换没有成本。任何工具是否适合，都应以实际试点和安全、运维评估为准。

3. 试点要测量管理成本，而不只看功能清单

我建议先选择一个跨团队、风险适中、周期足够长的项目试点，而不是一开始把全部项目搬进去。试点前后记录周进展准备耗时、逾期依赖识别时间、行动按期关闭率、状态与验收证据一致性、管理会议时长等指标。若系统让填报耗时增加，却没有改善风险发现和决策闭环，就应先调整字段与流程，而不是继续扩大上线范围。

工具选型不能只比较页面功能，也要算实施和持续维护成本：数据迁移、权限治理、模板设计、接口开发、用户培训、管理员投入、升级影响和退出方案。对于国产替代或跨平台迁移，关键判断是业务流程能否稳定承接、数据能否完整导出、权限与审计是否满足要求，而不是单看产品宣传语。

九、不同组织情况下的行动建议与取舍

1. 小团队：优先减少摩擦，不必复制大型治理体系

如果团队人数少、依赖关系简单、决策链短，可以先用轻量周进展：本周承诺、实际结果、下周目标、阻塞事项和需要的帮助。关键是每条阻塞都有负责人和处理时间，而不是为了看起来规范建立复杂的审批流。

取舍上，小团队可以接受一些信息由负责人直接口头同步，但必须保留重要日期变化和决策记录。若项目增多、多人共享资源或客户承诺开始冲突，再逐步补充里程碑基线、风险等级和组合视图。

2. 多项目组织：优先统一口径，再做组合看板

当一个部门同时运行多个项目时，管理难点通常从单项目执行转为资源竞争、优先级冲突和风险排序。此时应统一关键节点定义、红黄绿触发规则和待决策字段，并规定跨项目资源冲突如何升级。没有口径统一，组合看板只会把不同意思的颜色放在同一页。

取舍上，统一不是要求每个项目使用完全相同的工作流。研发、市场、实施和研究项目可以保留不同执行细节，但管理层关心的承诺、风险、依赖和决策字段必须能在共同尺度上解释。

3. 高不确定性项目：管理假设和验证周期，不要伪造精确日期

探索性工作、创新项目或需求快速变化的项目，早期日期本来就不稳定。与其每周强行报一个精确完成百分比，不如跟踪假设、验证结果、未决问题和下一次决策节点。例如，先确认用户需求是否成立，再决定是否投入完整开发资源。

取舍上，高不确定性项目需要更灵活的阶段目标，但仍应约定资源上限、验证期限和停止条件。灵活不是不受管理，而是把管理对象从固定交付日期转成阶段性证据和继续投入的理由。

4. 强合规或客户承诺项目：牺牲一部分速度，换取可追溯性

涉及安全、监管、合同验收或重大客户承诺时，状态变化、审批依据、测试证据和决策记录都应能回溯。必要时为关键风险设置即时升级，不等周会；对上线条件和豁免事项留下明确审批记录。

取舍上，合规项目的周进展可能比一般团队更正式，准备时间也更长。应避免把所有事项都做成高等级审批，而是把审计要求集中在关键变更、验收条件和风险接受上，降低不必要的流程负担。

5. 远程或跨地域团队：把异步表达写完整

跨时区协作时，周会未必能覆盖所有相关人员。周进展要写清事项背景、需要的输入、决策截止时间和默认处理方式，避免一句“等某地团队回复”导致任务停摆。对关键依赖设置确认机制，不能只依赖消息已读。

取舍上，异步机制需要更完整的文字与记录，短期内准备成本可能较高；但它减少了重复追问，也让不同时区的责任人有明确行动窗口。团队应避免把异步文档做成冗长流水账，重点仍是事实、影响和下一步。

十、制度落地的六周节奏：先试运行，再固化

1. 第一周：盘点现有报告与决策路径

收集现有周报、项目看板、会议纪要和升级记录，识别重复字段、无人使用的内容和反复出现的阻塞。重点追问过去三个月哪些问题原本可以更早暴露、哪些决策因为材料不清晰而延迟，以及管理者实际上会采取什么行动。

2. 第二周：确定最小字段和升级阈值

先定义项目目标、关键里程碑、当前预测、主要偏差、风险与依赖、纠偏行动、待决策事项等最小字段。阈值用组织自己的项目历史做初步校准，并明确它是触发讨论的规则，不是对项目负责人做简单排名的工具。

3. 第三至第四周：选项目试点并记录成本

选择项目类型有代表性、负责人愿意反馈、管理者能参加复盘的项目。试点时不只看周报是否按时完成，还要记录填报耗时、数据核验耗时、决策等待时间和逾期行动数。发现字段重复或状态误解，先调整模板和解释口径。

4. 第五周：复盘阈值和会议结构

检查哪些风险被过早升级、哪些关键问题仍未触发、管理层会议是否花时间讨论可由团队自行解决的事项。若黄色项目太多，先判断阈值是否过宽、风险描述是否不完整，而不是简单取消预警；若重要风险没有被发现，则要检查证据来源和责任边界。

5. 第六周：决定扩展、修订或停止

根据试点结果决定扩大范围、调整规则或暂停工具配置。可用的制度应同时满足三点：一线团队能在合理时间内维护，管理者能据此更早决策，项目数据经过抽查仍有可信度。只要其中一项不成立，就应继续修正，而不是为了完成上线计划而强行推广。

十一、周进展模板：让团队写出能被管理的内容

1. 建议的单项目摘要字段

2. 一条合格的周进展应该能被反问

管理者看到“预测晚2天”后，应该能追问基线日期是什么、受影响的里程碑是什么、判断依据是什么；看到“需要测试资源”后，应该能追问需要几人、多久、由谁负责、其他项目会受到什么影响。写作不是为了避免追问，而是让追问落在真正的取舍上。

3. 用一个简单的写作顺序提高信息密度

可以要求负责人按“结果，偏差，影响，行动，请求”组织内容。先说已经发生的事实，再说和计划有什么差异，然后解释对交付的影响，列出团队正在采取的行动，最后明确需要管理层做什么。这样既避免流水账，也避免只报问题不提供方案。

十二、结尾：真正有效的周进展，是让坏消息更早、更具体地出现

我认为，周进展制度的成熟度，不取决于表格有多少字段、看板有多少图，也不取决于每周会议开多久，而取决于偏差能否在还有选择空间时被看见。一个健康的机制，不会让团队因为报告风险而受到不公平惩罚，也不会允许风险长期用模糊描述隐藏在“整体正常”里。

如果你准备改造现有周进展，不必先做大规模系统切换。先选一个跨团队项目，明确基线、关键里程碑、验收证据、升级阈值和管理层决策字段；连续运行四到六周，复核数据可信度、会议耗时和行动闭环，再决定是否推广或引入工具。

下一步最值得做的动作，是抽查最近四周的周进展，找出三类记录：没有证据的完成、反复出现的依赖、没有责任人和期限的纠偏事项。把这三类问题各挑一项改成可验证、可升级、可复盘的记录，周进展就会开始从“汇报发生了什么”转向“帮助组织决定接下来做什么”。