判断团队是否具备工具迁移条件，需要把“能不能迁”拆成人力、技能、时间三类可核验的条件：先按迁移范围估算工作量，再对照可投入人日、关键技能覆盖和日历时间窗，最后给出“满足、需补强、暂不具备”的结论并说明缺口。本文提供一套可复算的评估方法与算例，适用于研发工具替换前的可行性判断。
要点总览（TL;DR）
- 把“能不能迁”拆成人力、技能、时间三类可核验条件，每项都给出公式、单位和分母，结论按“满足、需补强、暂不具备”三档输出。
- 人力看覆盖率：可投入人日 ÷ 迁移工作量人日；技能看覆盖率：已覆盖关键技能项 ÷ 关键技能项总数；时间看余量：日历可用天数 − 关键路径天数。
- 阈值由团队结合风险偏好自行设定，不存在通用达标线；分母为零或数据缺失时记为“未确认”，不直接判为不具备。
- 技能覆盖建议用技能清单加人员自评与主管确认交叉验证，降低自评偏乐观的影响；工作量估算用区间上限复算一次，观察结论是否翻转。
- 结论用于规划与补强决策，需在关键路径各阶段滚动复评，并配合试点验证，不用于绩效评价。
评估目标：要回答的三个可行性问题
评估的对象是本次迁移范围，而非团队的整体能力水平。一个团队在日常研发上人力充足，不代表它能同时抽出人手完成数据梳理、字段映射、权限重建和切换验证；反过来，一个规模不大的团队如果在迁移窗口内集中投入，也可能满足条件。因此，评估开始前要先写清迁移边界：迁哪些项目、哪些工作项类型、哪些附件与历史记录、哪些权限结构、哪些集成点，以及哪些团队参与。
在这个边界内，评估要回答三个问题：
- 人力是否覆盖工作量：在迁移窗口内，团队能实际投入的人日，是否不少于迁移所需的工作量人日。
- 关键技能是否覆盖：迁移涉及的关键技能项，是否都有具备相应经验的人员承担，且这些人员在同一时间段内可被调度。
- 时间窗是否容纳关键路径：从启动到切换完成的日历时间，扣除假期和依赖方等待后，是否足以走完关键路径并留出缓冲。
三个问题的结论合并为三档：满足表示三项条件均达到团队自设阈值，可按计划推进；需补强表示存在明确缺口，但缺口可通过增派人力、外部支持、调整窗口或提前培训补齐；暂不具备表示缺口在现有约束下无法在计划窗口内补齐，应推迟或缩小迁移范围。每档结论都必须附缺口说明，写清缺什么、缺多少、补齐方式与责任人。
指标与范围：人力、技能、时间各看哪些量
三类条件各自需要一组指标，每个指标都要有公式、单位和分母，否则不同人算出的结果无法比较。下表给出建议的指标定义，团队可按迁移范围增删指标项，但口径一旦确定，评估过程中保持一致。
| 类别 | 指标 | 公式 | 单位 | 分母与统计范围 |
|---|---|---|---|---|
| 人力 | 迁移工作量 | 各迁移对象工作量项人日之和 | 人日 | 本次迁移范围内的全部工作项，含梳理、映射、执行、验证 |
| 人力 | 可投入人日 | 参与人员 × 窗口内可投入天数 × 投入率 | 人日 | 仅统计已确认可被调度的人员，投入率按实际可用工时占比 |
| 人力 | 人力覆盖率 | 可投入人日 ÷ 迁移工作量人日 | 比值 | 分母为迁移工作量人日 |
| 技能 | 关键技能项数 | 迁移所需关键技能清单的条目数 | 项 | 按本次迁移范围识别，不含通用办公技能 |
| 技能 | 已覆盖技能项数 | 至少有一名可调度人员具备的技能项数 | 项 | 分母为关键技能项总数 |
| 技能 | 技能覆盖率 | 已覆盖技能项数 ÷ 关键技能项总数 | 比值 | 分母为关键技能项总数 |
| 时间 | 日历可用天数 | 窗口起止日期之间的工作日 − 假期 − 已占用日 | 天 | 按参与团队的实际日历计算 |
| 时间 | 关键路径天数 | 依赖关系最长链上各任务工期之和 | 天 | 含依赖方等待时间 |
| 时间 | 时间余量 | 日历可用天数 − 关键路径天数 | 天 | 余量占关键路径天数的比例即缓冲比例 |
范围界定直接影响分母。迁移对象通常包括工作项及其字段、状态与流程、附件与历史记录、权限结构、集成点五类，每类的处理难度差异很大：字段映射和权限重建往往比数据导出更耗人力。参与团队边界也要写明，例如只统计研发团队，还是包含运维、安全、业务方等依赖方；依赖方不投入人日，但其响应时间要计入关键路径。
数据口径与证据：每项指标从哪里取数
指标算得准不准，取决于取数来源是否可追溯。建议为每项数据标注来源和证据等级，评估结论附上取数记录，便于复核和后续复评。
- 人力数据：可投入人日优先取自排期表或项目计划中的资源分配，其次取工时记录中同类任务的历史投入，最后才用负责人访谈确认。访谈确认的数据标注为“待验证”，在结论中单独说明。
- 技能数据：先按迁移范围列出关键技能清单，例如数据导出与清洗、字段与流程映射、权限模型设计、脚本或接口开发、切换验证与回滚。每项技能由人员自评加主管确认交叉验证，两者一致记为“已确认”，仅有自评记为“待确认”，无人具备记为“缺口”。
- 时间数据：日历可用天数取自项目日历，扣除法定假期、团队已承诺的其他交付和依赖方排期。关键路径天数按任务依赖关系逐项累加，外部依赖方（如安全审批、运维窗口）的等待时间单独列出。
缺失值和估算值要显式标注。例如某项工作量没有历史数据，只能按经验估为“5 人日（估算，误差 ±50%）”，评估时可用区间上限做敏感性检查。分母为零的情况也要写清：如果关键技能项总数为零，说明技能清单尚未识别，应回到范围界定步骤，而不能直接判为满足。
计算与评估步骤：从工作量到三档结论
评估按五步推进，每一步的产物都可复算。
步骤一：拆工作量项并估人日。按迁移对象逐项列出任务，例如“导出并清洗 3 个项目的工作项数据”“映射 40 个自定义字段”“重建 6 类角色的权限”“验证附件完整性”。每项给出人日估算和估算依据，汇总得到迁移工作量人日。估算依据可以是历史同类任务、服务方提供的参考或多人独立估算取中值。
步骤二：计算人力覆盖率。人力覆盖率 = 可投入人日 ÷ 迁移工作量人日。可投入人日按参与人员逐一累加，投入率取实际可用工时占比，例如某工程师在窗口内只有一半时间可投入，按 0.5 计。覆盖率低于 1 说明人力不足，缺口人日 = 工作量人日 − 可投入人日。
步骤三：计算技能覆盖率。技能覆盖率 = 已覆盖关键技能项数 ÷ 关键技能项总数。只统计在迁移窗口内可被调度的人员，具备技能但同期被其他项目占满的人员不计入覆盖。覆盖率不足 1 时，列出未覆盖技能项，作为补强清单。
步骤四：计算时间余量。时间余量 = 日历可用天数 − 关键路径天数。缓冲比例 = 时间余量 ÷ 关键路径天数。缓冲用于吸收估算偏差和依赖方延迟，比例由团队按风险偏好设定，例如关键系统迁移可要求更高缓冲。
步骤五：映射到三档结论。阈值由团队自行设定，不存在通用达标线。一种常见做法是：三项指标均达到自设阈值判为“满足”；任一项未达标但缺口有明确补齐路径判为“需补强”；关键技能存在无人可补的缺口，或时间余量为负且无法调整窗口，判为“暂不具备”。判定规则要在评估前写定，避免算完再调标准。
分母为零或数据缺失时，对应指标记为“未确认”，不直接判为不具备，也不计入达标项。评估结论中单列未确认项及其补数计划。
在评估执行层面，迁移工作量项、责任人和排期可以放在同一套工作项与项目计划中管理，便于把估算人日与实际投入对照。ONES Plan 提供多项目进度管控和资源管理，支持资源报表反馈项目投入情况，并提供项目工时管理，可用于跟踪迁移期间的人力投入与计划偏差；具体能力以实际开通版本为准。
例子：一个20人研发团队的迁移条件测算
以下数值均为演示假设，用于说明公式代入方式，不代表任何行业标准。
假设条件：某 20 人研发团队计划在 6 周窗口内完成一次研发管理工具迁移，迁移范围包括 3 个项目的全部工作项、40 个自定义字段、附件与历史记录、6 类角色权限，以及 2 个集成点。团队可抽调 6 人参与，其中 2 人投入率 1.0，4 人投入率 0.5。关键技能清单共 8 项。窗口内日历可用天数为 26 天，关键路径天数为 22 天。
人力测算：工作量估算合计 96 人日，其中数据导出与清洗 30 人日、字段与流程映射 26 人日、权限重建 14 人日、附件与历史记录校验 12 人日、集成点适配 10 人日、切换验证 4 人日。可投入人日 = 2 × 26 × 1.0 + 4 × 26 × 0.5 = 52 + 52 = 104 人日。人力覆盖率 = 104 ÷ 96 ≈ 1.08，人力满足，余量 8 人日。
技能测算：8 项关键技能中，6 项有可调度人员且经主管确认，1 项仅有人员自评、待确认，1 项无人具备（集成点适配中的接口开发）。技能覆盖率按已确认口径 = 6 ÷ 8 = 0.75；若把待确认项计入则为 0.875。结论按保守口径取 0.75，存在 2 项缺口。
时间测算：时间余量 = 26 − 22 = 4 天，缓冲比例 = 4 ÷ 22 ≈ 18%。若团队自设缓冲阈值为 20%，则时间条件未达标，缺口约 1 天。
结论：人力满足，技能与时间存在缺口，整体判为“需补强”。补齐建议：接口开发技能通过原厂迁移服务或外部支持补位，或提前安排内部培训并调整关键路径；时间缺口通过压缩非关键任务、提前启动依赖方审批或把窗口延长 2 至 3 天解决。补齐后重新计算三项指标，再确认是否转为“满足”。
解读与限制：结论怎么用、哪里会失真
评估结论用于规划与补强决策，不能当作团队能力的定论，也不适合用于绩效评价。使用时注意以下边界。
- 工作量估算偏差会直接改变结论。算例中人力覆盖率 1.08 的余量只有 8 人日，若工作量低估 10%，覆盖率即降至约 0.98。建议对关键工作量项给出区间估算，用上限复算一次，观察结论是否翻转。
- 技能自评容易偏乐观。人员常把“接触过”记为“掌握”。校正方式是要求提供同类任务的实际交付记录，或安排一次小范围试做，以试做结果替代自评。
- 时间条件受外部依赖影响最大。审批、运维窗口、第三方接口联调的等待时间往往被低估。时间余量应在每个里程碑后滚动复评，依赖方排期变化时及时更新关键路径。
- 指标达标不保证迁移成功。三项条件满足只说明资源层面可行，数据质量、功能匹配和切换方案仍需通过试点验证。ONES 的替换方案建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，这与本文的评估逻辑一致：先确认条件，再执行迁移。
建议在迁移启动前完成首次评估，在关键路径上的每个阶段结束后复评一次，并把每次的取数记录和结论留档，形成可追溯的决策依据。
常见问题
团队规模小、人手有限，是否一定不具备迁移条件？
不一定。评估看的是本次迁移范围内的可投入人日与工作量人日的比值，与团队总人数没有直接对应关系。规模小的团队如果在迁移窗口内集中投入、缩小迁移范围（例如先迁核心项目的工作项与字段，附件和历史记录分批处理），人力覆盖率仍可能达到自设阈值。反过来，大团队若同期被其他交付占满，可投入人日也可能不足。判断依据是逐人累加的可投入人日和明确的迁移范围，而非团队人数。
关键技能项怎么列，列多了会不会把门槛抬得过高？
技能清单按本次迁移范围识别，只列迁移过程中必须有人承担的技能，例如数据导出与清洗、字段与流程映射、权限模型设计、脚本或接口开发、切换验证与回滚，通用办公技能不计入。清单过粗会漏掉真实缺口，过细会把门槛抬高。一个可操作的校准方式是：每项技能对应到具体迁移任务，找不到对应任务的条目删去；某项任务找不到对应技能，补进清单。清单确定后，评估过程中保持一致，便于复评时对比。
时间余量算出来是负数，是否只能推迟迁移？
负数说明日历可用天数不足以走完关键路径，先看能否调整约束再下结论。常见做法包括压缩非关键任务、提前启动依赖方审批、把部分迁移对象拆到第二阶段、延长窗口或增加并行人力。如果这些调整能在计划窗口内落地，结论可判为“需补强”并写明补齐方式；如果关键路径上的外部依赖无法提前、窗口也无法延长，则判为“暂不具备”。无论哪种情况，都应把调整后的关键路径重新计算一遍，而不是沿用原数值。
评估结论为“满足”，是否就可以直接开始正式迁移？
“满足”只说明资源层面三项条件达到团队自设阈值，数据质量、功能匹配和切换方案仍需验证。建议先做小范围试点：选取一个有代表性的项目完成迁移与验证，观察实际工作量与估算的偏差、技能短板的实际影响、依赖方响应时间是否符合预期。试点结果可用于修正工作量估算和缓冲比例，再决定正式迁移的排期。ONES 的替换方案也建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。
评估做完后，什么情况下需要重新算一遍？
建议在迁移启动前完成首次评估，并在以下情况触发复评：迁移范围增减（例如新增项目或集成点）、参与人员变动或投入率调整、关键路径上的依赖方排期变化、试点暴露的工作量偏差超过估算区间。复评时沿用同一套指标口径和阈值，把新的取数记录与上次结论并列留档，便于判断结论变化来自条件变化还是估算修正。
