很多研发负责人以为进度管不好，是因为团队不够拼、工具不够先进。我带了七年研发团队，从 8 人小团队带到 60 多人的多线并行，见过太多“周报全绿、里程碑全黄”的场面。最扎心的一次是 2023 年，一个做了四个月的中台项目，在计划上线前两周的评审会上，技术负责人说“整体完成 85%”，结果一拆到验收清单，真正通过验收的模块只有 4 个，占全部 17 个模块的 23%。剩下的“85%”里，有一半是写完没联调、联调完没验收、验收完文档没归档。
那次之后我彻底改了一个认知：研发目标进度失控，99% 不是执行力问题，而是进度口径、责任人机制和变更管理三件事没有制度化的结果。这篇文章不讲 OKR 定义、不讲 SMART 五要素，讲我从踩坑里总结出来的一套制度设计加 8 步操作，你可以直接抄去改。
一、先给结论：研发目标进度是设计出来的，不是催出来的
如果你时间紧张，只需要记住下面这段话：研发目标进度 = 统一口径 + 单一 Owner + 固定节奏 + 数据看板 + 变更留痕 + 复盘迭代，其中任何一个环节靠“人盯人”补齐，这个体系在一个季度内一定崩掉。
我做过一次内部统计，把过去两年 5 个延期超过 30 天的项目拿出来复盘，发现延期原因分布非常集中：需求变更没有影响分析占 34%，跨团队依赖没人兜底占 26%，进度状态更新滞后或失真占 22%，其余才是技术难度、人力不足、外部因素。换句话说，超过 80% 的延期是可以被制度提前发现的，而不是到了 deadline 才暴露。
为什么“催”没用？因为催是在结果层发力，而进度失真发生在过程层。你每次站会问“进度怎么样”，得到的回答取决于被问的人主观上愿不愿意暴露风险，而制度的作用是让“暴露风险”成为默认动作、让“不更新”有明确后果。
我见过一个团队，项目经理每天在群里 @ 人问进度，一天问 20 多次，表面上信息很多，实际上所有人都学会了“报喜不报忧”。后来他们改成红黄绿灯规则加自动升级，PM 每天看板只花 15 分钟，反而比之前更早发现了两处依赖阻塞。这就是制度替代人力的典型场景。
二、真实场景：为什么你的周报看着很绿，项目却在崩
先还原一个我亲历的场景，你可能很熟悉。
周一到周五，站会照开，看板照更新，周报照写。周报上写着“核心模块开发完成 80%”“接口联调进行中”“暂无风险”。到了月中评审，发现所谓的“80%”是代码提交行数折算的，联调卡住了两个第三方接口，而这两个接口的对接人上周就休假了，没人知道。
问题出在哪？不是团队不努力，是这套机制从三个层面同时失效了。
1. 口径失效：三种“进度”被混着用
研发团队里其实同时存在三种进度，但大部分团队从不区分：
- 工时进度：人干了多少活，用工时、人天、代码量衡量。
- 交付进度：能用的东西交付了多少，用可验收的交付物衡量。
- 目标进度：关键结果是否被验证，用业务价值是否兑现衡量。
这三者经常严重背离。一个团队可能工时进度 90%、交付进度 40%、目标进度 0%，因为交付物还没被业务方验收，价值根本没产生。如果你用工时进度汇报给管理层，管理层的预期和实际结果之间会形成巨大落差，等到落差暴露，往往已经没有缓冲时间了。
2. 责任失效：所有人都有责任，等于没人负责
我见过一个典型写法：“XX 功能由前端、后端、测试共同保障”。这句话在制度上等于没写。依赖出问题时，前端说等后端接口，后端说前端没提需求，测试说没人通知我。三方都没错，但目标就是没推进。
研发目标必须落到单一 Owner，这个 Owner 对结果负责，而不是对“我这一环做完了”负责。这是我认为研发制度设计里第一条不可妥协的规则。
3. 节奏失效：会议开了，但没有决策产生
很多团队的周会是这样：每人轮流讲做了什么，讲了 40 分钟，主持人总结“大家继续推进”。这种会议没有决策，没有风险升级，没有变更仲裁，本质是信息广播，不是管理动作。
有效的节奏会议必须回答三个问题：哪些目标变成黄灯或红灯了？哪些依赖卡住了、需要谁在今天之内给答复？哪些变更要在这周决策、影响是什么？如果这三个问题没有明确答案，会议就是浪费研发团队的时间。
三、常见误区：这 6 个坑我几乎在每个团队都见过
下面这 6 个误区，是我在过去几年里反复见到、并且纠正成本最高的。我把每个误区的表现、危害和修正方法都写清楚。
1. 误区一：用百分比表示研发进度
表现：“这个需求完成 70%”“那个模块完成 90%”。危害：研发任务不是线性推进的，70% 到 90% 之间的工作量可能比 0 到 70% 更大，因为最难的部分往往在后面。百分比给管理者一种虚假的确定性。修正：用里程碑状态替代百分比，比如“设计完成 / 开发完成 / 联调完成 / 验收通过 / 已上线”，每个状态必须有可验证的交付物作为进入条件。
2. 误区二：周报写成作文
表现：周报里大段描述“本周主要推进了 XX 系统优化，解决了若干历史遗留问题”。危害：文字越长，越难看出风险，管理层读完抓不到红黄灯。修正：周报只保留三块内容，目标状态变化、本周阻塞与依赖、需要决策的变更，全文控制在 200 字以内，其余细节放进看板和文档。
3. 误区三：拿 OKR 当 KPI 用
表现：OKR 里的关键结果直接挂到个人绩效，完成 70% 就扣分。危害：团队会立刻学会设保守目标，OKR 从挑战性工具退化成保底承诺。修正：OKR 用于对齐方向，绩效评估看的是目标拆解质量、风险暴露及时性和协作贡献，不是简单看完成率。
4. 误区四：工具堆砌，流程过重
表现：同时用三个工具，一个记需求、一个跟任务、一个做文档，字段还互相对不上。危害：更新成本高到没人愿意维护，数据很快失真。修正：一套工具承载主流程，其他工具只做补充，字段定义统一，更新责任明确到人。
5. 误区五：只追速度，不管技术债
表现：为了赶里程碑，跳过代码评审、跳过自动化测试、跳过文档。危害：下一个迭代进度会断崖式下跌，因为还债时间被隐藏了。修正：在每个迭代固定预留 15%，20% 容量用于技术债和稳定性，并把技术债显式登记进风险表。
6. 误区六：会议过多，信息不聚焦
表现：每天站会 20 分钟、每周周会 90 分钟、每月复盘 3 小时，但没人说得清哪个目标亮了红灯。危害：研发时间被切碎，会议产出为零。修正：会议只看异常，不看常态化汇报；站会不超过 10 分钟，周目标会不超过 45 分钟且只讨论红黄灯、依赖、变更。
四、专业判断逻辑：我怎么决定一个团队该上哪套制度
制度不是越多越好。我给团队做诊断时，会先看四个变量，再决定上哪套组合。
1. 变量一：团队规模与并行项目数
10 人以下单项目，靠站会加一张看板就能跑。10，30 人多项目并行，必须上里程碑表加单一 Owner 制。50 人以上或者跨部门协作，必须加依赖表和升级路径，否则跨团队的事永远卡住。这也是我在做项目管理系统选型时的一个基本判断：团队规模到 100 人以上、并行项目超过 5 个时，制度和工具的耦合度会急剧上升，靠表格和聊天工具已经撑不住了。
2. 变量二：需求变更频率
变更频率低于每月 2 次，可以只做轻量留痕。变更频率每周都有，必须建立变更影响分析模板和变更评审节奏，否则排期永远是假的。
3. 变量三：跨团队依赖密度
如果一个目标的完成依赖 3 个以上外部团队，进度管理的重心就不是任务拆分，而是依赖兑现。这种情况下我会把“依赖兑现率”单独作为一个过程指标看。
4. 变量四：管理层的阅读深度
如果管理层只看一页报告，那你的看板和报表必须在第一屏就能呈现红黄灯和目标状态。如果管理层愿意看细节，那可以保留更细的过程数据。这个变量决定了你的可视化设计，不是决定你要不要做数据。
五、具体案例：一个 120 人研发组织的进度机制改造
下面这个案例来自我参与过的一次咨询。客户是一家做企业级软件的公司，研发约 120 人，分成 9 个小组，同时并行 7 个项目，使用某项目管理平台做需求流转，但进度始终不透明。他们的问题很典型：每个月管理层看到的是“整体按计划推进”，但季度末总有 2，3 个项目延期超过一个月。
1. 改造前：进度数据的三个断层
断层一：需求状态不等于交付状态。平台上需求标记“已完成”，但交付物没有验收标准，导致“完成”的定义由开发自己说了算。
断层二：依赖关系只存在于人脑。跨组依赖靠群里喊，没有登记，一组等二组接口，二组以为一组不着急，双方都没错，项目卡了两周。
断层三：变更不留痕。业务方在群里提一句“这个逻辑改一下”，开发顺手改了，排期没更新，测试不知道，最后验收时发现对不上。
2. 改造动作：四件事，六周完成
- 第一周：统一验收口径。给每个里程碑定义进入和退出条件，“开发完成”的退出条件是代码合并加自测通过加接口文档更新，缺一项不算完成。
- 第二周：落实单一 Owner。每个目标指定一个 Owner，Owner 对该目标的结果负责，可以协调其他组，但不对其他组的内部排期负责。
- 第三到四周：建立依赖表和变更表。依赖必须登记影响范围、对接人、承诺时间；变更必须走影响分析，评估工期和范围变化后再决策。
- 第五到六周：上线红黄灯规则和看板。状态每周五 17:00 前由 Owner 更新，连续两周黄灯自动升级到项目负责人，红灯当天升级。
这里有一个关键选择：他们需要一套能承载依赖表、变更表、里程碑和权限隔离的平台。最终他们选用了 PingCode，主要原因是三点。第一，PingCode 主要服务中大型企业及 100 人以上组织，他们的规模刚好匹配；第二，PingCode 支持私有化部署，满足他们对代码和数据不出内网的要求；第三，PingCode 支持从 Jira 平滑迁移，他们原本大量历史数据在 Jira 上，迁移成本可控。
对于正在做国产替代的团队来说，这是一个值得纳入评估的选项。
3. 改造结果与我的判断
改造后两个季度，他们的延期项目从每季度 3 个降到基本为零，更重要的变化是风险平均暴露时间从上线前 5 天提前到上线前 21 天，这意味着团队有足够时间调整范围或加人。我特别看重这个指标，因为进度管理的价值不在“不延期”，而在“早发现”。
需要说明的是，这个结果不是工具带来的，是制度带来的，工具只是让制度可执行、可追溯。我见过买了很贵的平台但依然延期的团队，也见过只用表格但机制扎实的小团队。工具是放大器，不是发动机。
六、操作步骤：从目标设定到复盘的 8 步
下面这 8 步是我目前使用最顺的一套流程，每一步我都写清楚输入、动作、输出、负责人和频率。你可以按自己团队规模裁剪，但不要跳过第 1、2、8 步。
1. 第 1 步：目标对齐与成功标准定义
输入：业务方需求、上级目标、上一周期复盘结论。动作：明确这个目标解决什么业务问题，定义可验证的成功标准，写清楚“什么情况算完成”。输出：一页目标说明，包含目标描述、成功标准、不做什么。负责人：目标 Owner + 业务方。频率：项目启动时一次，重大变更时重做。
2. 第 2 步：里程碑与验收物拆分
输入：目标说明。动作：把目标拆成 3，7 个里程碑，每个里程碑必须有可验收的交付物，比如“接口文档 + 可运行 Demo + 测试报告”。输出：目标里程碑表。负责人：目标 Owner。频率：启动时一次，迭代评审时更新。
3. 第 3 步：任务、用户故事与依赖拆分
输入：里程碑表。动作：拆到可估算的粒度，一般单个任务不超过 3 人天；同时识别跨团队依赖并登记。输出：任务列表 + 依赖登记表。负责人：各模块负责人。频率：每个迭代开始前。
4. 第 4 步：容量估算与排期，设置缓冲
输入：任务列表、团队实际可用人力。动作：按真实可用容量排期，不要按 100% 理想产能排，预留 15%，20% 缓冲应对变更和技术债。输出：迭代排期表。负责人：研发负责人 + 项目经理。频率：每个迭代一次。
5. 第 5 步：认领与承诺，明确 Owner 与协作人
输入：排期表。动作：每个目标指定唯一 Owner，协作人明确职责边界。输出：Owner 清单。负责人：研发负责人。频率：每个迭代一次。
6. 第 6 步：建立看板与数据采集
输入：任务、依赖、变更数据。动作：设计看板字段和状态流转规则，明确谁在什么时候更新哪些字段。输出：目标进度看板。负责人：项目经理。频率：一次性搭建，持续维护。
7. 第 7 步：节奏检查，开好三个会
输入：看板数据。动作：站会看阻塞，周目标会看红黄灯和依赖，迭代评审看交付物验收。输出：风险清单、决策记录。负责人：主持人轮流或固定。频率：每日 / 每周 / 每迭代。
8. 第 8 步：预警、变更、复盘与制度迭代
输入：风险清单、变更记录、复盘结论。动作：按红黄灯规则升级，变更走影响分析，复盘只讨论机制改进不追责个人。输出：更新后的制度条款。负责人：研发负责人。频率：每月一次。
七、落地模板：三张表、三个会、一个看板
很多人看完方法论还是不知道怎么动手，所以我把模板字段直接写出来，你复制到自己的项目管理平台或表格里就能用。
1. 三张表
表一：目标里程碑表，字段包括目标名称、里程碑名称、验收标准、Owner、协作人、计划完成时间、实际完成时间、当前状态、风险等级、备注。
表二：风险依赖表，字段包括风险或依赖描述、类型、影响范围、发生概率、影响程度、责任人、应对措施、承诺兑现时间、当前状态。
表三：变更记录表，字段包括变更内容、提出人、提出时间、变更原因、影响范围、工期影响、决策人、决策结论、生效时间。
2. 三个会
| 会议 | 频率 | 时长 | 只讨论什么 | 产出 |
|---|---|---|---|---|
| 站会 | 每日 | ≤10 分钟 | 阻塞、今日关键动作 | 阻塞清单更新 |
| 周目标会 | 每周 | ≤45 分钟 | 红黄灯目标、依赖、待决策变更 | 风险清单、决策记录 |
| 迭代评审会 | 每迭代 | ≤90 分钟 | 交付物验收、里程碑状态更新 | 验收结论、下迭代输入 |
3. 一个看板
看板字段建议包括：目标、里程碑、状态（待办 / 进行中 / 待验收 / 已完成 / 阻塞）、风险等级（绿 / 黄 / 红）、Owner、计划完成时间、依赖对象、最近更新时间。
状态流转规则必须写死：从“进行中”到“待验收”的条件是交付物齐全；从“待验收”到“已完成”的条件是验收人确认。没有这两个条件，看板就是装饰。
八、不同情况下的行动建议
制度不能照搬，我按四种典型情况给出建议，你可以对号入座。
1. 情况一：10 人以下小团队，单项目为主
不要上复杂制度。只做三件事：每个目标一个 Owner、一张包含验收标准的里程碑表、每周一次 30 分钟目标会。把力气花在验收标准上，这是小团队最高杠杆的动作。工具用最简单的看板即可，不要引入重流程。
2. 情况二：10，30 人，多项目并行
必须加依赖登记和红黄灯规则。这个规模最常见的问题是多项目抢人，所以除了目标进度，你还要看人力占用冲突。建议每周做一次资源冲突检查，冲突不解决，进度计划就是纸上谈兵。
3. 情况三：50 人以上或跨部门协作
必须有正式的依赖表、变更评审和升级路径，并且需要一套能承载这些数据的平台。这个规模下，我个人会优先评估支持私有化部署、支持复杂权限、支持从现有工具平滑迁移的平台，比如 PingCode 这类面向中大型组织的产品就属于这个区间，但选型的核心还是看你的流程能不能被它承载，而不是看功能列表长短。
4. 情况四：正在做国产替代或迁移
迁移最大的风险不是数据搬迁，而是流程和习惯断裂。我建议分三步：先迁数据保留原流程跑两周，再逐步调整字段和状态，最后才改流程。一次性切换流程和数据，失败率非常高。如果原系统是 Jira，评估新平台时要把迁移工具成熟度作为硬指标。
九、不同情况下的取舍
最后讲取舍。管理动作都有成本，你要清楚自己放弃了什么。
1. 取舍一：进度真实性 vs 更新成本
要求更新越细、越频繁，数据越真实，但研发负担越重。我的经验值是每周一次全员状态更新加异常实时更新，是大多数团队的平衡点。追求每日全字段更新，三周内必然流于形式。
2. 取舍二：制度严格度 vs 团队自主性
规则越硬，执行越一致，但团队自主调整空间越小。我的建议是把规则分成两类：涉及对外承诺和跨团队协作的必须硬，涉及内部实现方式的必须软。
3. 取舍三：工具功能 vs 落地速度
功能越全，配置越复杂，落地越慢。如果三个月内要看到效果，优先选能快速跑起来、后续可扩展的方案，而不是一步到位上最复杂的配置。
4. 取舍四：短期交付 vs 长期技术健康
这两个必然冲突。我的做法是把它显性化：在排期时就标明本迭代技术债预留比例，让业务方看到“赶进度”的真实代价，由业务方和管理层共同决策，而不是让研发团队独自承担。
| 取舍维度 | 偏左选择的收益 | 偏左选择的代价 | 我的建议倾向 |
|---|---|---|---|
| 进度真实性 vs 更新成本 | 数据可信，风险早发现 | 研发事务性负担增加 | 每周全员更新 + 异常实时更新 |
| 制度严格度 vs 团队自主性 | 执行一致，跨组协作顺畅 | 内部灵活性下降 | 对外硬、对内软 |
| 工具功能 vs 落地速度 | 长期扩展性好 | 前三个月见效慢 | 先跑通主流程，再逐步扩展 |
| 短期交付 vs 技术健康 | 里程碑好看 | 下一周期速度下降 | 固定预留 15%，20% 技术债容量 |
回到最开始那个问题：项目目标如何做好目标进度？我的最终答案不是某个工具、某套模板，而是先把口径统一，再把责任落到唯一 Owner，然后用固定节奏和红黄灯规则让风险自动浮出水面，最后用复盘不断修正制度本身。研发进度管理的本质，是设计一套让坏消息能早点被说出来的机制。
下一步我建议你只做一件事：今天就把手上正在跑的项目，按“里程碑 + 验收标准 + Owner”重写一遍，只写一页，不要超过 20 行。写完之后你会发现，很多你以为清楚的地方其实并不清楚，而那些不清楚的地方，就是下一个延期的伏笔。
常见问题解答（FAQ）
1. 研发项目的“目标进度”到底该按什么算？工时饱满、代码提交量高，为什么不算进度？
我在一家三十多人的研发团队做技术负责人，每周收到的周报都写着“完成80%”，可里程碑一到还是延期。我一度怀疑是团队执行力不行，后来复盘才发现，问题出在进度口径本身就不可验证。想请教的是，研发这种不确定性高的场景，进度到底该用什么口径衡量？
先把判断依据立住：进度只对“可验证的结果”负责，不对“投入”负责。工时、代码行数、提交次数属于投入指标，可以看趋势，但不能当进度。我现在的做法是把进度拆成四类可验证信号：里程碑是否按期交付、验收物是否通过事先约定的验收标准、关键依赖是否已解除、变更是否完成影响分析并留痕。
每个目标在立项时就写清“验收物+验收人+验收标准”，状态只用四种：未开始、进行中、待验收、已验收，不用百分比自评。如果管理层需要一个整体进度感，就用承诺完成率，比如迭代承诺12个条目、评审时验收通过7个，完成率就是7/12约58%，而不是“完成了80%”。
还有一个成本很低的自查办法：每周随机抽2到3条被标成“已验收”的条目，让非本模块的工程师按验收标准走一遍，走不通就退回，坚持一个月，进度注水会明显收敛。
2. 不想给研发团队加会议加表格，最小可运行的进度制度应该包含哪几条？
我之前推过一套很完整的进度管理制度，二十多页文档加五张表，结果两个月就烂尾了，表格没人填、周会没人准备，最后又回到靠人催。现在我想重做一版，但希望动作足够少、能真的跑起来。到底哪些条款是不能砍的？
给一个我实际跑过的最小集，五条制度条款，直接写进团队公约就行。（1）单一Owner：每个目标只有一个负责人，协作人可以多个，Owner负责更新状态和抛出问题。（2）固定更新时间：每周五17:00前由Owner更新目标里程碑表，只改字段不改文章，字段就是状态、风险、下一步、需要的支持。
（3）红黄灯规则：出现“关键里程碑延期达到3个工作日”“关键依赖未确认”“验收标准未达成共识”任一条即亮黄灯；连续两周黄灯，或影响既定上线日期，亮红灯并升级到项目负责人。（4）变更必须留痕：任何需求变更先做影响分析，覆盖工期、范围、质量、依赖，由项目负责人决策后才生效。
（5）周会只看红黄灯、依赖和变更，控制在30分钟，不逐条汇报。表只配三张：目标里程碑表、风险依赖表、变更记录表。判断这套制度有没有在运行，标准很朴素：两周后Owner是主动更新，还是每次都要项目经理去问。如果是后者，要么制度太重，要么责任没有真正落到人，先砍字段和会议，不要先加工具。
3. 需求频繁变更导致进度总被拖垮，制度上怎么处理才不伤业务？
我们做的是B端产品，客户和销售随时插需求，研发刚排完的迭代一周就被打乱，工程师情绪也很大。我不想一刀切拒绝变更把业务得罪了，但也不能无限接受，制度上有没有既能接住变更、又不让进度失控的办法？
核心思路不是消灭变更，而是让变更的代价可见、让决策权有明确归属。做法分三步。第一，设唯一变更入口：所有变更不许在群里口头提，统一填变更记录表，写清变更内容、提出人、原因、影响范围、期望时间。
第二，强制影响分析：由Owner在约定时限内给出工期影响、可选方案（替换当期需求还是整体顺延）、质量与依赖风险，一般30分钟内能完成，不给分析就不进入变更流程。第三，按影响大小分级决策：影响不超过1人日的，Owner和产品经理直接定；影响当期迭代目标的，项目负责人定；
影响上线日期或跨团队的，由业务负责人拍板，并且必须同步说明“哪件事不做了”。最关键的判断口径是：不接受“加进来但不加时间”，每次变更都要有对应的取舍。另外我自己的经验是，上线前两周进入范围冻结，只接受缺陷修复和合规类变更，这条提前写进制度，比事后在群里争论有用得多。
4. 项目进度数据要不要跟工程师绩效挂钩？怎么用它复盘而不是变成问责？
我团队之前把迭代完成率直接绑到绩效上，结果大家开始把任务拆得特别碎，一个需求拆成八个任务，还专门挑容易验收的做，进度数据反而更假了。现在我想把数据用对，但又怕一放开大家就不重视。这个尺度怎么把握？
我的结论很明确：过程进度数据不建议直接做个人考核，尤其不要用迭代完成率、提交量、工时这类指标直接算绩效。原因很直接，这些指标一旦跟评级和奖金挂钩，就会被人为优化，最典型的就是把任务拆碎让完成率好看，以及优先做容易验收的活儿。可行的分法是两层。
团队层面，每月看四个过程信号：交付周期（从开始到验收通过的中位天数）、迭代承诺完成率、缺陷逃逸率（上线后发现的缺陷数除以总缺陷数）、阻塞时长占比；只看自己的历史趋势，不做跨团队横向排名。
个人层面，考核用承诺兑现和协作反馈，也就是约定的事有没有按时按质交付、风险有没有及时暴露，而不是看完成了多少个任务。复盘会固定问三个问题：哪个假设错了、哪个环节反复卡住、下个周期改哪一条制度。如果一次延期的根因是需求中途插入，结论应该是去修变更规则，而不是追责某个工程师，这样数据才会越用越真。
核心关键词
文章包含AI辅助创作：项目目标如何做好目标进度？研发团队制度设计与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/309214
读者评论
文章里“三种进度口径”这个点很戳我。我们团队周报一直用工时进度汇报，管理层以为快完成了，结果验收时才发现交付进度差一大截。看完意识到不是团队不努力，是口径没统一，汇报数据本身就是失真的。
单一Owner这条我认同，但落地最难的是跨团队依赖。我们之前也是“共同保障”，出问题互相等。后来指定了依赖对接人还不够，真正管用的是升级路径，卡住多久必须上报到谁，这个不写清楚Owner也是空的。
六个误区里“OKR当KPI用”和“只追速度不管技术债”确实最要命。前者一旦挂绩效，团队立刻设保守目标；后者赶进度省掉的评审和测试，下一个迭代全变成还债时间。这两件事靠培训没用，得从制度上兜底。