shadow-work

隐形工作

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请先阅读。

如果 .agents/em-context.md 不存在，请先索要一份简要的经理人档案并保存，然后再提供详细建议：职位／职称、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话围绕某个特定人员展开，且 .agents/reports/[name].md 不存在，请先索要该人员的简要档案并保存，然后再提供详细建议：职称／级别、任职时长、优势，以及当前挑战或成长方向。

如果之后的对话揭示了值得长期保留的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和规律，不要保存猜测、短暂的挫败情绪或尚未厘清的解读。

回复风格

首个回答要简洁实用。除非用户要求深入说明，否则不要一次性倾倒整套框架。

默认做法：

• 先说明可能的诊断或建议
• 仅在缺失的背景信息会改变建议时，提出最多 2-3 个有针对性的问题
• 给出下一步具体行动，并在有帮助时提供经理人可直接使用的措辞
• 简要提及相关框架，但不要解释每个部分
• 直接回答后，再提供更深入的版本

---

如何使用此技能

• 团队总是无法兑现承诺，但每个人看起来都很忙 -> 诊断全部三种隐形工作类型，并找出主要的产能消耗来源
• 临时事故和支持请求占用了产能 -> 从类型 1：隐形生产支持开始
• 资深工程师因承担不起眼的协调工作而筋疲力尽 -> 从类型 2：胶水工作开始
• 非正式请求悄悄占用了冲刺容量 -> 从类型 3：隐形待办开始
• 远程团队难以了解成员实际上承担了哪些工作 -> 纳入远程放大效应问题

---

默认回复结构

用户寻求帮助时，不要只解释概念。请给出实用的诊断：

1. 可能的隐形工作类型 - 说明类型，并根据用户提示中的证据标明判断把握程度。
2. 接下来 2-6 周要衡量的内容 - 使用轻量级信号，避免推出繁重的流程。
3. 立即遏制 - 说明本周要采取什么行动，避免团队继续损失产能。
4. 结构性修复 - 说明规划、职责归属、轮值、认可方式或 PM／EM 工作流需要如何调整。
5. 利益相关者沟通话术 - 提供 EM 可用于与 PM、领导层或团队沟通的简洁话术。

如果用户提供的事实不充分，请询问最少量的缺失信息：工作来源、由谁承担、发生频率，以及目前是否有任何记录。

---

什么是隐形工作

隐形工作是指消耗实际产能、却未出现在计划中的工作。它会导致团队持续无法兑现承诺，却没人明白原因。隐形工作分为三种类型，每种都需要不同的应对方式。

关键的管理举措不是“更努力工作”或“更准确地估算”，而是先让这些工作清晰可见，以便团队能够坦诚地权衡取舍。

---

诊断问题

在提出解决方案前，先使用以下问题：

• 来源： 未计划的工作来自哪里：生产环境、其他团队、PM 请求、经理、工程师、客户，还是代码库本身？
• 承担者： 通常由谁处理？分配是否均衡，还是集中在一两位资深人员身上？
• 可见性： 这些工作是否出现在工单、冲刺看板、事故日志、评审文档或绩效评估中？
• 规律： 这些工作是反复出现、季节性发生、特定于项目，还是随机发生？
• 代价： 主要消耗的是日历时间、专注时间、情绪能量、路线图产能，还是晋升认可？
• 取舍： 这些工作出现时，哪些计划内工作会悄无声息地被牺牲？

---

类型 1：隐形生产支持

临时事件分诊、告警调查、支持团队请求、手动修复，以及从未进入工单系统的客户升级处理。

如果不跟踪，就会忽略其中的模式。同一个 15 分钟的手动修复，每年可能耗费数百小时，而根本原因却一直没有解决。团队看似有余力，却持续交付不足，也没有数据说明原因。

该怎么做：

• 为计划外支持工作创建一个轻量级类别，即使只是工单系统中的一个标签也可以
• 跟踪 4-6 周，然后进行频次分析：最常见的重复问题、主要请求来源、承担最多工作的人
• 轮换热修复责任，而不是让某个人长期充当人工断路器
• 将重复的手动修复转化为路线图事项，并明确说明延迟的成本

---

类型 2：协作支撑工作

代码审查、指导、入职培训、文档编写、协调、跨团队沟通，以及“能不能帮他们解决一下阻塞？”之类的工作，往往不成比例地落在资深工程师身上。

如果管理不当，协作支撑工作会带来两个问题：承担这类工作的工程师得不到认可，最终精疲力竭；不承担这类工作的工程师却获得晋升，也没有学会维持组织正常运转的工作。

该怎么做：

• 在绩效沟通和晋升材料中明确提及协作支撑工作
• 通过结对、实时审查会议、答疑时间和轮换负责人，将相关技能传授给更初级的成员
• 资深工程师发挥乘数效应时，保护他们的创造时间
• 跟踪协作支撑工作是否正在成为某个人默认的角色，而非团队共享的能力

---

类型 3：影子待办列表

官方路线图之外的工作：PM 私下提出修复请求、工程师选择自己知道更正确但耗时更长的方案、与其他团队直接协商的计划外集成，以及单独看似乎不多、累积起来却很可观的“小请求”。

这些工作会悄然消耗大量实际产能，同时破坏业务和工程团队之间的信任。领导层只看到团队做出承诺却未能兑现，却看不到产能都花在了哪里。

该怎么做：

• 规划时询问：“我们可能会被要求做哪些尚未纳入范围的工作？”
• 环境充满变数时，明确预留影子产能；如果没有数据，可以先从 10-20% 开始
• 将 PM 私下提出的请求转入官方待办列表，不要让提出请求的人难堪
• 定期向利益相关方展示影子待办列表数据，作为路线图取舍的依据

---

远程办公的放大效应

对于远程团队，影子工作更加隐形：经理也无法随意观察到这些工作。这意味着，在为团队成员争取加薪或晋升时，你没有自然形成的证据；产能被消耗时，也难以清楚掌握情况。

因此，建立轻量级跟踪习惯是管理基础设施，而非额外负担。它能保护团队为实际工作争取认可的能力，也能为 EM 提供产能沟通所需的证据。

---

与利益相关方沟通的话术

使用直接且不带指责的措辞。目的是揭示取舍，而不是责怪工作来源。

与 PM 沟通： “我想让这些请求变得可见，因为它们确实是工作。如果我们继续在待办列表之外处理，就会继续错过计划中的路线图事项，而且我们双方都不会有可靠的数据。我们把它们加到看板上，再决定哪些工作需要让位。”

与领导层沟通： “团队未能兑现承诺，并不是因为估算草率。我们正在承担计划中没有体现的计划外工作。我会在接下来几周跟踪这些工作，然后整理重复出现的来源、成本和可选方案。”

与承担过多协作支撑工作的资深工程师沟通： “我注意到你承担了很多协调和审查工作。其中一部分很有价值，但我不希望这些工作变得隐形，也不希望它们妨碍你承担有助于成长的工作。我们来决定哪些工作应得到认可、轮换承担或停止。”

深入了解

如果用户询问某个框架的出处、想阅读原文，或想了解此技能中任何主题的更多背景信息，请阅读 references/sources.md。

---

相关技能

• roadmap-planning - 在产能规划中应明确为影子工作预留产能，而不是忽略它
• working-with-pm - 私下请求属于 PM 与 EM 的关系问题，而不只是产能问题
• retaining-developers - 高级工程师默默承担看不见的衔接工作却得不到认可，属于留任中的「不受重视」状态
• knowledge-sharing - 衔接工作往往与文档和新员工入职方面的问题重叠