预计工期最佳实践：PMO任务属性落地方案，常见问题

2023 年我接手一个 120 人研发组织的 PMO 诊断，翻开工期报表的第一眼就觉得不对劲：任务平均预计工期 4.2 天，实际平均 4.1 天，整体偏差率不到 3%。任何真做过研发管理的人都知道，实验室里都很难跑出这个数字，更别说十几条业务线并行、外包和自研混编的组织。

我去访谈了六个项目组，答案很一致：工期是月底补填的，负责人先看实际做了几天，再倒推一个差不多的预计值填进去。也就是说，这份报表度量的不是预测能力，而是填表人的记忆力和配合度。

这件事几乎概括了"预计工期"在企业里落地失败的全部原因。它不是估算方法问题，甚至不是工具问题，而是任务属性怎么设计、谁来更新、更新之后数据流向哪里的问题。下面我把这套东西拆成可执行的 PMO 落地方案，包括字段设计、粒度、权限、节奏，以及我踩过的坑和七个最常见的误区。

一、先给结论：预计工期要落地，只需要管四件事

开工之前先给结论，避免你读到一半发现方向不对。预计工期作为一个管理对象，落地的成败由四件事决定：属性最小集是否够小、PMO 是否只盯分布、填报摩擦是否低于数据收益、估算与承诺是否分离。这四条只要违背一条，数据就会在两三个月内变成废纸。

1. 工期属性的最小可用集是四个，不是十四个

我在多个组织里见过最长的工期属性清单有十七个字段：乐观工期、悲观工期、最可能工期、计划工期、承诺工期、剩余工期、实际工期、工期偏差、偏差率、工期风险等级、工期置信度……结果是没人填得全，最后所有字段都在月末被同一个人批量补录。

真正驱动决策的属性只有四个：基准工期、当前预计工期、实际工期、剩余工期。前两个回答"应该多久"和"现在看还要多久"，后两个回答"实际用了多久"和"现在还剩多久"。这四个数字一旦同时存在且时间戳清晰，绝大多数管理问题都能被回答。

可选属性只加三个：估算方法、估算置信度、工期偏差率。前两个是分析偏差来源用的，第三个是系统自动算的。除此之外的字段，除非你能说清它会导致哪一个具体动作发生变化，否则一律不加。

2. PMO 的职责是管偏差分布，不是管单个数字

很多 PMO 的日常动作是：看某个任务预计工期 3 天，实际做了 5 天，然后去问负责人为什么超期。这个动作看起来在管控，实际上在制造对立，并且不产生任何组织级收益。

PMO 真正该看的是分布：某个团队 200 个已完成任务里，偏差率的分布形态是什么样？是集中在 ±20% 的窄峰，还是双峰，一半任务严重低估、一半任务严重高估？双峰往往意味着任务类型没有分类，把探索性任务和重复性任务混在同一个池子里统计。

3. 填报摩擦必须低于数据收益，否则数据必然造假

这是我在诊断中最常用的一条判据。一个负责人填报工期属性所花的全部时间，应该小于他从这份数据中获得的好处。如果填报需要 3 分钟，而回报是每次评审会被追问"为什么偏差 40%"，那么理性选择就是填一个接近真实工期的数字。

所以工期属性的落地设计，第一步不是定义字段，而是定义数据回流路径：填了之后，负责人自己能看到什么。我通常要求落地的第一版必须包含一个"我的估算准确度"个人视图，让填报人先受益，再谈组织级统计。

4. 估算与承诺必须分离：基准锁定，预测滚动

把预计工期同时当作"我的最好猜测"和"我对你的承诺"，是这个领域最根本的错配。承诺需要稳定，估算需要随时修正，两者压在同一个字段上，结果一定是：要么没人敢改（失去预测能力），要么随便改（失去承诺效力）。

解法很简单：基准工期锁定，变更走审批；当前预计工期自由滚动，随时可改。两个数字之间的差距，恰好就是项目风险的可视化。

二、为什么 PMO 的工期管理总是失败：三种真实现场

结论说完了，接下来讲它是怎么在真实场景里崩掉的。我把过去几年见过的现场归纳成三种，几乎覆盖了 90% 的失败案例。

1. 现场一：字段齐全，但没人知道填了干嘛

