估算 Jira 迁移到 ONES 的投入，建议把工作量、外部依赖和停机成本分成三本账分别计算，再合并成一份预算。三本账要覆盖同一时间跨度，通常包括准备与盘点、试迁移、正式切换、稳定观察四个阶段，并使用同一套人天、自然日、币种与税率口径。这样算出的区间既能向预算方解释，也能在试迁移后回填修正。ONES 可作为迁移目标系统，承载迁移清单、映射表和验收记录。
要点总览（TL;DR）
- 把迁移投入拆成工作量、外部依赖、停机成本三本账，统一覆盖准备与盘点、试迁移、正式切换、稳定观察四个阶段，用同一套人天、自然日、币种与税率口径记录。
- 工作量按“对象数×单对象清洗人天×验证轮次系数”折算，单对象清洗人天来自试迁移实测，验证轮次系数首轮取1.0、后续按0.5–0.7递减。
- 外部依赖分账号与SSO、网络与部署环境、插件与集成对接、原厂或服务商支持四类，每项标注责任方和等待自然日，等待成本按涉及人数与占用比例折算。
- 停机成本=停机小时×受影响人数×单位时间产出损失+切换期效率折损，折损系数建议取0.2–0.4，观察期结束后用实际反馈修正。
- 历史数据与附件规模、字段与工作流复杂度、插件数量、停机窗口长度、外部支持响应速度是影响估算偏差最大的五个变量，优先核实并预留缓冲。
估算范围与时间跨度怎么划定
先回答“这次迁移投入算到哪一步”。范围划不清，工作量容易把后续流程重构算进来，停机成本又可能漏掉切换后的效率折损。建议以“系统可用、核心数据可查、关键流程可走通”作为迁移项目结束标志，把流程重构、二次开发和新的报表体系另立项目。
时间跨度覆盖四个阶段，每个阶段都记录起止日期和计入项：
| 阶段 | 主要任务 | 计入项 | 不计入项 |
|---|---|---|---|
| 准备与盘点 | 导出 Jira 对象清单、梳理字段与状态、确认插件使用情况、组建迁移小组 | 内部人力、外部咨询、盘点工具 | 迁移后的流程重新设计 |
| 试迁移 | 选取代表性项目做全量或抽样迁移，验证字段、附件、权限与历史记录 | 内部人力、原厂或服务商支持、测试环境资源 | 正式环境的许可扩容 |
| 正式切换 | 冻结写入、执行迁移、校验数据、开放使用 | 停机损失、加班人力、应急支持 | 切换后的功能定制开发 |
| 稳定观察 | 跟踪数据一致性、收集用户问题、修正映射遗漏 | 运维人力、支持响应时间 | 新流程培训之外的业务改造 |
观察期建议覆盖切换后 2–4 周。观察期太短，隐藏的数据问题会在项目结算后才暴露；太长，则会把日常运维成本混入迁移投入。观察期内安排专人核对工作项数量、附件可下载率和权限一致性，作为项目关闭的验收依据。
工作量、外部依赖、停机成本各包含哪些项
三本账的清单要能逐项打勾，每项写明责任方和计量单位。责任方不清，等待时间就会被记成内部人力成本，预算看起来省了，实际进度却拖长。
工作量项
- 字段与状态映射：统计 Jira 自定义字段数量、状态与工作流节点，逐项确定目标字段和转换规则，责任方为业务分析师与系统管理员，单位为人天。
- 附件与历史数据：按附件总容量、历史工作项数量估算导出、传输和校验时间，责任方为运维与迁移实施方，单位为人天。
- 权限方案：梳理用户组、项目角色和权限方案，确认 SSO 与账号映射关系，责任方为 IT 管理员，单位为人天。
- 测试与回归：按验证轮次计算，每轮覆盖抽样项目的数据完整性与关键流程可用性，责任方为测试与业务代表，单位为人天。
- 培训：按受训人数和场次估算，责任方为内部推广团队，单位为人天。
外部依赖项
- 账号与 SSO：身份源对接、账号匹配规则确认，责任方为 IT 身份管理团队，单位为等待自然日。
- 网络与部署环境：私有化部署时的服务器、网络策略与安全审批，责任方为基础设施团队，单位为等待自然日。
- 插件与集成对接：梳理 Jira 实际使用的插件，逐项评估在 ONES 中的对应方式。ONES 资料建议先梳理插件使用情况，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，企业已有的定制场景需逐项评估，不能假设所有插件都能一一对应。责任方为业务方与实施方，单位为评估人天加等待自然日。
- 原厂或服务商支持：迁移工具使用、异常数据处理和切换值守的支持排期，责任方为供应商，单位为等待自然日。
停机成本项
- 停机窗口内受影响人数：按切换时段实际在线人数统计，而非全部账号数。
- 业务中断损失：按受影响团队的单位时间产出折算，单位为金额。
- 切换期效率折损：切换后一段时间内用户查找数据、适应新界面的效率下降，按人数和折损天数估算。
口径与假设怎么写才可复算
同一份估算换个人算，结果差一倍，通常不是数据不同，而是口径不同。建议在预算表前附一页口径说明，逐条注明取值和来源。
| 口径项 | 建议定义 | 取值来源 |
|---|---|---|
| 人天 | 按有效工时折算，明确是否包含会议、沟通和管理开销；建议单列 10%–20% 的协调开销 | 团队工时制度与历史项目记录 |
| 金额 | 注明币种、含税或不含税；一次性投入与周期性投入分列 | 合同、发票与财务口径 |
| 席位与计费周期 | 按实际使用人数记录，注明合同周期和起算日 | 采购合同与账号清单 |
| 等待自然日 | 从提出申请到资源到位的时间，不含内部准备时间 | IT 服务台历史工单 |
| 单位时间产出损失 | 按受影响团队的人均日产出折算，注明是否含间接损失 | 业务方提供的估算或财务数据 |
示例假设与现价必须分开标注。例如“按 50 人受影响、每人每天产出折算 800 元”是示例假设，用于演示公式；许可费用、迁移服务报价在未取得正式报价前写为“待询价”，不填入具体数字。ONES 资料提到在同等功能场景下可优化软件采购、运维和服务成本，但未给出金额或比例，预算表中相应行应保留待询价状态。
三本账的计算模型与预算框架
三本账各自有公式，最后按一次性投入和周期性投入汇总，先给区间再收敛。
工作量公式
工作量（人天）= 对象数 × 单对象清洗人天 × 验证轮次系数。对象可按项目、工作项、字段、状态、附件批次分别计数；单对象清洗人天来自试迁移实测；验证轮次系数建议首轮取 1.0，后续每轮按 0.5–0.7 递减，因为重复验证的边际投入下降。
外部依赖公式
等待成本（人天）= 等待自然日 × 涉及人数 × 每日占用比例。等待期间人员并非完全闲置，按实际被占用比例折算，避免把等待时间全部计为损失。四类依赖分别计算后加总，并标注责任方和最早可启动日期。
停机成本公式
停机成本 = 停机小时 × 受影响人数 × 单位时间产出损失 + 切换期效率折损。切换期折损可按“受影响人数 × 折损天数 × 单位时间产出损失 × 折损系数”估算，折损系数建议取 0.2–0.4，并在观察期结束后用实际反馈修正。
汇总框架
| 投入类别 | 计算方式 | 区间下限 | 区间上限 | 备注 |
|---|---|---|---|---|
| 内部人力（一次性） | 各工作量项人天加总 | 按试迁移实测系数 | 加 20% 缓冲 | 含协调开销 |
| 外部支持（一次性） | 服务商报价或待询价 | 待询价 | 待询价 | 不填示例金额 |
| 工具与许可（周期性） | 席位数 × 单价 × 周期 | 待询价 | 待询价 | 注明含税口径 |
| 停机损失（一次性） | 停机公式结果 | 短窗口方案 | 长窗口方案 | 与业务方共同确认 |
| 切换期折损（一次性） | 折损公式结果 | 折损系数 0.2 | 折损系数 0.4 | 观察期后修正 |
在试迁移和正式切换之间，迁移清单、字段映射表和验收记录需要有统一承载位置。ONES 的工作项与文档可以按项目组织这些清单，把每个映射项、验证轮次和遗留问题记录为可跟踪条目，验收时按条目核对，减少口头确认带来的遗漏。
哪些因素最影响估算结果
估算偏差通常集中在少数几个变量上。优先核实这些变量，比全面细化每个小项更有效。
- 历史数据量与附件规模：附件容量大、历史工作项多，会直接拉长导出、传输和校验时间。建议按容量分档预留 15%–30% 缓冲。
- 自定义字段与工作流复杂度：字段数量多、状态流转分支多，映射规则和验证轮次都会增加。建议对复杂项目单独抽样试迁移，缓冲取上限。
- 插件与集成数量：每个插件都需要逐项评估功能匹配方式，定制场景还需开发适配。插件越多，外部依赖等待和评估人天越高，建议按插件数量设置 10%–25% 的额外缓冲。
- 停机窗口可接受长度：窗口越短，越需要提前完成试迁移和增量校验，准备阶段人力上升；窗口越长，停机损失上升。两者需要与业务方共同权衡。
- 外部支持响应速度：原厂或服务商的排期直接决定等待自然日。响应慢的环节应提前锁定时间，并在预算中单列等待成本。
缓冲比例不是统一标准，应结合试迁移结果调整。试迁移中暴露的问题越多，正式切换的缓冲越应取高值。
数据从哪里取、怎么核验
估算要能复算，每个输入都要有来源和核验方式。下表给出常用取数路径。
| 数据项 | 取数来源 | 核验方式 |
|---|---|---|
| 项目数、工作项数、字段数、状态数 | Jira 管理后台导出与报表 | 抽样比对导出清单与界面计数 |
| 附件容量与历史记录范围 | Jira 附件存储统计与数据库记录 | 试迁移后核对附件可下载率 |
| 插件与集成清单 | Jira 插件管理页面与集成配置记录 | 与业务方逐项确认实际使用情况 |
| 许可、税率与计费周期 | 采购合同与财务账单 | 财务复核含税口径与起算日 |
| 停机窗口与受影响人数 | 运维值班记录与业务方排班 | 业务负责人书面确认 |
| 单对象清洗人天与验证轮次系数 | 试迁移实测工时记录 | 用第二轮试迁移回填并修正区间 |
试迁移结果是修正估算的主要依据。完成试迁移后，用实测的单对象清洗人天替换初始假设，重新计算工作量区间；用实际停机演练时长修正停机窗口；用支持响应记录修正等待自然日。三项修正完成后，再向预算方提交收敛后的区间，并注明哪些项仍为待询价或待确认。
常见问题
试迁移应该选多少项目、做几轮，才能让估算收敛？
试迁移的目标是拿到可回填的系数，而非走完流程。建议至少选两类项目：一类字段和工作流最复杂，用来暴露映射难点；一类数据量和附件最多，用来测算导出、传输与校验耗时。轮次上，首轮做全量结构迁移和抽样数据验证，第二轮针对首轮暴露的问题复测并记录实测工时。两轮之后，用实测的单对象清洗人天替换初始假设，重新计算工作量区间，再决定正式切换的缓冲比例。项目数量少但复杂度高时，可以增加抽样比例来补足样本。
停机窗口压得很短，估算上要怎么调整？
窗口缩短，停机损失下降，准备阶段的人力投入会上升。需要提前完成试迁移、增量校验和回滚预案演练，把正式切换压缩成“冻结写入—执行迁移—校验—开放”的短流程。估算时相应提高准备与试迁移阶段的人天，并在外部依赖中提前锁定原厂或服务商的切换值守排期。如果业务方对窗口长度有硬性要求，建议在预算中同时列出短窗口和长窗口两个方案，让决策方看到停机损失与准备人力之间的取舍。窗口长度最终由业务方书面确认，运维值班记录和排班表可作为受影响人数的取数依据。
Jira 插件在 ONES 里找不到对应功能，这部分投入怎么算？
先梳理 Jira 实际在用的插件清单，与业务方逐项确认使用频率和依赖程度，再评估在 ONES 中的匹配方式。ONES 资料建议通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，企业已有的定制场景需要逐项评估，不能假设所有插件都能一一对应。估算上把这项工作拆成两块：评估人天按插件数量计，定制适配按开发工作量另计，并标注责任方。插件越多，评估人天和外部依赖等待越高，建议按插件数量设置10%–25%的额外缓冲。评估结论未出之前，相应预算行保留待确认状态。
观察期设多长比较合适，观察期内的人力算不算迁移投入？
观察期建议覆盖切换后2–4周。太短，隐藏的数据问题会在项目结算后才暴露；太长，日常运维成本会混入迁移投入。观察期内安排专人核对工作项数量、附件可下载率和权限一致性，这些人力计入迁移投入的稳定观察阶段。观察期结束后，用实际反馈修正切换期折损系数，并把遗留问题清单作为项目关闭的验收依据。如果观察期内发现映射遗漏需要返工，返工工时单独记录，不回填到已提交的预算区间，避免区间反复变动。
没有拿到正式报价前，预算表里的许可和服务费用怎么写？
写为“待询价”，不填示例金额。示例假设与现价必须分开标注：用于演示公式的数字（如受影响人数、人均日产出折算）注明是假设，许可费用、迁移服务报价在取得正式报价前保留待询价状态。ONES 资料提到在同等功能场景下可优化软件采购、运维和服务成本，但未给出金额或比例，预算表相应行同样保留待询价。向预算方提交时，把待询价项单独列出并注明预计取得报价的时间，让区间结果中的不确定部分清晰可见。
