StatusPath Reports使用指南
如何跨多个地区统计 Jira 工作流时间
跨地区统计 Jira 工作流时间时，每次运行应选择三种单 Calendar 政策之一：共享服务 Calendar、负责人地区范围加一个 Calendar，或客户地区范围加一个 Calendar。如果决策需要保留多套地区定义，应使用拆分报表策略，为每个地区分别建立范围和 Calendar。每次运行或每个 Saved Report 只有一个所选 Calendar；StatusPath 不会按行、工作项、Assignee、Reporter、客户或地区动态映射 Calendar。
先选择一套 Calendar 政策，或拆分报表
同一段 Jira 历史可能产生多个正确的工作时间结果，因为每个 Calendar 回答的问题不同。下表前三行是单次运行可选择的三种单 Calendar 政策；第四行是创建多次独立运行的策略，不会让一份报表同时使用多个 Calendar。
| 政策 | 回答的问题 | 所需范围 | 使用的 Calendar | 可比性 | 维护成本 | 不应使用的情况 |
|---|---|---|---|---|---|---|
| 共享服务 Calendar | 有多少时间落在同一套全球服务或交付承诺内？ | 完整且经过约定的服务总体 | 一套已批准的共享服务 Calendar | 只有所有结果采用同一服务政策时才有强可比性 | 低：维护一套 Calendar 和范围定义 | 不要用它代表各地区实际值守覆盖 |
| 负责人地区政策 | 有多少时间落在某一归属地区的值守时段内？ | 每次运行只含一个负责人地区的 cohort，通过 Project 或 Saved Filter/JQL 建立 | 该 cohort 的一套地区 Calendar | 只比较采用同一归属规则和报表设置的 cohort | 中：每个地区维护范围和 Calendar | 不要用于混合地区的单次运行，也不要期待 Assignee 变化在工作项内部切换 Calendar |
| 客户地区政策 | 有多少时间落在明确客户或市场的服务时段内？ | 每次运行只含一个明确客户地区的 cohort，通常由 Jira 字段和 Saved Filter/JQL 建立 | 该 cohort 的一套客户地区 Calendar | 只比较等价的客户政策和对齐的报表设置 | 中到高：维护地区字段、范围和 Calendar | 不要根据查看者或当前 Assignee 推断地区 |
| 分地区独立报表 | 多个分别定义的地区视图各自显示什么？ | 每份地区报表有一个独立范围 | 每份报表保存一套 Calendar | 只有各报表回答同一政策问题时才可比较；范围重叠的结果绝不能相加 | 高：维护多份 Saved Report、Calendar 和 cohort 规则 | 真正需要的是一套共享服务答案时不要拆分 |
日历与时长文档说明了当前 Calendar 控件、工作时段、时区、例外日期和受影响的时长报表。Saved Report 保存一个所选 Calendar ID，不包含根据每一行、工作项、Assignee、Reporter、客户或地区自动选择 Calendar 的规则。因此，多套 Calendar 必须通过多次报表运行实现。
Jira 看板工作日与报表日历是不同设置
Atlassian 的配置工作日页面说明了公司管理型看板设置，该设置用于指定的 Jira 原生报表和小组件，并包含工作日、非工作日期和看板时区。
Jira 还有展示时区设置。用户可以在 Jira 个人设置中选择 Jira 应用展示日期和时间所用的时区；Jira 管理员也可以设置默认用户时区，用户可以覆盖该默认值。
这些 Jira 设置不会自动选择或改写 StatusPath Calendar。比较涉及日期边界或工作时间时，应分别记录 Jira 看板设置、Jira 展示时区和所选 StatusPath Calendar。
可复现 Jira 场景：一次全球支持交接
工作项 SR-5101 在 2026-07-06 06:00Z 进入 In Review，并在 2026-07-07 15:00Z 离开。两个时间戳相差 33 个自然小时：
星期一 06:00Z → 星期二 06:00Z = 24h
星期二 06:00Z → 星期二 15:00Z = 9h
自然时间合计 = 33h
受控对比保持工作项、In Review 区间、完整历史窗口和 Decimal Hours 格式不变。三套 Calendar 都采用周一至周五 09:00-17:00，且没有节假日或例外；只改变 IANA 时区：
| Calendar | IANA 时区 | In Review 本地区间 | 工作排班 | 计入工作时间 |
|---|---|---|---|---|
| 共享 UTC | UTC |
星期一 06:00 → 星期二 15:00 | 周一至周五 09:00-17:00 | 14h |
| 上海 | Asia/Shanghai |
星期一 14:00 → 星期二 23:00 | 周一至周五 09:00-17:00 | 11h |
| 纽约 | America/New_York |
星期一 02:00 → 星期二 11:00 | 周一至周五 09:00-17:00 | 10h |
这三个结果是三套政策下互为替代的答案，不是三段工作量。每个数值都是同一 Jira 区间与一套不同书面运营排班的交集。它们可以用于验证政策敏感性，但不能相加，也不能作为地区绩效进行比较。
原始时间戳是 UTC 时刻：2026-07-06T06:00:00Z 至 2026-07-07T15:00:00Z。下表列出了完整的逐行人工复算。三套 Calendar 都以周一至周五为工作日，每天只有一个本地 09:00-17:00 工作时段，节假日与 exceptions 列表均为空。
| Calendar | 本地日期 | 当日 Jira 区间 | Calendar 工作时段 | 实际计入交集 |
|---|---|---|---|---|
共享 UTC（UTC） |
2026-07-06 周一 | 06:00-24:00 | 09:00-17:00 | 09:00-17:00 = 8h |
共享 UTC（UTC） |
2026-07-07 周二 | 00:00-15:00 | 09:00-17:00 | 09:00-15:00 = 6h |
上海（Asia/Shanghai） |
2026-07-06 周一 | 14:00-24:00 | 09:00-17:00 | 14:00-17:00 = 3h |
上海（Asia/Shanghai） |
2026-07-07 周二 | 00:00-23:00 | 09:00-17:00 | 09:00-17:00 = 8h |
纽约（America/New_York，UTC-04:00） |
2026-07-06 周一 | 02:00-24:00 | 09:00-17:00 | 09:00-17:00 = 8h |
纽约（America/New_York，UTC-04:00） |
2026-07-07 周二 | 00:00-11:00 | 09:00-17:00 | 09:00-11:00 = 2h |
共享 UTC 结果：14 个工作小时
在共享 UTC Calendar 下，星期一贡献完整的 8 个工作小时，星期二贡献 6 小时：
星期一 09:00-17:00 = 8h
星期二 09:00-15:00 = 6h
共享 UTC 合计 = 14h
上海结果：11 个工作小时
在 Asia/Shanghai 时区中，该区间是星期一 14:00 至星期二 23:00。星期一贡献最后 3 个工作小时，星期二贡献一个完整工作日：
星期一 14:00-17:00 = 3h
星期二 09:00-17:00 = 8h
上海合计 = 11h
纽约结果：10 个工作小时
在 2026 年 7 月 6 至 7 日，IANA America/New_York 时区按夏令时规则把这些时间戳解析为 UTC-04:00，因此本地区间是星期一 02:00 至星期二 11:00。星期一贡献 8 个工作小时，星期二贡献 2 小时：
星期一 09:00-17:00 = 8h
星期二 09:00-11:00 = 2h
纽约合计 = 10h
三次运行分别与各自政策核对一致：共享 UTC 为 14h，上海为 11h，纽约为 10h。它们是同一底层区间的三个互斥答案。不要相加、静默替换，也不要把它们作为地区绩效进行比较。只有当每份报表回答同一政策问题，并且范围规则及其余设置对齐时，运营层面的地区比较才成立。
配置可复现的多地区报表
- 先写出决策。 选择一套单 Calendar 政策：共享服务、负责人地区范围或客户地区范围。只有需要分别运行地区报表时才使用拆分报表策略。
- 定义 Jira 范围。 当 Project 本身就是范围时使用 Project；否则使用引用明确 Jira 地区字段的 Saved Filter 或 JQL。地区字段不是独立的 StatusPath 范围控件。不要从查看者时区推断地区。
- 创建并验证 Calendar。 记录每个 Calendar 的 IANA 时区、工作日、每日时段、节假日和例外；大范围使用前先核对一个普通工作日。
- 运行第一套政策。 选择一个 Calendar，保持 Decimal Hours 和完整历史窗口，运行 Time in Status，并人工核对
SR-5101。 - 保存命名配置。 在 Saved Report 名称中写入政策和地区。每个 Saved Report 保存一个 Calendar，不会按行、工作项或 Assignee 映射日历。
- 区分验证与运营。 验证 Calendar 敏感性时，保持同一工作项并且只切换 Calendar；使用运营拆分报表策略时，为每个地区分别建立范围和 Calendar，并记录范围与 Calendar 都发生了变化。
- 只比较对齐的问题。 在每个数值旁保留政策、Calendar 名称、时区、范围和运行日期。不要跨政策比较结果，也不要把 Calendar 差异解释为地区生产力排名。
如果工作项在保持 In Review 的过程中跨地区交接，应预先决定指标始终采用一套服务日历，还是通过分别限定范围的报表回答运营问题。单次 StatusPath 运行不会拆分同一区间，并在每次 Assignee 变化时动态应用新 Calendar。
常见错误
让查看者的 Jira 时区决定指标
Jira 展示时区用于呈现日期和时间，并不定义 StatusPath 时长报表应计算哪套运营工作时间。
期待逐工作项自动选择 Calendar
StatusPath 对本次报表运行应用所选 Calendar。Reporter、客户、当前 Assignee 和 Assignee 历史都不会自动切换该 Calendar。
同时改变范围和 Calendar
如果工作项范围和 Calendar 同时变化，就无法把结果差异归因于 Calendar。每次只改变一个输入。
把替代政策结果相加或排名
14h、11h 和 10h 是同一 Jira 区间在三套替代政策下的结果。三者之和不代表自然时间、投入工时、吞吐量或唯一归属时间，数值排序也不代表地区绩效排名。
用固定 UTC 偏移替代地区时区
America/New_York 会在夏令时边界改变偏移。应使用目标 IANA 时区，并在适用的时钟切换附近验证已知区间。
常见问题
全球 Jira 团队应该使用哪一种 Calendar 政策？
没有适用于所有团队的最佳政策。全球统一承诺可使用共享 Calendar；值守时间可使用运营地区 Calendar；明确的客户承诺可使用客户地区 Calendar；需要地区对比时则分别运行报表。
StatusPath 可以根据每个工作项的 Assignee 或客户选择 Calendar 吗？
不可以。每次报表运行或每个 Saved Report 使用一个 Calendar。需要不同地区 Calendar 时，应建立明确的 Jira 范围并分别运行。
Jira 个人时区等于 StatusPath Calendar 时区吗？
不等于。Jira 个人时区控制 Jira 应用中的日期时间展示；所选 StatusPath Calendar 定义工作时长计算纳入的工作时段。
同一个工作项可以出现在多份地区报表中吗？
可以，但应限于受控的政策敏感性检查。必须标记范围重叠，不能把结果相加或排名并当作不同工作项。用于运营地区比较时，每份拆分报表必须采用同一政策问题和明确的范围规则。
应该如何处理夏令时？
使用 America/New_York 等 IANA 地区时区，而不是固定偏移。在时钟切换前后各验证一个已知区间，并在跨周期比较旁保留 Calendar 版本。
相关指南
- Jira 工作流报表 Business Calendar 指南
- 如何为 Jira 状态报表配置工作时间和节假日
- 时区如何影响 Jira 状态时长和趋势报表
- 如何统计 Jira 工作项在不同负责人名下的停留时间
在每个地区结果旁保留政策
只有同时保留问题、范围、Calendar、时区和比较规则，多地区时长才可解释。前往 Atlassian Marketplace 试用 StatusPath Reports，分别运行命名清晰的地区配置，核对一个区间，并把所选政策与每个结果一起保存。