典型特征是制度先于工具落地。PMO 出了一份《任务属性填写规范》，规定所有任务必须填写预计工期、计划开始、计划完成、工作量，且在任务创建时完成。规范发下去第一周执行率很高，第二周开始出现空值，一个月后负责人在群里被通报，于是所有人学会了填写"合理值"。

问题在于，这份规范从未说明数据被谁消费、用来做什么决策。填报人看不到回路，自然按最省力的方式填写。半年后这份数据会呈现出我在开头描述的那种"完美偏差率"。

2. 现场二：数据被用来考核，于是立刻失真

比现场一更危险的情况是，工期偏差率被纳入个人绩效。我见过一个部门把"平均工期偏差率低于 15%"写进了季度考核，结果下一个季度开始，所有任务的预计工期都变成了实际工期的近似值，偏差率降到 6%。

只要一个估算字段被用作考核依据，它就不再是估算，而是博弈的结果。这不是员工不诚信，而是系统设计缺陷。工期偏差只适合做团队级校准指标，不适合做个人级考核指标，团队级指标会驱动经验分享，个人级指标只会驱动数字粉饰。

3. 现场三：工具支持了，但流程没有闭环

第三种情况往往发生在工具能力不错的组织里。项目管理平台里配置了完整的工期字段、自定义工作流、自动计算偏差率，报表也能一键导出。但工期数据在评审会上从来没被投影出来过，唯一的使用场景是季度汇报时截图。

这类组织的典型症状是"数据齐全但决策照旧"。根因是数据没有嵌入任何决策节点。我在落地时会强制设计三个决策点：迭代计划会上看历史偏差分布、周例会上看当前预计工期的滚动变化、里程碑评审上核对基准与预测的差距。只有嵌进会议节奏，属性才会被真正维护。

4. 一个 120 人组织三个季度的观测数据

回到开头那个组织。我们在诊断之后做了一版改造：把工期属性从 13 个压到 4 个必需 + 3 个可选，取消月末批量补录，改为在平台里由任务负责人每周更新一次当前预计工期，并给每个负责人开放个人偏差视图。三个季度后观察到几个变化。

字段填写完整率从 58% 提升到 92%；月末补录比例从 71% 下降到 15%；个人偏差视图的周活跃访问者占到任务负责人的 63%。最有意思的是偏差统计本身，改造前偏差率 3%（不可信），改造后变成 27%（可信），而这个 27% 才真正帮他们改了排期习惯。

数据变"难看"恰恰是治理起效的第一个信号。如果你接手一个 PMO，看到工期偏差率低于 10% 且组织规模超过 100 人，先怀疑数据，不要先表扬团队。

三、落地方案：字段、粒度、权限、节奏

下面进入具体方案。我把它拆成四个维度：字段怎么设计、任务拆到多细、谁有权改、多久更新一次。这四个维度里任何一个缺位，方案都会退化成填表运动。

1. 字段设计：四个必需、三个可选、一个公式

必需字段就是前面表格里的四个。这里补充两点实现细节。第一，基准工期和当前预计工期必须是独立的两个字段，不能在界面上显示成一个"计划工期"然后靠修改历史来追溯，因为绝大多数团队不会去看修改历史。

第二，单位要统一到工作日还是自然日，必须在全组织层面统一。我见过研发用工作日、实施交付用自然日的组织，跨部门汇总时偏差率直接翻倍，而且没人发现原因。建议默认工作日，同时把团队日历（节假日、调休）配置进工具，让系统自动折算。

可选字段三个。估算方法用于分析偏差来源，取值建议限定为类比估算、参数估算、三点估算、专家判断四种。估算置信度取值高、中、低三档，用途是决定要不要加缓冲。工期偏差率由系统计算：

工期偏差率 = (实际工期 – 基准工期) / 基准工期 × 100%
示例：

基准工期 = 8 个工作日

实际工期 = 11 个工作日

工期偏差率 = (11 – 8) / 8 × 100% = +37.5%

注意：分子用基准工期而非当前预计工期，

否则"中途修正预测"会掩盖真实的估算误差。

2. 粒度设计：任务拆到多大，工期才估得准

