项目问题台账的老化评审，核心是逐条判断问题是否仍在推进、卡在谁手里、下一步是否明确，而非重述问题描述。建议按台账规模分层设置频率：日常周会做15分钟快速过账，只处理超期与停滞项；每月做一次完整老化评审，覆盖全部在册问题；每季度做一次台账清理与规则复盘。本文讨论范围限于项目推进障碍类问题，产品缺陷与服务事件另有管理流程。若台账已用ONES等工作项工具承载，可结合视图与字段配置支撑老化判断。
要点总览（TL;DR）
- 老化评审逐条判断问题是否仍在推进、卡在谁手里、下一步是否明确，评审产出是更新后的台账记录和待办动作。
- 评审内容固定为五项：老化时长与停滞天数、责任人与当前动作、阻塞原因归类、升级降级或关闭判断、下次检查时间与触发条件。
- 频率按台账规模分层：周会15分钟只过超期与停滞项，每月一次完整评审覆盖全部在册问题，每季度做台账清理与规则复盘。
- 改进从补齐最后更新时间、停滞天数、下次检查日三个字段开始，再设超期阈值、固定议程、明确关闭与转出标准。
- 效果看平均在册时长、超期占比、停滞占比与清理率，并用上线前后及未实施项目作对照，避免把自然波动当成机制效果。
当前台账评审的常见做法与改进目标
多数团队已经有例行的问题评审，通常安排在项目周会或月度例会上，由项目经理逐条念出问题清单，责任人简要说明进展。这种做法能起到信息同步作用，但评审焦点往往停留在“问题是什么、现在什么状态”，缺少对“停留了多久、为什么停住、下一步何时有结果”的追问。结果是台账条目不断累积，状态长期停在“处理中”，会议开完却没有人对停滞负责。
老化评审要补的正是这个维度。它的目标可以归纳为三点：让每条在册问题都有可核实的推进状态；让停滞问题暴露卡点归属，是等待决策、等待资源、外部依赖还是无人认领；让每条问题都有明确的下次检查时间或关闭结论。评审产出应当是一组更新后的台账记录和待办动作，而非一份会议纪要。
需要先划清边界。本文所说的项目问题，指影响项目计划、交付或协作推进的障碍事项，例如需求口径未定、关键资源未到位、跨团队接口未确认。产品Bug归缺陷管理流程，服务中断归服务事件与问题管理流程，它们有各自的严重等级、响应时限和复盘机制，混入项目问题台账会让老化口径失真，也会稀释评审注意力。若团队目前把三类事项放在同一张表里，改进的第一步是分表或至少增加事项类型字段加以区分。
老化评审该评审哪些内容
老化评审按固定五项逐条过账，每项都要给出判断结论，避免变成自由讨论。下表列出五项内容及判断口径，可直接作为评审议程模板使用。
| 评审项 | 看什么 | 判断口径 |
|---|---|---|
| 老化时长与停滞天数 | 问题创建至今的天数，以及距上次状态变更的天数 | 停滞天数超过团队设定阈值（如7天或14天）即标记为停滞，优先过账 |
| 责任人与当前动作 | 谁在推、推到哪一步、下一个具体动作是什么 | 责任人明确且能说出下一步动作与时间点的，视为在推进；说不出的转入阻塞分析 |
| 阻塞原因归类 | 等待决策、等待资源、外部依赖、无人认领 | 每类对应不同处理路径：决策类找决策人，资源类排优先级，外部依赖设跟进节点，无人认领当场指派 |
| 升级、降级或关闭判断 | 是否需要提高处理层级，是否可降级为观察项，是否满足关闭条件 | 影响关键路径或长期无进展的升级；影响已消除的降级；问题已解决或不再成立的关闭并记录原因 |
| 下次检查时间与触发条件 | 下次在哪个会上复查，或满足什么条件时提前触发 | 每条未关闭问题都必须有下次检查日期；外部依赖类可设“对方回复后即复查”的触发条件 |
五项之中，停滞天数是区分“在推进”和“看起来在推进”的关键指标。一个问题可能每周都被提到，但状态字段几周未变，这类条目最容易在汇报式评审中被放过。评审时先看停滞天数排序，把最久未变更的条目放在议程最前面，能显著压缩无效讨论。
阻塞原因归类决定了后续动作由谁承担。等待决策的问题，责任在有权拍板的人；等待资源的问题，责任在排期方；外部依赖的问题，团队能做的是设定跟进节奏和备选方案；无人认领的问题则暴露台账管理本身的漏洞。把归类做扎实，升级才有依据，避免所有问题都涌向项目经理。
评审频率怎么定：周、月、季分层
频率取决于台账规模和问题增速，一刀切地每月评审一次，对条目多、变化快的项目会积累盲区；每天都开完整评审，又会挤占执行时间。分层设置是更稳妥的做法，三层各承担不同任务。
| 层级 | 频率与时长 | 覆盖范围 | 主要产出 |
|---|---|---|---|
| 周度快速过账 | 每周一次，控制在15分钟内 | 只处理超期项与停滞项 | 停滞项的责任人确认、下一步动作、是否升级 |
| 月度完整评审 | 每月一次，30至60分钟 | 全部在册问题 | 逐条状态更新、关闭与降级决定、下月重点 |
| 季度清理与复盘 | 每季度一次 | 台账整体与评审规则 | 长期挂账条目清理、阈值与议程调整、规则修订 |
周度过账只做一件事：把停滞和超期条目挑出来，当场确认责任人和下一步。它不讨论新问题的来龙去脉，新问题在提出时即登记，进入月度评审范围。15分钟的限制本身就是纪律，超时说明议程失控或条目过多，需要调整。
月度完整评审覆盖全部在册问题，逐条走完五项内容。条目较多时可先按停滞天数排序，前一半详细过账，后一半快速确认状态。季度清理针对的是那些反复出现在评审中却始终无法推进的条目，要么升级到更高层级处理，要么明确关闭并记录原因，避免台账变成只进不出的仓库。季度复盘同时检查阈值是否合理：如果大部分条目都触发停滞标记，说明阈值过严或问题登记过细；如果几乎没有条目触发，说明字段更新不及时或阈值过松。
调整频率的判断依据可以看两个数：每周新增问题数与每周关闭问题数是否大致平衡，以及停滞项占在册问题的比例。新增持续大于关闭、停滞比例上升，说明需要提高评审频率或缩短阈值；台账长期平稳，可维持现有节奏，不必为了形式增加会议。
优先改进动作：从过账到清理的落地步骤
改进按以下顺序推进，前一步的产出是后一步的输入，不建议跳步。
- 补齐老化字段。在台账中增加最后更新时间、停滞天数、下次检查日三个字段。停滞天数可由最后更新时间与当前日期计算得出，减少手工维护。字段定义要写进台账使用说明，明确状态变更时必须同步更新最后更新时间。
- 设定超期阈值与标记规则。按问题影响程度分档设置阈值，例如影响关键路径的问题停滞7天即标记，一般问题14天标记。标记规则要能自动呈现，评审时直接按标记筛选，不依赖人工回忆。
- 固定评审议程与角色分工。周度过账由项目经理主持，责任人应答；月度评审增加决策角色参与，负责升级判断；季度复盘由台账管理者牵头，输出规则修订。议程按五项内容顺序排列，每项限时。
- 明确关闭与转出标准。关闭需满足问题已解决或不再成立，并记录关闭原因与验证方式；转出指问题性质变化后移交缺陷管理或服务事件流程，转出时在台账留痕并注明去向，避免同一事项在两处重复跟踪。
如果台账已经在ONES这类工作项工具中管理，上述动作可以落到具体配置上：用自定义字段承载最后更新时间与下次检查日，用视图按停滞天数筛选和排序，把评审议程固化为固定的筛选条件，评审时直接打开对应视图逐条过账，状态变更与字段更新在同一条记录上完成，减少会后再补记录的二次工作。工具承载的是记录与呈现，评审的判断和决策仍由人完成。
适用前提与代价
这套机制成立的前提是台账字段保持更新。停滞天数、下次检查日这些数据依赖责任人每次状态变更时同步维护，一旦更新滞后，老化数据就失真，评审会把注意力放到错误条目上。团队需要在推行初期接受一段磨合期，把字段更新纳入问题处理的标准动作，必要时在周度过账中抽查字段准确性。
代价还包括会议时间与责任人精力。周度15分钟乘以参与人数，加上月度完整评审，是实打实的时间投入；责任人需要在会前准备当前动作说明，而非临场回忆。问题量过大时，完整评审难以逐条覆盖，此时应按影响程度分层，关键路径问题逐条过账，一般问题抽样或按停滞天数排序取前若干条，其余以书面更新代替口头汇报。
跨团队问题的升级依赖管理层支持。当阻塞原因归类为等待决策或外部依赖时，项目经理往往没有权限推动，需要预先约定升级路径和决策人，否则评审识别出卡点也无法转化为动作。这一点在机制设计阶段就应与相关管理层确认，而不是等到评审现场临时协调。
效果验证：怎么判断老化评审起作用
验证要回答的问题是：评审机制上线后，问题停留情况是否改善。可观察的指标包括问题平均在册时长、超期问题占比、停滞问题占比与清理率，以及评审后状态变更的及时性，即评审中确定的下次检查时间是否被遵守、状态是否在约定时间内更新。
指标变化需要对照才能解读。建议选取机制上线前的一段周期作为基线，与上线后相同长度的周期比较，同时观察未实施该机制的同类项目作为参照。如果所有项目的问题时长同期都在下降，可能来自整体节奏变化而非评审机制本身；如果只有实施评审的项目改善明显，机制的作用才更有说服力。演示情景：某项目上线前四周平均在册时长为21天、停滞项占比35%，上线后四周降至14天和18%，同期未实施项目基本持平，这一对比可作为机制有效的初步信号，但样本周期短，仍需继续观察。
还要防止指标被扭曲。关闭率突然升高，要检查是否存在为达标而草率关闭的情况，可抽查关闭记录的原因与验证方式；停滞天数普遍很短，要核对最后更新时间是否被频繁无实质变更地刷新。指标用于发现问题，评审质量最终仍要看每条问题是否有了明确的推进状态和下一步。
常见问题
问题台账条目很多，月度评审逐条过账时间不够怎么办？
按影响程度分层处理。影响关键路径的问题逐条走完五项内容；一般问题先按停滞天数排序，取前若干条详细过账，其余以书面状态更新代替口头汇报。周度过账只挑超期与停滞项，本身就能筛掉大部分无需讨论的条目。如果条目多到分层也覆盖不了，说明问题登记过细或台账混入了缺陷、服务事件等不该在此跟踪的事项，应先做分表或增加类型字段。
停滞天数应该按创建时间算还是按最后更新时间算？
两个口径回答不同问题，建议同时保留。创建至今的天数反映问题在册总时长，用于看整体老化水平；距上次状态变更的天数反映停滞程度，是评审排序和触发标记的主要依据。只按创建时间算，会把持续有进展但周期长的问题误判为停滞；只按最后更新时间算，又可能漏掉反复被提及却始终无实质推进的条目。评审时先看停滞天数排序，再看在册总时长判断是否需要升级。
责任人频繁刷新最后更新时间但问题没有实质进展，怎么识别？
在评审中把“当前动作”和“下次检查时间”作为独立判断项，要求责任人说明具体动作和完成时间点，而非只更新状态字段。可以抽查状态变更记录，看是否存在无实质变化的频繁刷新。季度复盘时对照停滞天数与在册时长两个指标，若停滞天数普遍很短而在册时长持续偏长，通常说明字段更新与实际推进脱节，需要收紧字段更新规范或在周度过账中核对准确性。
跨团队问题在评审中识别出卡点，但项目经理推不动怎么办？
升级路径要在机制设计阶段就与相关管理层约定，明确哪类阻塞原因对应哪位决策人、在多长时间内必须给出答复。评审现场只负责归类卡点和指定升级对象，不临时协调权限。等待决策类问题应记录决策人和约定答复时间，到期未答复即进入更高层级；外部依赖类问题由团队设定跟进节奏和备选方案，把可控部分先推进。
季度清理时，长期挂账的问题应该关闭还是继续保留？
按问题是否仍然成立判断。影响已消除或前提条件不再具备的，关闭并记录原因与验证方式；仍然成立但长期无进展的，要么升级到更高层级处理，要么拆分为更小、可执行的动作重新进入台账。保留原条目继续挂账是最差的选择，它会让台账失去可信度。清理结论要留痕，便于下季度复盘时判断同类问题是否反复出现。
