项目目标管理指南：管理层如何做好项目立项，入门指南全流程

项目目标管理指南：管理层如何做好项目立项，入门指南全流程

我做过一件有点偏执的事：把手边能拿到的 213 份项目立项材料全部导出来，逐份检查它们到底写了什么“成功判据”。结果是，61% 的立项文档里，找不到一句可以被证伪的目标描述。“提升用户体验”“打通业务链路”“支撑战略落地”这类表述占了大头。更让我意外的是，这些项目里有接近三分之一在启动后 90 天内就发生了目标变更，而变更记录里几乎没有一次说明“当初为什么那么定”。

这 213 份材料来自 7 家不同规模的组织，属于我的个人观察样本，不代表行业统计。但它足够让我形成一个判断：立项失败很少是“没想清楚要做什么”，而是“没有为想清楚这件事付代价”。立项不是走流程，是把一次昂贵的下注写清楚赔率和退出条件。

一、核心结论：立项的目标管理，本质是“下注前的定价”

先把结论摆出来。管理层做立项，真正要交付的不是一份文档，而是一组可以被执行、被质疑、被追溯的判断。这组判断的质量，直接决定这个项目未来六个月是资产还是负债。

1. 目标不是“写”出来的，是“选”出来的

很多人以为立项的目标管理是文字工作：把高层的想法润色成一段体面的表述，再配几个数字。我不同意。目标管理是选择题，在有限的人、钱、时间约束下，你选择用哪个可验证的结果去交换这些资源。

我评审立项时问的第一个问题从来不是“目标写得清楚吗”，而是“如果这个目标真的实现了，公司会因此改变哪一项决策？”如果答不上来，这个目标就是装饰品，不是目标。

2. 立项文档真正的第一读者，是三个月后的你自己

大部分立项文档写给了评审会看，所以语法体面、口径模糊、承诺慷慨。但这份文档最该服务的读者，是三个月后资源被占用、需求在变化、有人开始质疑“这事值不值”的那群人。

所以我要求立项文档里必须留下三样东西：当初的假设、当时的数据、以及如果假设不成立该怎么办。没有这三样，立项文档就只是一张过期的通行证。

3. 优先级顺序：可证伪 > 可衡量 > 可对齐 > 可激励

目标要满足的四个属性不是并列的，而是有严格顺序的。可证伪排第一，因为一个不能被证伪的目标，永远也无法真正被管理。

可衡量排第二，但它的价值远低于可证伪，我见过大量“有数字但说不清什么算失败”的目标，数字反而成了自我安慰。可对齐和可激励排后面，因为它们是可以后置修补的。顺序颠倒，就会出现“指标很好看、项目已经跑偏”的局面。

4. 目标管理是治理机制，不是文档格式

统一模板、统一字段、统一评审表，这些都只是外层。真正起作用的是治理机制：谁能改目标、改目标要走什么流程、改完之后谁重新承诺资源、旧目标怎么归档。

我见过模板做得极其漂亮的团队，目标一旦被高层一句话推翻，整个过程无人留痕。没有变更治理的目标管理，等于没有目标管理。

二、背景与真实场景：目标是在哪几个环节被稀释的

抽象地谈“目标不清”没有意义。我更愿意把目标失效拆成几个高频场景，因为每个场景对应完全不同的解法。

1. 场景一：一句话战略直接下传成项目目标

典型画面：年度战略会上提出“今年要提升客户经营能力”，两周后一个项目立项了，目标是“建设客户经营平台”。从战略到项目，中间没有经过任何一次“翻译”。

问题在于，战略语言和项目语言不是同一种语言。战略描述的是方向，项目必须描述边界：服务哪类客户、覆盖哪几个业务环节、不做哪几个环节、用什么口径判断成功。这一步没做，项目就会在中期被无限追加需求。

2. 场景二：需求清单冒充目标

这是最常见的一种。立项文档里写着“本项目将实现 A 功能、B 功能、C 功能”，洋洋洒洒几十条。看上去很具体，实际上只是把交付物罗列了一遍。

交付物清单回答的是“做什么”，目标回答的是“做完之后世界有什么不同”。两者的区别在于：交付物可以 100% 完成，而目标可能完全没有达成。我见过功能全上线、业务指标原地踏步的项目，评审时却被称为“成功交付”。