这是被严重低估的一个变量。我用同一批团队的完成任务做过分布分析，结论是：任务工期落在 3 到 10 个工作日区间时，估算偏差的离散程度最低。低于 1 个工作日的任务，偏差率会被分母放大，1 天变 2 天就是 100% 偏差；高于 20 个工作日的任务，估算依据基本来自直觉，且一旦偏差就是月级别的。

所以拆解规范应该是：任何任务的基准工期不应超过 10 个工作日，超过就继续拆；也不建议低于 0.5 个工作日，太细的任务应该合并到父任务下做估算。这条规范的实际执行效果，比任何估算培训都显著。

3. 权限设计：基准锁定，预测开放，历史留痕

权限是工期属性里最容易设计错的一环。我的方案是三条规则。第一条，基准工期只有项目经理和 PMO 可写，写入即锁定，变更必须走变更单并记录原因。第二条，当前预计工期和剩余工期由任务负责人随时可写，无需审批。第三条，实际工期全部由系统根据状态流转自动计算，任何人不允许手工填写。

第三条经常被忽略，但非常关键。只要实际工期允许手工填写，它就一定会被美化，因为它直接决定偏差率，而偏差率是最容易被感知为"考核"的指标。让系统算，让状态流转说话。

4. 节奏设计：更新频率与校准周期

更新节奏上，我的建议是：当前预计工期每周至少更新一次，且必须在两个触发点强制更新，任务被阻塞超过 1 个工作日时，以及关键路径上的前置任务完成时。剩余工期在每日站会上口头同步，只在变化超过 1 个工作日时才录入系统。

校准周期建议按迭代或月度做。校准不是追责，而是把偏差数据反馈回估算方法：如果一个团队连续三个周期在"接口联调"类任务上低估 40%，那么正确动作是给这类任务增加固定系数或加缓冲，而不是要求大家"下次估准一点"。

四、七个常见误区，逐个拆解

这一节是全文最实用的部分。下面七个误区我在不同组织反复见到，每一个都有明确的识别信号和对应的修正动作。

1. 把工期当工时

工期是日历跨度，工时是投入量，两者是两个正交维度。一个任务 5 个工作日工期、投入 2 个人各 50% 精力，工时是 5 人天，但工期还是 5 个工作日。把它们混在一个字段里，排期和成本核算会同时出错。

识别信号很直接：如果负责人被问"这个任务多久"，他回答"大概 3 天"，接着你问"几个人"，他说"两个人"，这就是典型混用。正确做法是两个字段并存，并在界面上明确标注单位。

2. 把估算当承诺

估算的本质是概率分布，不是单点保证。工程师说"大概 5 天"，真实含义通常是"有 50% 概率 5 天内完成，80% 概率 7 天内完成"。PMO 把这个 5 天当成承诺写进计划，然后按承诺去考核，得到的结果一定是估算被系统性高估。

3. 用故事点当工期

故事点是相对度量，用于团队内部的速率计算，它和日历天之间没有稳定映射，也不应该有。我见过把故事点直接乘以固定系数换算成工期的做法，这在同一个团队短期内勉强可用，一旦跨团队横向比较就会彻底失效。对外承诺的排期必须回到日历天，故事点只留在团队内部。

4. 强制填满所有字段

常见于制度驱动的组织。要求所有任务、所有层级的字段都必须填写，包括那些还在调研阶段、连范围都不清楚的任务。结果是一批随意填写的数字进入数据集，把整个偏差分布污染掉。

修正方式是分阶段启用：先只要求执行中的任务填写，验证三个月后再扩展到规划中的任务。宁可样本小，不要样本脏。

5. 只统计不反馈

PMO 每个月出一份偏差率排名，发到群里，然后没有下文。这既没有让填表人受益，也没有形成改进动作。有效反馈必须包含三样东西：团队自己的分布、偏差集中的任务类型、下个周期建议的调整动作。缺任何一样，数据都会慢慢没人看。

6. 基准工期被随意修改

这是最隐蔽的失真来源。基准工期一旦可以随意调整，偏差率就永远好看，因为它总能向实际值靠拢。我建议在工具里把基准工期做成变更留痕字段，任何修改记录操作人、时间、原因，并在项目复盘时把这些记录拉出来看。

7. 跨项目直接比工期偏差

两个项目的偏差率没有可比性，除非任务类型分布、团队成熟度、需求稳定性都接近。新业务探索项目的偏差天然高于维护型项目，把两者放在一张排名表里，只会让探索型团队被迫隐藏风险。比较应该在"同类任务"维度做，而不是在"项目"维度做。

