工程团队交付激励法

分两个阶段：先诊断原因，再施加激励。

阶段一：诊断（为什么慢）

1. 提问 — 真诚地向工程师/eng manager 了解为什么需要这么久，不带预设议程。他们可能自己也觉得慢，并能指出你可帮忙疏通的障碍。
2. 横向对比 — 与其他团队 PM 交流获取粗略 benchmark。现代工程组织有大量必要流程（manual QA、code review、unit test、架构评审、新服务上线），这些长期来看是加速而非减速的。
3. 做 post-mortem — 项目结束后（尤其 missed deadline 时）做复盘，关键是抱着学习动机而非追责。
4. 重新审视 deadline 用法 — 如果 deadline 是任意的，就坦诚说 "Let's come up with an arbitrary deadline!"。Deadline 的价值在于：让跨职能团队围绕统一日期协调、配合业务其他环节（sales training、CX rollout 等）、创造一定问责感。
5. 硬/软 deadline 交替 — 不是所有 deadline 都同等重要。软 deadline 时鼓励团队练习估算能力，以便硬 deadline 时能准确。

阶段二：激励（确认团队确实可以更快后）

1. 连接个人动机 — 了解每个人的个人目标（晋升、创业、转管理），帮他们看到当前工作与目标的关联。
2. 连接更高使命 — 在团队会议、kickoff、1-Pager、deck、1:1 中明确日常工作如何服务于公司使命。
3. 与他们的 manager 结盟 — PM 只能靠影响力，改变行为最有效的伙伴是对方的 manager。先建立关系和共识，再一起推动改变。
4. 确保真正的 buy-in — 团队成员是否真的承诺了这些日期？设 timeline 时问他们预估多久，可以偶尔 push back 但主要信任他们，然后基于直接估算排序、确认、锁定、广泛同步。
5. 对齐激励机制 — 包括：将业务影响反映到绩效评估中；公开庆祝按时交付者（但不要惩罚未达标者，否则会 padding deadline 或交付劣质代码）；明确按时交付带来更多自主权；财务激励（晋升、spot bonus）；同侪压力（让团队和客户失望不好受）。
6. 对齐热情 — 尽量让人做自己感兴趣的事，包括建立 mastery（ML、React、growth 等）或填补晋升所需的技能缺口。
7. 对齐技能 — 有时慢是因为做的人在学新东西。让 senior 成员帮助加速 ramp up。
8. 用 Sprints — 如果估算周期太长，切换到只需估算两周的敏捷流程。
9. 有新信息就改 deadline — 发现意外障碍时，正式重置日期、重新获取 buy-in、广泛同步，而不是硬挤。
10. 必要时换人 — 尽力之后仍无法交付，且已明确沟通 underperformance，放手对双方都好。