managing-urgency

管理紧迫事项

开始之前

首先检查是否有 EM 上下文。如果 .agents/em-context.md 存在，请阅读。

如果 .agents/em-context.md 不存在，请先询问最简经理人档案，并在给出详细建议前保存：职务／头衔、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话中的某个人是核心人物，且 .agents/reports/[name].md 不存在，请先询问此人的最简档案，并在给出详细建议前保存：职务／级别、任职时间、优势，以及当前挑战或成长领域。

如果之后的对话揭示了持久的新上下文，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，而不是猜测、一时的挫折或尚未解决的解读。

回复风格

首次回复应简洁且有用。除非用户要求深入讲解，否则不要一次性列出整个框架。

默认做法：

• 先说明可能的诊断或建议
• 只有在缺失的上下文会影响建议时，才提出至多 2-3 个有针对性的问题
• 给出下一步的具体行动；必要时提供经理可以直接使用的确切措辞
• 简要提及相关框架，但不要解释其中的每个部分
• 先给出直接答复，之后再提供深入版本

---

如何使用此技能

• 刚收到一个不合理的期限，不确定该如何回应 → 收到不合理的期限时（从这里开始）
• 希望主动利用期限来聚焦工作 → 将期限作为工具
• 期限已确定，希望避免执行中的常见陷阱 → 需要避免的 5 个错误

---

默认回复结构

帮助处理紧迫事项时，明确说明取舍：

1. **期限类型：**真实、虚假、有用的约束，还是恐慌所致。
2. **五项检查：**目标、范围、质量、人力配置和工作强度。
3. **选项：**缩小范围、增加人手、接受风险、调整日期或停止其他工作。
4. **建议：**说明较不坏的方案及原因。
5. **利益相关方沟通话术：**说明如何传达取舍，同时避免听起来像在辩解。

回复紧急请求时，绝不要只说“提出异议”。要提供具体的取舍方案。

当你被交付一项不合理的截止期限

在让团队承诺之前，先想清楚以下五个问题：

1. 这个截止期限真的有必要吗？

速度是有代价的：技术债务、糟糕的决策和职业倦怠。每个工程团队都有一个可持续的最佳节奏——大幅超出这一节奏，虽然能更快达到第一个里程碑，却会损害后续的一切。

仔细审视这个截止期限。是谁设定的，依据是什么？它反映的是外部限制（合同、发布或监管日期），还是内部愿望？所有相关人员都了解质量方面的取舍吗？如果这个截止期限确实不可避免，就要准确说明原因——团队知道自己为何而战时，才会投入更多。

2. 谁应该参与这项工作？

人多不一定更快。人数超过少数几人后，协调成本就会超过增加人手带来的收益——尤其是工作紧密耦合时。确定最精简且有效的团队规模。与其把所有人都拉进一场危机，有时不如短期组建一个团队冲刺，同时让其他人维持关键的日常工作。

3. 应该要求大家付出多大努力？

每个人都有自己的生活。要求额外付出的门槛应该很高——而且一旦提出，就必须是认真的。以下原则通常适用：

• 周末工作：只有在公司的成败确实取决于此时才安排，并在之后补休
• 每个人的能力和意愿各不相同——不要假定大家都一样
• 如果业务有可预见的忙碌期（发布、季节性高峰），应在入职培训时说明这些预期，而不是等到危机中途才提

要求大家付出非比寻常的努力时，请高级领导直接出面表示认可——这既能回应大家的疑问，也能表明这些付出得到了关注。

4. 你们走在正确的路上吗？

正常交付可以随着时间推移逐步调整方向。紧急交付则不行——一个小小的错误很快就会不断放大。冲刺期间，你最关键的工作是确保团队以正确的方式做正确的事。

缩短反馈周期。立即让产品经理（PM）和设计团队参与进来。每天都问：哪些内容可以砍掉？哪些内容可以简化？有哪些现成的东西可以复用？在冲刺初期，甚至可以暂时对关键决策进行微观管理——每一个早期选择都会决定后续时间是被锁定还是得到释放。

5. 恢复正常状态后会是什么样？

成功完成紧急冲刺后，领导层可能会认为团队总能以这种方式工作。但事实并非如此。持续处于危机模式会导致人员流失并降低质量。冲刺结束后，你的职责是明确说明：“我们是在特殊情况下交付了这项工作——这不是常态。”在下一个截止期限出现之前，就应设定好这个预期。

---

将截止期限作为一种工具

帕金森定律：**工作会膨胀到填满可用时间。**没有截止期限的项目会比实际所需耗时更长，并不断增加范围。这不是人的缺点——而是开放式时间的一种结构性特征。

实际意义是：在健康的环境中，具有挑战性的截止期限能带来专注和创造力。同样的截止期限，在有害的环境中则会引发走捷径和恐惧。这种工具本身是中性的——结果取决于环境。

一个简单的测试：发送一份没有截止期限的调查问卷，再发送一份内容相同、但要求明天前完成的问卷。回复率和速度会有显著差异。广泛应用这一原则——用于内部评审、设计签字确认和决策周期。

有挑战性的截止期限与不可能完成的截止期限之间，关键区别在于：有挑战性的截止期限要求人们进行优先级排序并集中精力。不可能完成的截止期限则要求人们在重要事项上偷工减料、把人累垮，或者两者兼而有之。判断一个截止期限属于哪一类，是你作为 EM 作出的最重要决策之一。

---

5 个应避免的错误

1. 不告诉团队截止日期之后会发生什么。 当团队了解按时或错过日期的后果时，他们会更努力。如果截止日期是内部设定的，就明确说明这一点，并解释它能带来什么。“不会影响外部，但完成这项工作就能获得 Q3 路线图审批”就是一个值得了解的真实原因。

2. 不让团队参与范围界定。 团队参与评估哪些事项可行时，截止日期的效果最好。你不需要达成共识，但至少要征求意见。一个工程师如果觉得“要是有人问过我，我早就能告诉他们这行不通”，那么在冲刺开始前，他就已经失去了投入感。

3. 为了赶上截止日期而过度施压。 截止日期的目的是聚焦，而不是受苦。出现意外障碍时——外部阻碍、复杂度被低估，或依赖项延期——截止日期应该灵活调整，而不是拖垮团队。偶尔错过一个自定的截止日期，也好过为了守住一个已不再合理的日期而牺牲周末。

4. 施压不够。 这是相反的失误。有些经理为了维持良好关系而避免要求团队付出更多，有时甚至自己承担额外工作，而不是提出要求。这不是保护，而是在逃避。找到恰当的施压程度，正是这份工作的职责。

5. 在范围或日期需要调整时过于僵化。 外部提出调整范围或时间线，并不代表失败，而是带来了新信息。正确的做法是清楚说明取舍，并共同作出决定，而不是出于自尊心为原计划辩护。

---

深入了解

如果用户询问某个框架的来源、想阅读原文，或想进一步了解本技能中的任何主题，请阅读 references/sources.md。

---

相关技能

• delegation — 持续的紧迫感通常是上游委派工作不到位的表现
• working-with-pm — 大多数虚假或错位的紧迫感都源于 PM 与 EM 之间的关系
• roadmap-planning — 不合理的截止日期通常源自规划和范围界定问题