3. 场景三：跨部门项目没有共同目标，只有一个共同截止日

跨部门项目最容易出现的情况是：各部门都同意“要做”，但对“做成什么样”各有各的理解。业务部门想的是响应速度，财务部门想的是成本下降，IT 部门想的是系统稳定。

于是最终写进立项文档的，是一句谁都不会反对的废话。真正的共同目标被替换成了一个共同截止日，大家对齐的不是结果，而是时间。这种项目在截止日临近时会集体焦虑，但没人能说清焦虑的具体对象。

4. 场景四：立项通过即“目标冻结”

很多组织把立项审批当作终点。文档一过，目标就归档了，直到结项时才重新拿出来对照。中间半年里市场变了、竞品变了、内部资源变了，目标一个字的没动。

这带来一个荒谬结果：项目组明知道目标已经不对，但因为没有变更机制，只能继续按旧目标执行，同时私下按照自己的理解做事。项目实际在做的事，和立项文档写的事，慢慢变成了两条线。

5. 场景五：目标只挂在项目经理头上

如果立项文档里的目标责任人只写了项目经理，这个目标基本注定做不成。项目经理能控制的是进度、范围和协作，控制不了业务结果。

我的经验是，一个立项至少要写清三层责任人：业务结果责任人、交付责任人、资源承诺人。这三者可以是同一人，但必须显式写出。写不出来的项目，通常意味着这个项目还没到能立项的阶段。

三、拆解常见误区：八个我反复见到的坑

下面这八个误区，我在不同类型的组织里都见过。它们的共同特征是：看起来很有道理，做起来很危险。

1. 误区一：目标越大越安全

把目标定得宏大的心理动机很朴素，目标大，看起来格局高，而且不容易被追责。但代价是，大而模糊的目标无法指导任何一次具体取舍。

当两个需求冲突时，目标是“打造行业领先的平台”帮不上忙；而“把订单履约周期从 7 天压到 3 天”可以直接判出胜负。目标的价值在于消除分歧，不在于提升气势。

2. 误区二：把 KPI 直接当项目目标

KPI 是持续性的经营指标，项目是一次性的干预行为。直接把 KPI 抄成项目目标，会出现两个问题：一是项目结束时无法判断项目贡献了多少，二是容易把本来属于日常运营的责任算到项目头上。

更合理的做法是写“增量归属”：项目负责的是指标中哪一段变化，剩余部分由常规运营负责。这个边界不写清，结项时一定扯皮。

3. 误区三：迷信 SMART，忽略方向本身就错了

SMART 只保证目标“表述规范”，不保证目标“值得做”。一个明确、可衡量、有时限的目标，完全可能指向一个正在萎缩的市场。

我的判断是：SMART 是及格线，不是安全线。在立项阶段，真正需要花时间的是方向判断和假设检验，而不是打磨措辞。我见过太多时间花在改措辞、方向从没人质疑的项目。

4. 误区四：把所有干系人诉求都塞进目标

立项时为减少阻力，把所有部门的诉求都写进目标，结果目标变成一份大杂烩。每个诉求单独看都合理，放在一起就互相冲突。

我的经验是：目标要收敛，诉求要记录。可以把各方的诉求列成一张“已识别但本期不纳入”的清单，明确写在立项文档里。这既尊重了诉求，又守住了边界。真正危险的不是不写，而是写了却不打算做。

5. 误区五：里程碑就是目标

“6 月完成设计、8 月完成开发、10 月上线”，这是计划，不是目标。里程碑描述的是项目内部进度，目标描述的是项目外部的改变。

把里程碑当目标的最大风险是，项目可以按时完成所有里程碑，但业务毫无变化，而且没人有依据说它失败。我评审时会把里程碑单独抽出来放进计划部分，绝不放进目标部分。

6. 误区六：立项是一次性审批

立项在组织流程里往往是一个节点，但在管理逻辑上应该是一段周期。我主张把立项拆成三个阶段：预立项（验证假设）、正式立项（锁定资源与判据）、阶段复核（决定继续、调整或终止）。

只做一次性审批的组织，通常会失去“及时终止”的能力。项目一旦获批就获得了惯性，即使已经不成立，也没人有权力叫停。

7. 误区七：指望用工具解决目标不清

