每个项目阶段都有其预设的价值定位和关键成果指标（KPI），核心目标是直接服务于该阶段价值定位的 "必做事项"；而额外工作则是超出该阶段预设目标、可能因前期规划不足或突发情况产生的 "补漏事项" 。
判断一项工作是否为 "维护推广阶段的核心价值"，本质上看它是否直接推动了该阶段的核心 KPI（如用户覆盖、使用效率、稳定性）；若被归为 "额外工作"，则可能被认为是 "前期阶段没做好的遗留问题"，而非该阶段的增量贡献。
结合 UI 自动化平台的示例，具体展开：
1. 先明确 "维护推广阶段" 的典型核心目标（基于该阶段的价值定位）
维护推广阶段的核心价值是：让系统从 "能用" 到 "好用、常用"，从 "少数人用" 到 "多数人用"，同时确保大规模使用时的稳定性。因此，核心目标通常围绕 3 个方向：
- 推广层面：扩大用户覆盖（如从 2 个部门到 5 个部门）、提升用户活跃度（如周使用次数从 100 次到 500 次）、降低用户使用门槛（如减少操作步骤、提供更清晰的教程）。
- 维护层面：保障系统稳定运行（如故障发生率从 5% 降到 1%）、快速响应用户高频问题（如问题解决时效从 24 小时缩短到 8 小时）、优化资源消耗（如运行耗时减少 30%）。
2. 核心目标内的工作：直接服务于上述 KPI 的 "必做事项"
这些工作是维护推广阶段 "本就该做" 的事，且能直接体现该阶段的价值增量。
示例 1：跨部门推广中的权限体系优化
- 背景：UI 自动化平台初期仅支持研发部门使用，推广阶段需接入测试、产品部门，但各部门数据权限规则不同（如测试部门需访问用例库，产品部门仅需查看报告）。
- 核心目标相关工作：设计 "角色 - 权限矩阵"，支持 3 类部门的差异化权限配置，解决跨部门协作时 "权限混乱导致无法使用" 的问题。
- 为什么是核心目标：这是 "扩大用户覆盖" 必须解决的问题，直接推动 "用户从 2 个部门扩展到 5 个部门" 的 KPI，属于推广阶段的核心任务。
示例 2：高并发场景下的任务调度优化
- 背景：平台初期用户少（日均 100 次任务），维护阶段用户激增到日均 1000 次任务，出现 "任务排队堵塞，部分任务超时失败" 的问题。
- 核心目标相关工作：重构任务调度模块，引入 "优先级队列 + 资源动态分配" 机制，将任务平均耗时从 10 分钟缩短到 3 分钟，失败率从 8% 降到 1%。
- 为什么是核心目标：这是 "保障系统在用户激增后稳定运行" 的关键工作，直接服务于 "故障发生率降低" 的维护阶段 KPI，属于该阶段必须完成的核心任务。
3. 可能被视为 "额外工作" 的事项：偏离阶段核心目标，更像 "前期遗留问题"
这些工作虽有价值，但领导可能认为 "本该在项目初期（如开发阶段）完成"，而非维护推广阶段的核心产出。 示例 1：底层代码重构（非因用户激增或推广需求）
- 背景：平台底层代码初期写得较乱（无设计模式、注释缺失），但用户少的时候运行没问题；维护推广阶段，负责人觉得 "代码不优雅"，花 2 个月重构了底层框架（未解决任何当前用户反馈的问题，也未提升运行效率）。
- 为什么可能被视为额外工作：重构的核心目的是 "弥补前期代码质量缺陷"，而非解决推广中的用户覆盖问题或维护中的稳定性问题，不属于维护推广阶段的核心目标（该阶段核心应是 "让更多人用好、用稳"，而非 "代码好看"）。领导可能会问："为什么开发阶段不做好设计？"
示例 2：功能补漏（非用户高频需求）
- 背景：平台初期未开发 "用例导出为 Excel" 功能，用户一直没提需求；维护推广阶段，负责人突然觉得 "这个功能应该有"，花 1 个月开发了该功能，但上线后仅 1% 的用户使用。
- 为什么可能被视为额外工作：该功能并非推广阶段 "提升用户活跃度" 的关键需求（用户没高频反馈），也不是维护阶段 "保障稳定" 的必要工作，更像 "前期没考虑全的补漏"，不属于维护推广阶段的核心目标。
总结：如何判断 "是否为核心目标内的工作"？
问自己 3 个问题：
- 这件事是否直接帮助 "扩大用户覆盖、提升用户使用体验"（推广阶段核心）？
- 这件事是否直接解决 "用户激增后的稳定性、效率、资源消耗" 问题（维护阶段核心）？
- 这件事如果不做，是否会阻碍维护推广阶段 KPI 的达成？
如果答案是 "是"，则属于核心目标内的工作；如果更偏向 "弥补前期不足" 或 "优化非关键细节"，则可能被视为额外工作。