五、专业判断逻辑：偏差数据如何变成决策

数据收上来之后，真正的难点是怎么判断。这一节给出我实际使用的判断框架，包括三点估算的区间表达、偏差分级和缓冲归属。

1. 用区间代替单点：三点估算的实操口径

我不要求所有任务都做三点估算，那会显著增加填报成本。我的做法是分类型启用：范围清晰的重复性任务用单点估算；范围存在不确定性的任务用三点估算；探索性任务只给区间不给承诺日期。

三点估算的计算口径建议用加权平均而不是简单平均：期望工期 = (乐观 + 4 × 最可能 + 悲观) / 6。这个公式的价值不在于算得多准，而在于强制负责人说出悲观情形，而悲观情形往往才是风险来源。

2. 偏差分级与触发动作

偏差不是一个需要被消除的坏东西，而是一个需要被分级响应的信号。我在方案里通常设三档：偏差在 ±20% 以内，属于正常波动，只需在团队校准会上回顾；偏差在 ±20% 到 ±50% 之间，需要负责人在周例会上说明原因，并判断是否需要调整后续排期；偏差超过 ±50%，触发根因分析，检查是拆解粒度、需求变更还是资源问题。

这里有个反直觉的判断：持续零偏差比持续高偏差更值得警惕。零偏差通常意味着估算是按历史经验倒推的，团队已经放弃了真实预测。我在诊断中看到连续三个周期偏差率低于 5% 的团队，第一反应是去查填报时间戳。

3. 缓冲归属：缓冲属于项目，不属于任务

很多团队的缓冲是被平摊到每个任务上的，每个任务多估 20%。这种做法的问题是，单任务缓冲很容易被"再压一压"，最后总缓冲在乐观情绪中被消耗掉，且没有任何可见性。

正确做法是任务按最可能值估算，缓冲独立汇总在项目级。项目缓冲的消耗率是一个极好的健康指标：消耗超过 50% 而项目进度不到一半，说明风险已经在提前释放，需要立刻干预。

六、以 PingCode 为例：中大型组织的工期属性落地配置

前面讲的是方法，这一节讲工具层面怎么落地。对于 100 人以上、需要私有化部署和国产替代的组织，PingCode 是比较常见的选择，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移。下面是我在实际配置中使用的方案。

1. 工作项类型与自定义属性

第一步是区分工作项类型。不要把需求、任务、缺陷塞进同一个类型，因为这三类任务的工期分布完全不同，混在一起会让偏差统计失去意义。建议按"研发任务""测试任务""缺陷修复""实施交付任务"分别建立类型，每个类型单独配置工期属性的启用规则。

第二步是配置自定义属性。把基准工期、当前预计工期、估算方法、估算置信度做成自定义字段，实际工期和工期偏差率通过公式字段自动计算。属性配置建议用平台的自定义字段能力统一管理，避免各项目各自定义造成口径分裂。

工期属性配置示例（结构示意）
工作项类型：研发任务

├─ 基准工期 数值字段（工作日） 权限：项目经理 / PMO

├─ 当前预计工期 数值字段（工作日） 权限：任务负责人

├─ 剩余工期 数值字段（工作日） 权限：任务负责人

├─ 估算方法 单选 类比 / 参数 / 三点 / 专家判断

├─ 估算置信度 单选 高 / 中 / 低

├─ 实际工期 公式字段 已完成时间 – 实际开始时间（工作日折算）

└─ 工期偏差率 公式字段 (实际工期 – 基准工期) / 基准工期

团队日历绑定：

工作日定义、法定节假日、调休日，用于自然日与工作日互转

2. 从 Jira 迁移时的工期字段映射

对于正在做国产替代的组织，迁移阶段最容易出问题的不是数据量，而是字段语义。Jira 里的 Original Estimate 和 Remaining Estimate 是工时口径，很多人会直接映射到工期字段上，导致迁移后全线偏差失真。迁移前必须先做一件事：把每个工期相关字段的单位、口径、更新责任人列成对照表，再决定映射关系。

迁移字段映射示意
Jira 字段 → 目标字段 说明

Original Estimate（工时） → 预计工时 不可映射为工期