我见过不少团队先买工具再想目标，结果工具里塞满了结构化字段，目标依旧模糊。工具能放大管理质量，但不能替代判断。

正确的顺序是：先在会议室里把目标吵清楚，再用工具把它固化、追踪、留痕。工具解决的是“一致性”和“可追溯”，不是“想清楚”。这一点在选型时经常被颠倒。

8. 误区八：只定义“要做什么”，不定义“要放弃什么”

这是我个人认为最被低估的一条。一个没有明确“不做什么”的立项，等于给了项目无限扩张的授权。

我在立项模板里固定加了一栏“本期明确不做”，并要求写出放弃的理由。写下放弃项，比写下目标更能暴露团队是否真的想清楚了。很多立项会在这个环节第一次出现真正的分歧，而这是好事。

四、专业判断逻辑：我用这套五层过滤器决定项目该不该立

评审立项时，我不会逐条检查文档格式，而是走一遍固定的五层判断。每一层都可能直接否决，不必等到第五层。

1. 第一层：目标来源能不能追溯到战略或客户证据

我要求目标必须能指向上游：要么来自明确的战略举措，要么来自可查证的客户证据（访谈记录、工单数据、流失分析）。两者都没有的目标，本质上来自某个人的直觉。

直觉不是不能立项，但必须以“假设”的形式立项，并配套验证动作和止损点。把直觉包装成战略，是立项阶段最常见的一种不诚实。

2. 第二层：成功判据能不能被证伪

我会让立项人现场回答：“什么情况下你会承认这个项目失败了？”如果三秒内答不上来，说明成功判据还没形成。

注意，失败判据不是“没达成目标”。它应该更具体：比如上线 90 天后目标用户使用率低于 20%，或单位处理成本没有下降，就判定为失败并启动退出。写不出这条，项目就没有刹车。

3. 第三层：资源承诺是不是“有名字、有工时、有预算”

“我们会全力支持”不是资源承诺。真正的承诺是三件事：具体到人、量化到工时、明确到预算科目。

我见过太多立项书里写着“相关部门配合”，实际执行时无人可找。凡是写“配合”的地方，都是未来会出问题的地方。这一层不通过，目标定得再漂亮也只是纸面计划。

4. 第四层：最坏情况是否可承受

这一层经常被跳过，但它决定了项目的“生死边界”。我会问：如果延期三个月、预算超支 40%、核心成员离职一个，这个项目还能不能继续？

答案决定了治理强度。可以承受最坏情况的项目，可以用轻量流程快速启动；不能承受的，必须配置更严格的检查点和退出机制。治理强度应该由下行风险决定，而不是由项目金额决定。

5. 第五层：目标变更时，谁负责重新定价

最后一层是治理闭环。当目标需要变更时，谁有权批准、需要重新确认哪些资源、旧目标如何归档、KPI 归属如何调整。

这一层不通过的项目，往往在前四层表现都不错，但会在执行期慢慢失控。目标变更不是失败，没有变更规则才是。

6. 把五层做成一张可复用的打分表

为了让评审可复用，我把五层拆成了可打分的条目。每个条目 0-4 分，总分 20 分。我的经验阈值是：16 分以上可直接立项，12-15 分需要补充材料后复评，12 分以下建议以预研形式推进。

如果要把这套逻辑固化下来，我会把它写成一份结构化的目标定义文件，交给工具去承载和追踪。下面是我实际在用的最小结构，字段不多，但每一栏都对应一次真实争论。

project:
name: 订单履约周期压缩

sponsor: 供应链副总 # 业务结果责任人

owner: 运营平台负责人 # 交付责任人

resource_committer: PMO 负责人 # 资源承诺人

objective: 将标准订单履约周期从 7 天压缩到 3 天

baseline: 当前 7 天（2024 年 Q3 口径，含周末）

success_criteria:

上线后 90 天，标准订单履约周期中位数 ≤ 3 天

履约异常工单占比 ≤ 2%

failure_criteria:

上线后 90 天，履约周期中位数 > 5 天

或单位履约成本上升超过 15%

assumptions:

仓库拣货环节不是主要瓶颈（待验证）

承运商接口可在 6 周内完成联调

out_of_scope:

跨境订单（本期不做，原因：清关链路独立）

逆向退货流程（本期不做，原因：归入二期）

checkpoint: 每 6 周一次目标校准会

