把 Jira 迁移到 ONES 的投入，建议拆成四层来估：范围层锁定项目、问题数、附件量、自定义字段和用户数；工作量层按盘点、映射、试迁移、正式迁移、校验、切换支持分别估人天；外部依赖层列出 Jira 导出权限、网络与部署环境、身份源、附件存储、集成对接方和业务验收人；停机与回退层用切换窗口时长和受影响人数折算业务损失。本文给出可复算的拆解表、口径说明和三档区间算法，帮助预算申报时说明每个数字的来源与假设。
要点总览（TL;DR）
- 先封口范围：项目数、问题单数、附件与评论量、自定义字段与工作流数、活跃用户数五类对象逐行登记，数量以 Jira 后台导出为准，迁移后的流程重构与历史归档清理另行立项。
- 工作量按盘点、映射设计、迁移开发、试迁移、正式迁移、校验、培训、切换值守逐项估人天；外部依赖按 Jira 导出权限、环境审批、身份源对接、附件存储、集成对接方、业务验收人档期逐项标日历天和责任人。
- 总投入用四块相加：内部人天×人天单价＋外部服务或工具费用＋停机损失＋过渡期支持成本；停机损失按切换窗口小时数×受影响人数×人均小时成本折算，业务中断难按人头算时改用积压工单量估算。
- 三档区间的差别落在具体取值上：乐观档对应范围小、映射简单、依赖按期到位；保守档对应字段工作流复杂、试迁移返工、停机窗口受限，缓冲比例随之上调。
- 优先核实高杠杆项：自定义字段与工作流复杂度、附件体量、外部审批周期、停机窗口可接受度、是否保留全量历史数据；用试迁移实测人天替换假设值后再定稿预算。
估算范围与时间跨度怎么定
估算失真的常见起点是范围没有封口：预算按十个项目报，执行时陆续追加到二十个；或者把迁移后的流程重构也算进迁移预算。开始估人天之前，先把“本次迁移”的对象边界写成清单，并明确每一项是否计入。
范围清单建议按对象类别逐行登记，每行写清数量、取数来源和是否计入。项目数、问题单数、附件与评论量决定数据搬运和校验的体量；自定义字段与工作流数量决定映射设计的复杂度；活跃用户数影响培训、账号开通和切换当天的支持压力。这五类对象建议全部登记，数量以 Jira 侧管理后台或系统报表的实际导出为准，不用印象值。
| 对象类别 | 数量 | 取数来源 | 是否计入本次估算 |
|---|---|---|---|
| 迁移项目数 | 待填 | Jira 项目列表，按业务确认的迁移批次 | 计入 |
| 问题单数（含子任务） | 待填 | Jira 过滤器统计或数据库查询 | 计入 |
| 附件容量与评论量 | 待填 | 附件存储统计、评论计数 | 计入 |
| 自定义字段与工作流数 | 待填 | Jira 管理员后台字段与工作流清单 | 计入 |
| 活跃用户数 | 待填 | 近 90 天登录报表 | 计入 |
| 迁移后的流程重构 | — | — | 不计入，另行立项 |
| 历史归档数据清理 | — | — | 不计入，另行立项 |
时间跨度要和人天分开记。日历周期指从启动盘点到最后一批项目切换完成、过渡期支持结束的总时长，受外部依赖方档期和审批节奏影响；人天是实际投入的工作量。两者混在一起，会出现“周期三个月所以报九十人天”这类虚高或虚低的估算。一次性迁移成本（盘点、映射、迁移、校验、切换）与切换后的过渡期支持成本（值守、问题修复、用户答疑）建议分两行列示，过渡期按周计，写明持续几周、每周投入几人。
工作量和外部依赖分别包含哪些项
把投入分成两类：迁移团队自己能推动的内部工作量，和需要其他角色配合、不受迁移团队单方控制的外部依赖。两类分开列，责任归属和风险归属才清楚，排期时也才知道哪些项可以压缩、哪些项只能等。
内部工作量按任务类型逐项估人天，每项写清责任方和前置条件。盘点与映射设计通常由熟悉 Jira 配置和 ONES 目标结构的人承担；脚本或工具迁移、试迁移、正式迁移由技术执行方承担；数据校验需要业务方抽样确认；培训与切换值守由项目管理员和 IT 支持共同承担。每项标注单位（人天或小时），并注明开始前需要满足什么条件，例如字段映射表评审通过后才能进入试迁移。
| 类别 | 条目 | 责任方 | 单位 | 前置条件 | 是否关键路径 |
|---|---|---|---|---|---|
| 内部工作量 | 现状盘点（项目、字段、工作流、用户） | 迁移项目组 | 人天 | Jira 管理员提供只读权限 | 是 |
| 内部工作量 | 字段与状态映射设计 | 迁移项目组 + 业务代表 | 人天 | 盘点清单完成 | 是 |
| 内部工作量 | 脚本或工具迁移开发与调试 | 技术执行方 | 人天 | 映射表评审通过 | 是 |
| 内部工作量 | 试迁移（抽样项目全流程跑通） | 技术执行方 | 人天 | 测试环境就绪 | 是 |
| 内部工作量 | 正式迁移执行 | 技术执行方 | 人天 | 试迁移校验通过、切换窗口确认 | 是 |
| 内部工作量 | 数据校验（数量、字段值、附件、权限） | 业务抽样人 + 技术执行方 | 人天 | 正式迁移完成 | 是 |
| 内部工作量 | 用户培训与操作指引 | 项目管理员 | 人天 | 目标环境配置冻结 | 否，可与校验并行 |
| 内部工作量 | 切换值守与过渡期答疑 | IT 支持 + 项目管理员 | 人天/周 | 切换完成 | 否，切换后发生 |
| 外部依赖 | Jira 侧管理员配合与导出权限 | Jira 管理员 | 日历天 | 权限申请审批 | 是 |
| 外部依赖 | 接口或插件可用性确认 | Jira 管理员 + 工具供应商 | 日历天 | 版本与插件清单确认 | 是 |
| 外部依赖 | 网络与部署环境审批 | IT 基础设施团队 | 日历天 | 部署方案提交 | 是 |
| 外部依赖 | 身份源与单点登录对接 | IT 身份管理团队 | 日历天 | 账号体系梳理完成 | 是 |
| 外部依赖 | 附件存储与容量准备 | IT 基础设施团队 | 日历天 | 附件容量统计完成 | 否，可与映射并行 |
| 外部依赖 | 通知与第三方集成对接方确认 | 各集成系统负责人 | 日历天 | 集成清单梳理完成 | 否，可与迁移并行 |
| 外部依赖 | 业务验收人档期 | 业务部门负责人 | 日历天 | 校验方案确定 | 是 |
关键路径上的项串行推进：Jira 导出权限不到位，盘点无法开始；映射表未评审，试迁移不能启动；业务验收人档期排不上，正式切换只能顺延。附件存储准备、集成对接确认、用户培训这类项可以与主链路并行，排期时把它们放在等待窗口里完成，能压缩总日历周期而不增加人天。外部依赖项建议逐项写明确认方式，例如权限以审批单为准、档期以会议纪要为准，避免口头承诺被当成已落实。
口径与假设怎么写才可复算
同一份估算换个人复算，结果差出一倍，多半是口径没写清。人天按几小时算、日历天怎么换算、费用含不含税、按年还是按月计费，这些都要在估算表前面单独列一张口径说明，每行写取值和依据来源。
| 口径项 | 取值 | 依据来源 | 影响章节 |
|---|---|---|---|
| 人天定义 | 每人天 8 小时，含评审与沟通时间 | 团队工时制度 | 工作量估算、预算公式 |
| 日历天与人天换算 | 按并行度折算，扣除节假日 | 项目排期表 | 时间跨度、阶段分摊 |
| 费用币种与税费 | 人民币，注明含税或不含税 | 采购合同口径 | 预算公式 |
| 席位与计费周期 | 按年计费，席位数量以实际开通账号为准 | 厂商报价单 | 预算公式 |
| 停机窗口 | 是否停机切换、窗口时长 | 业务方确认 | 停机损失折算 |
| 历史数据范围 | 全量保留或按时间截断 | 业务方确认 | 范围清单、迁移工作量 |
费用部分要把两类数字分开写：厂商报价单或合同上的金额标注询价日期和有效期，作为事实价格；用于演示算法的金额明确标为示例假设，不写成实际报价。尚未取得报价的项写“待询价”，不填估计值冒充报价。假设清单至少覆盖三条：迁移工具是自建脚本还是采购工具、是否停机切换、是否保留全量历史数据。这三条各自改变工作量结构，写清楚后，读者替换假设就能重算。
计算模型与预算框架怎么搭
总投入按四块相加：内部人天乘以人天单价，加上外部服务或工具费用，加上停机损失，加上过渡期支持成本。每一块都从前面两张表取数，公式里不出现没有来源的数字。
内部人天来自工作量分解表各行求和；人天单价按团队实际人力成本或外包报价填写，两者口径不同时分开列。外部服务或工具费用包括迁移工具采购、可能的第三方实施服务，按报价单填写。停机损失按切换窗口小时数乘以受影响人数乘以人均小时成本折算；如果业务中断影响难以按人头折算，可以改用切换期间预计积压的工单量或订单量估算，并在假设里写明采用哪种方法。过渡期支持成本按周投入人天乘以持续周数计算。
| 成本块 | 乐观档 | 常规档 | 保守档 |
|---|---|---|---|
| 内部人天 | 范围最小、字段映射简单、一次试迁移通过 | 按分解表基准值 | 字段与工作流复杂、试迁移返工两轮 |
| 外部服务或工具费用 | 自建脚本，无采购 | 采购标准迁移工具 | 采购工具加第三方实施服务 |
| 停机损失 | 非工作时段切换，影响接近零 | 工作时段短窗口切换 | 工作时段长窗口，含回退演练 |
| 过渡期支持 | 2 周，每周 2 人天 | 4 周，每周 3 人天 | 6 周，每周 4 人天 |
| 缓冲 | 5% | 10% | 15%–20% |
三档的差别体现在具体取值上，不是给总数乘系数。乐观档成立的条件是范围小、映射简单、外部依赖按期到位；保守档对应字段工作流复杂、需要多轮试迁移、停机窗口受限的情况。缓冲比例用于覆盖未识别的小项和返工，范围已经封口、试迁移充分时可以取下限。预算按阶段分摊：盘点与映射设计、试迁移、正式迁移与校验、切换后支持四个阶段各自列出人天和费用，便于按季度申请和跟踪执行偏差。
在字段映射和试迁移环节，ONES 侧的工作通常落在目标空间与项目结构搭建、自定义字段与工作项类型配置、状态流转设置上。这些配置的复杂度直接决定映射设计的人天，建议在盘点阶段就用试用环境把目标结构搭一遍，把配置工作量实测出来，而不是按项目数拍脑袋。试迁移后的校验可以按工作项数量、字段值抽样、附件可下载性、权限可见性逐项比对，校验清单本身就是验收依据。
哪些因素最影响估算结果
估算偏差很少均匀分布，通常集中在少数几项上。预算申报前优先核实这几项，比把整张表算得更细更有效。
| 敏感因素 | 影响方向 | 波动幅度参考 | 核实方式 |
|---|---|---|---|
| 自定义字段与工作流复杂度 | 映射设计与校验人天成倍增加 | 字段数翻倍时映射工作量可能增加 50%–100% | 导出字段与工作流清单，逐项标注映射难度 |
| 附件与历史数据体量 | 迁移时长和存储成本上升 | 按附件容量分档，容量翻倍迁移窗口相应延长 | 统计附件总容量与最大单文件 |
| 外部依赖方档期与审批周期 | 关键路径拉长，日历周期增加 | 每项审批按 3–10 个工作日预留 | 提前发确认函，记录承诺日期 |
| 停机窗口可接受度 | 切换方案与损失折算改变 | 工作时段与休息时段切换，损失差异显著 | 与业务方确认可接受窗口 |
| 是否保留全量历史数据 | 范围与成本直接变化 | 按时间截断可减少相当比例的迁移量 | 业务方确认保留年限 |
字段与工作流是最容易被低估的一项：Jira 里长期演化的自定义字段往往带有大量历史值和条件逻辑，映射到 ONES 时需要逐项决定保留、合并还是舍弃，这个决定过程本身就是工作量。附件体量影响的不只是迁移时长，还包括目标环境的存储容量准备，容量不足会在切换前临时扩容，打乱排期。外部依赖的审批周期建议按工作日预留并写进排期表，把等待时间显性化，避免被当成迁移团队的拖延。
各项数据从哪里取、怎么核验
估算表里每个数字都应有来源和责任人，数据更新后能按同一路径重取。取数来源分四类：Jira 侧、ONES 侧、外部依赖方、费用单据。
| 输入项 | 来源 | 责任人 | 核验方式 | 更新频率 |
|---|---|---|---|---|
| 项目数、问题单数 | Jira 管理后台与过滤器统计 | Jira 管理员 | 与数据库计数交叉比对 | 盘点时一次，切换前复核 |
| 字段与工作流清单 | Jira 管理员后台导出 | Jira 管理员 | 映射走查会逐项确认 | 映射设计阶段 |
| 附件容量 | 附件存储统计 | IT 基础设施团队 | 与目标环境容量规划比对 | 盘点时一次 |
| 活跃用户数 | 近 90 天登录报表 | Jira 管理员 | 与身份源账号清单比对 | 切换前复核 |
| 目标空间与字段配置 | ONES 试用环境实测、官方资料 | 迁移项目组 | 试迁移抽样验证 | 映射设计阶段 |
| 环境审批与对接确认 | 审批记录、确认邮件或会议纪要 | 各依赖方负责人 | 以书面记录为准 | 每周跟踪 |
| 工具与服务费用 | 报价单或合同 | 采购负责人 | 标注询价日期与有效期 | 报价更新时 |
核验方法以试迁移为核心：抽取一个有代表性的项目完整迁移一遍，按问题单数量、字段值抽样、附件可下载性、评论完整性、权限可见性逐项比对，记录实际耗时。试迁移的实测人天替换掉估算表里的假设值，正式迁移的估算就有了依据。字段映射走查会邀请业务代表参加，把“这个字段还要不要”的决定当场做完并记录。切换演练按真实窗口计时，测出的时长用于停机损失折算。估算表建议标注版本和更新日期，每次取数变化后重算一次，预算申报时引用最新版本。
常见问题
Jira 里的自定义字段很多，映射工作量怎么估才不至于偏差太大？
先把字段清单导出，逐项标注映射难度，分成三类：直接对应 ONES 已有字段、需要合并或转换、决定舍弃。第二类最耗工时，因为每个字段都要业务代表确认保留与否，还要处理历史值的转换规则。估算时按字段数分档给区间，字段数翻倍时映射工作量可能增加 50%–100%，具体幅度取决于条件逻辑和历史值的复杂程度。建议在盘点阶段就用试用环境把目标结构搭一遍，把配置工作量实测出来，再回填到估算表。
外部依赖方一直不给确认，排期怎么留余量？
把每项外部依赖写成带承诺日期的条目，确认方式以书面记录为准，例如权限以审批单为准、档期以会议纪要为准，口头承诺不计入已落实。排期时按工作日预留审批周期，每项按 3–10 个工作日估算，并把等待时间单独画在排期表上，让等待显性化。附件存储准备、集成对接确认、用户培训这类非关键路径项，安排在等待窗口里并行完成，可以压缩总日历周期而不增加人天。关键路径上的项一旦延期，正式切换日期相应顺延，这个联动关系要在预算申报时说明。
停机损失按人头折算不合适，还有别的算法吗？
可以改用业务量估算：统计切换窗口内预计积压的工单量或订单量，乘以单笔业务的处理成本或延误成本。两种方法选一种并在假设里写明，不要混用。如果业务方接受非工作时段切换，停机损失可以接近零，但要把回退演练的时长算进窗口。窗口时长建议通过切换演练实测，用测出的时长替换估算值，比按经验拍数字更可靠。
试迁移要做几轮，每轮大概占多少人天？
轮次取决于字段映射的复杂度和首轮校验发现的问题量。常规做法是先抽一个有代表性的项目完整跑通，按问题单数量、字段值抽样、附件可下载性、评论完整性、权限可见性逐项比对，记录实际耗时。首轮通过后，正式迁移的估算就有了实测依据；首轮发现映射错误较多时，需要返工映射表再跑一轮。估算表里把试迁移按轮次列，每轮单独给人天，保守档预留两轮返工的量，比在总数上加一个模糊系数更容易向预算评审解释。
迁移工具自建还是采购，对总投入的影响体现在哪？
自建脚本省掉采购费用，但迁移开发与调试的人天要计入内部工作量，后续 Jira 版本变化或字段调整时维护成本也落在团队身上。采购工具把开发工作量换成许可费用，同时可能附带第三方实施服务费。两种方式在预算表里落在不同成本块，比较时要把内部人天折算成金额后与采购报价放在同一口径下看。这条属于假设清单的必填项，写清楚后读者替换假设就能重算总投入。