Remaining Estimate（工时） → 剩余工时 同上

Story Points → 故事点 保留为相对度量

Due Date → 计划完成日期 需按团队日历折算

Time Spent → 已用工时 保留原始口径

（无对应） → 基准工期 迁移后由项目经理补录

（无对应） → 当前预计工期 迁移后由任务负责人填写

PingCode 支持从 Jira 平滑迁移，实践中的关键动作是在迁移前清理 Jira 侧的僵尸字段和已废弃工作流，否则这些结构会一起被带过来，迁移后的配置复杂度会大幅上升。我一般建议迁移前先做一轮字段盘点，把使用率低于 10% 的自定义字段直接砍掉。

3. 私有化部署对工期数据管理的实际影响

私有化部署在这个场景下的价值不只是合规。工期数据涉及人员产出和项目节奏，属于比较敏感的内部数据，私有化部署能让组织把它和内部人事、成本系统做更深度的集成，而不必担心数据出域。对于 100 人以上、有多条业务线的组织，这一点在推动"数据回流到决策"时很关键，因为集成门槛降低后，工期数据才有可能真正进入项目健康度看板。

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

同样的方案，在不同规模和成熟度的组织里，落地顺序完全不同。下面按三种维度给出建议。

1. 按组织规模

50 人以下团队：不要上 PMO 级工期管控。只需要在一个工具里维护预计工期和实际完成时间两个字段，靠周会口头同步即可。这个阶段的瓶颈是方向而不是效率，工期数据的边际价值很低。

50 到 200 人组织：这是工期属性落地的黄金区间，也是问题最集中的区间。建议直接采用本文的四个必需属性，先在一个事业部或一条产品线试点，跑满三个迭代再做横向推广。重点建设个人偏差视图，让填报人先受益。

200 人以上组织：必须做口径治理。第一步是统一工作日历和工期单位，第二步是建立任务类型分类标准，第三步才是属性推广。这个规模下最大的风险不是没人填，而是各事业部各填一套，半年后无法横向比较。

2. 按研发模式

以瀑布或阶段门为主的项目：基准工期是最重要的属性，必须锁定并纳入变更管理。建议在里程碑评审时固定核对基准与实际，偏差超过阈值触发变更单。

以敏捷迭代为主的团队：弱化基准工期，强化当前预计工期和剩余工期的滚动更新。故事点保留为团队内部的相对度量，对外承诺日期回到日历天表达。

混合模式：按工作项类型分别设置启用规则，不要用一个统一模板套所有项目。这是很多组织踩过的坑，用一个标准去管两种完全不同的工作方式，结果是两种都不满意。

3. 按数据基础

如果组织此前完全没有工期数据积累，建议从"只记录不考核"开始，先跑两个季度积累样本，再做偏差分析。如果已有历史数据但质量存疑，先做一次数据清洗，把明显补录和倒推的记录标记出来，避免用脏数据校准估算模型。

八、不同情况下的取舍

方案落地时总会遇到取舍，这些取舍没有标准答案，但有明确的判断依据。下面四组是我实际被问得最多的。

1. 估算精度与填报摩擦的取舍

精度提升有边际递减，摩擦增加却是线性的。我的经验阈值是：当填报动作让单个任务的创建时间增加超过 60 秒时，数据质量会开始下降。所以字段设计要以秒为单位审视，每加一个字段都问一次"这个字段值多少钱"。

2. 统一口径与团队自治的取舍

统一口径的好处是可比，代价是团队觉得不贴合自己的实际。我的建议是做分层统一：工期的定义、单位、计算方式必须全组织统一；属性的启用范围、更新频率可以由团队在一定区间内自治。这样既保证数据可汇总，又不至于让团队觉得被套模板。

3. 自动采集与人工填报的取舍

能从系统自动拿的数据不要让人填。实际工期、工期偏差率、状态流转时间这几项完全可以自动算。真正必须人工填的只有一件事：对未来的判断，也就是当前预计工期和置信度。把人工填报压缩到"只有判断类信息需要人填"，是降低摩擦最有效的一招。

4. 私有化部署与 SaaS 的取舍