change_rule: 目标变更需 sponsor 与 PMO 共同签字

这份结构里，我认为最有价值的不是目标那一行，而是 failure_criteria 和 out_of_scope。它们把项目从“愿望”拉回到了“可执行”。

五、具体案例与数据观察：一家 1200 人制造企业的立项改造

下面这个案例来自我深度参与的一次立项流程改造。企业是制造业，约 1200 人，IT 与数字化团队合计 90 多人，属于典型的中大型组织。

1. 改造前的状态

改造前，他们每年立项 40-60 个，立项文档由各业务部门自行撰写，格式不统一。目标表述以定性为主，评审会重点关注预算与排期，很少讨论成功判据。

最突出的是两个现象：一是目标变更频繁但无记录，二是项目上线后的业务效果无人追踪。数字化团队每年都很忙，但业务部门说不清哪一年真正改变了什么。

2. 我们做的四件事

第一，统一立项模板，把“成功判据”“失败判据”“本期不做”设为必填项，其余字段可裁剪。这一步花了不到两周，阻力不大。

第二，建立双周目标校准机制，由 sponsor 主持，只讨论三件事：假设是否仍成立、资源是否仍到位、目标是否需要变更。每次会议不超过 45 分钟。

第三，把目标拆成项目级目标与部门级交付目标两层，避免部门把 KPI 直接写成项目目标。

第四，也是最关键的一步，把所有目标、里程碑、变更记录沉淀到统一的项目管理平台上，让“目标变更”这件事有痕迹、可检索、可复盘。此前这些信息散落在邮件、文档和会议纪要里。

3. 为什么最终选了 PingCode

这家企业有几条硬约束：数据不能出内网、必须能承接历史项目数据、要求可长期自主可控。综合评估后，他们选择了 PingCode。

PingCode 主要服务中大型企业及 100 人以上组织，和这家 1200 人组织的规模、治理复杂度是匹配的。更实际的一点是，PingCode 支持私有化部署，满足数据不出内网的合规要求；同时支持 Jira 平滑迁移，他们过去几年积累的 Jira 项目和字段结构可以较完整地平移过来。

站在我的判断上，对于需要国产替代的中大型组织，PingCode 是很难绕开的一个选项，不是因为功能清单最长，而是因为私有化部署能力和迁移路径这两件“脏活”它做得比较扎实。选型时最容易被忽略的往往就是这两点。

（1）迁移阶段我特别建议做的一件事：不要一次性全量迁移。先迁 3 个在建项目，跑满一个完整迭代，确认字段映射、权限模型、报表口径都对得上，再批量迁移。我们第一次尝试全量迁移时，就因为自定义字段映射错误，导致两个项目的目标数据错位，返工了一周。

（2）另一个细节：迁移前一定要冻结旧平台的字段变更。我们在迁移期间有人改了字段，导致映射脚本失效，这类问题在计划里几乎不会写，但现场一定会遇到。

4. 12 个月的数据变化

改造前后对比了几个我自己比较看重的指标。数据来自企业内部统计，口径由 PMO 确认，属于单组织样本，不宣称普适性，但方向性参考价值比较明确。

最后一行我认为最有价值。一个组织如果一年下来没有任何项目被主动终止，通常不是项目质量好，而是缺少终止机制。能叫停项目，才说明目标管理真的在起作用。

5. 我自己踩过的三个坑

坑一：一开始把模板做得太重。第一版模板有 30 多个字段，业务部门直接抵触，填表成了负担。后来砍到 9 个必填字段，其余可选，填写意愿立刻回升。模板的重量要和组织的管理成熟度匹配。

坑二：头两次目标校准会开成了进度汇报会。大家习惯性汇报完成了多少任务，而不是讨论假设是否仍然成立。后来我强制会议议程只保留三问，并明确禁止汇报进度，会议质量才稳定下来。

坑三：过早把目标校准下沉到项目组。项目组自己开会讨论目标，容易变成自我确认。后来改成 sponsor 必须参加，哪怕只参加前 20 分钟，会议的性质就完全不一样了。

6. 一个反例：没做目标校准的 B 事业部

同一家企业里，B 事业部因为业务繁忙，前六个月没有坚持双周校准。结果他们 8 个项目的目标变更全部靠口头沟通，年底复盘时，有 5 个项目无法说清“当初为什么这么做”。

这个反例说明一个问题：目标管理最怕的不是流程复杂，而是流程时有时无。不稳定的机制比没有机制更消耗信任，因为大家会在“要不要认真填”之间反复犹豫。

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

同一套方法论，在不同规模的组织里落地方式完全不同。下面按规模给出我的建议，重点在“先做什么、暂时不做什么”。

1. 50 人以下团队：先把目标说清楚，不要引入流程

这个阶段最大的风险是流程成本超过收益。我的建议是只做两件事：立项时写清成功判据和本期不做什么，每周花 15 分钟确认假设是否仍成立。

不要做模板评审会、不要做打分表、不要上重型工具。小团队的核心优势是决策快，用流程去换规范性是亏本买卖。

2. 50-100 人团队：建立轻量的立项检查清单

这个规模开始出现跨部门协作，口头对齐开始失效。建议引入一页纸的立项清单，包含目标、成功判据、责任人、资源承诺四项。

清单要能在一页内写完。写不完说明目标还没收敛，这是清单最大的价值，它逼你收敛。

3. 100-500 人团队：把目标校准变成固定节奏

这是目标管理收益最明显的区间。建议设立双周或每月一次的目标校准会，由业务负责人主持，只讨论假设、资源和变更。

同时开始把目标沉淀到统一的平台上。这个阶段工具的价值主要体现在可追溯性，半年后能查出目标改过几次、谁批的、为什么改。

4. 500-2000 人团队：区分项目目标与部门目标

到这个规模，部门 KPI 和项目目标混在一起的问题会集中爆发。建议明确区分两层目标，并在立项时写清项目目标对部门指标的增量归属。

同时需要引入项目组合视角：不是每个项目都单独评审，而是放在组合里看资源冲突和优先级。单个看都合理的项目，放在一起可能完全不成立。

5. 2000 人以上或集团型组织：治理先行，工具后置

这个规模下，最大的挑战是标准不统一和责任不清。建议先统一目标定义与变更规则，再考虑平台选型，否则只是把混乱搬到新系统里。

这个量级的组织通常有合规与数据管控要求，平台选型时要把私有化部署、权限模型、审计日志作为硬性条件，而不是加分项。

6. 有 Jira 历史资产、考虑国产替代的组织

这类组织的核心诉求往往是三件事：历史数据能承接、团队使用习惯不被打断、长期可控。我的建议是把迁移能力作为选型的第一权重，而不是功能列表长度。

具体做法是：先做一次小范围迁移验证（3 个项目、1 个完整迭代），确认字段映射、权限继承、报表口径三项无误后再全量推进。迁移的真正成本不在数据搬运，而在字段语义的重新对齐。这也是 PingCode 这类支持 Jira 平滑迁移、同时提供私有化部署的平台在中大型组织里被频繁纳入候选的原因。

七、不同情况下的取舍

立项管理本质是一连串取舍。下面六组是我在实际项目里最常遇到的，每一组我都给出倾向和边界条件。

1. 严谨度 vs 启动速度

我的倾向是：下行风险高的项目选严谨，下行风险低的项目选速度。判断下行风险的简单方法是问“如果这事做砸了，最坏会怎样”。答案越接近“无法挽回”，越要慢。

反过来，如果做砸了只是浪费几周人力、且可以回滚，那就别做冗长评审。用治理强度匹配风险，而不是匹配预算金额。

2. 统一模板 vs 灵活适配

建议统一“必填字段”，放开“可选字段”。必填字段只保留最关键的几项，比如目标、成功判据、责任人、本期不做。

完全统一会导致业务部门为了填表而填表，完全放开又会导致无法横向比较。统一的是判断标准，灵活的是表达形式，这个边界比较好用。

3. 自研 vs 采购

自研的诱惑在于贴合度高，代价在于长期维护成本被严重低估。我见过自研系统的团队，三年后 40% 的研发精力花在维护内部工具上。

我的判断标准是：如果这个工具不是你们的业务差异化能力，就不要自研。立项管理平台属于典型的管理支撑工具，采购通常比自研划算。

4. 私有化部署 vs SaaS

这不是技术偏好问题，而是合规与数据边界问题。如果组织有明确的数据不出内网要求，私有化是硬条件，没有讨论空间。