如果组织规模在 100 人以上、涉及多条产品线、且需要和内部成本或人事系统集成，私有化部署的长期收益通常更大，主要收益来自集成深度和数据可控性。如果团队规模较小、更看重上线速度，SaaS 形态更快。这里的判断依据不是技术偏好，而是你打算把工期数据用到多深：只做报表，SaaS 足够；要进入项目健康度和资源规划，集成能力更重要。

九、常见问题答疑

这一节回答我在咨询和落地过程中被问到最多的问题，尽量给出可直接执行的答案。

1. 预计工期和预计工时到底该填哪个？

两个都要填，但用途不同。预计工期用于排期和交付承诺，回答"什么时候能完成"；预计工时用于容量规划和成本核算，回答"要投入多少人力"。如果只能先上一个，先上预计工期，因为它直接决定跨团队协作的节奏。

2. 任务拆到多细才能估工期？

控制在 3 到 10 个工作日区间，上限不超过 10 个工作日，下限不低于 0.5 个工作日。超出上限的继续拆，低于下限的合并到父任务。这个区间不是理论推导，而是从偏差分布里观察到的经验窗口。

3. 团队不愿意填预计工期怎么办？

先解决回报问题，再解决意愿问题。给任务负责人开放个人估算准确度视图，让他在排期时能参考自己的历史数据；在计划会上引用团队偏差分布来调整排期，让填报人看到数据真的改变了计划。意愿是结果，不是前提。

4. PMO 要不要强制所有任务都填？

不要。强制全量填写会在两个周期内产生大量随意值，污染整个数据集。建议分阶段：先要求执行中的任务填写，跑两个周期验证质量，再逐步扩展到规划中的任务。宁可样本少而可信，不要样本全而失真。

5. 基准工期能不能改？

能改，但必须留痕并说明原因。基准工期的价值在于它是一份可追溯的原始承诺，如果修改没有记录，偏差率就失去了参考意义。建议在工具里把它做成变更留痕字段，复盘时把变更记录一并拉出来看。

6. 敏捷团队还需要预计工期吗？

需要，但用法不同。敏捷团队更需要的是当前预计工期和剩余工期的滚动更新，用于燃尽和容量判断；基准工期在敏捷场景下可以弱化，只在有外部承诺日期时启用。故事点不能替代工期，因为它无法对外表达交付日期。

7. 跨项目的工期偏差能直接横向比较吗？

不能直接比。任务类型分布、需求稳定性、团队成熟度不同，偏差天然不同。正确做法是按任务类型分组后再比较，比如"接口联调类任务"在各部门的平均偏差率，这种比较才具备可操作性。

8. 工期数据可以用来做绩效考核吗？

不建议用于个人考核。一旦与个人绩效挂钩，填报行为就会转向博弈，数据会迅速失去预测价值。工期偏差更适合作为团队级校准指标，用来改进估算方法和缓冲策略，而不是评价个人。

9. 私有化部署对工期数据管理有什么实际影响？

主要影响在集成深度和数据可控性。私有化部署让组织可以把工期数据与内部成本、人事、项目健康度系统做更深度的打通，也便于满足内部数据合规要求。对于 100 人以上、多业务线的组织，这一点在推动"数据进入决策"时往往是决定性的。

10. 没有历史数据，第一次该怎么开始？

先记录，不分析。用一个季度积累已完成任务的工期样本，期间不做任何偏差考核和排名，只保证记录的真实性。季度末做一次分布分析，识别偏差集中的任务类型，下个季度再针对这些类型调整估算方法。

十、总结：预计工期是组织预测能力的入口

回到开头那份"偏差率不到 3%"的报表。它的问题不是数字假，而是整个组织失去了对"未来要多久"这件事的判断力，报表只是把这个事实掩盖了起来。

我在这篇文章里想说的核心判断是：预计工期不是一个需要被填准的字段，而是一套需要被持续使用的决策机制。字段只是入口，真正的价值在于偏差数据有没有回流到排期、有没有改变缓冲策略、有没有让下一次估算比上一次好一点。

如果你的组织正准备落地这套东西，我建议的下一步是：先花一周时间盘清当前工期相关的字段和填写现状，砍掉所有说不出用途的字段；然后选一个 50 到 200 人规模的事业部，用四个必需属性跑满三个迭代；最后拿偏差分布去开一次校准会，看看数据是不是真的改变了什么。三个迭代之后，你会比任何方法论都更清楚自己的组织适合哪一档方案。