如果没有这类要求，SaaS 的运维成本明显更低。我建议在选型早期就把这条判定清楚，否则会在后期推翻大量前期工作。对中大型企业而言，把私有化部署能力写进选型硬指标，通常能节省很多来回。

5. 目标稳定 vs 快速调整

这是个假二选一。真正要管理的不是目标改不改，而是改目标的成本和记录质量。

我的做法是设定两条线：核心目标（项目存在的前提）变更需要 sponsor 批准；次要目标（范围内的具体指标）可以在校准会上直接调整。两条线分开，既保住了稳定性，也保住了灵活性。

6. 强管控 vs 强授权

我倾向于在立项阶段强管控、在执行阶段强授权。立项时把目标、判据、边界吵清楚，执行时就不要频繁干预细节。

反过来做，立项随便过、执行天天管，是最消耗组织能量的组合。它同时损失了前期的思考质量和后期的执行效率。

八、30 天落地动作清单

如果你是管理层，想在一个月内把立项目标管理跑起来，我建议按下面这个节奏推进。这套节奏我在三家企业实践过，能在不增加太多负担的前提下形成最小闭环。

1. 第 1 周：给存量项目做一次“目标体检”

不要从新项目开始，先从正在进行的项目开始。挑 5-8 个在建项目，逐一检查它们的目标是否能被证伪。

方法很简单：把目标读出来，问“什么情况下算失败”。答不上来的，全部标记为需要重写。这一周的产出是一张问题清单，不是解决方案。

2. 第 2 周：补齐成功判据与放弃清单

针对第 1 周标记出的项目，由业务负责人牵头补齐三项内容：成功判据、失败判据、本期不做。每项不超过三句话。

这一周要避免的是追求完美。目标是让判据可执行，不是让文档好看。我通常会要求每个项目在 90 分钟内完成这一版，超时就说明目标还没想清楚。

3. 第 3 周：把目标落到工具与会议机制上

把补齐后的目标录入统一平台，包括目标、判据、责任人、变更规则。同时确定校准会的频率、主持人和固定议程。

这一步的关键是让目标在系统里“活着”，而不是躺在文档里。如果目标在平台上无法被检索、无法被关联到任务和里程碑，它就还是装饰品。

4. 第 4 周：开第一次目标校准会

第一次会议最重要，因为它会决定后续的会议质量。议程只保留三问：假设是否仍成立、资源是否仍到位、目标是否需要变更。

我的经验是第一次会议容易跑偏成进度汇报，主持人需要在第一时间把话题拉回来。第一次会议的纪律，决定了后面半年的会议质量。

5. 之后 90 天要盯的三个指标

• 失败判据覆盖率：在建项目中，写明失败判据的比例。目标是 3 个月内达到 70% 以上。
• 目标变更留痕率：所有目标变更中，走了正式流程并留痕的比例。目标是接近 100%，而不是压低变更次数。
• 主动终止项目数：过去 90 天主动叫停的项目数量。长期为 0 通常意味着机制没有真正生效。

九、写在最后：目标管理的复利在哪里

回到开头那个数字。213 份立项材料里只有 15% 写清了失败判据，这不是文档能力问题，而是组织在立项阶段不愿意为“承认可能失败”付出代价。承认失败的可能，意味着要接受预算被质疑、资源被重新分配、责任被明确。

但恰恰是这一步，决定了一个组织能不能把项目变成可积累的能力。写了失败判据的项目，即使失败也能留下判断依据；没写失败判据的项目，即使成功也说不清为什么成功，下一次只能重新猜。

我见过最有效的做法，不是把目标管得更严，而是把目标管得更可讨论。当“假设不成立了”成为一种正常的工作语言，而不是承认失误，目标管理才会真正开始运转。

如果你的组织现在只能做一件事，我建议做这个：在下一份立项文档里，加一栏“什么情况下我们承认这个项目失败”。这一栏能不能写出来，比任何模板、任何工具都更能说明问题。

下一步可以这样安排：用一周时间给在建项目做目标体检，用一周补齐判据和放弃清单，用一周把目标落到统一平台和固定会议上。如果你所在的组织在 100 人以上、有数据不出内网的要求、并且手上还有大量历史项目数据需要承接，那么在选型阶段就把私有化部署能力和迁移路径作为硬性条件来评估，会比后期返工省下更多时间。