eol-checklist

EOL 检查清单

目的

将退役决策转化为按阶段设定关卡的执行计划：必须完成哪些事项、在哪个生命周期阶段完成，以及由谁负责。输出应是一份可执行的检查清单——每项内容都像一张便利贴那么简短，包含一个动词和一个明确的职能负责人——而不是策略文档。

检查清单的规模应与退役范围相称。 退役一个已弃用的内部工具，可能需要跨三个阶段列出十几项任务；退役一条受监管的硬件产品线，则可能需要跨六个阶段制定跨职能操作手册，并在阶段之间设置关卡标准。两种做法都正确；用错规模才是问题所在。

输入

最适合提供： 正在退役的产品，以及已承诺的任何日期。

也很有帮助： 客户和营收规模、是否有替代产品及其准备情况、合同或监管义务，以及是否涉及硬件、库存或渠道合作伙伴。

在调用时一并提供的任何内容——技能名称之后的文本、粘贴的上下文内容，或附加的 ARGUMENTS: 行——都视为已给出的答案。请利用这些信息，跳过其中已经涵盖的问题；不要重复询问。

手头没有信息？也没关系。 该技能最多会提出三个问题——要退役什么、规模多大，是否有替代产品，以及有哪些硬性截止日期——然后选择一个级别并开始制定计划。未知信息会标记为假设，而不会成为阻碍。

调用示例：

• 为我们的旧版报告模块制定 EOL 检查清单，将于 12 月 31 日关闭，约涉及 400 个账户。
• 为硬件退役制定一份详尽的检查清单——服务合同、8 家经销商、通过 UL 认证。

---

核心概念

先确定合适的规模

并非所有 EOL 流程都相同。 大多数情况介于两者之间。请有意识地选择级别：

	级别 1 — 轻量	级别 2 — 标准	级别 3 — 详尽
典型范围	功能、内部工具、未版本化的 API	商业产品、现有客户	营收关键型产品、硬件、受监管产品
使用阶段	2-3 个（NSC、EOS、EOL）	4-5 个（NSC、EOS、EOE、EOM、EOL）	全部 6 个（NSC 至 EOSRV）
职能领域	4 个	11 个	15 个
关卡标准	不需要	在主要阶段之间设置	每个阶段之间设置，并指定审批人
输出形式	待办事项清单	含负责人和日期的执行清单	跨职能操作手册

级别 2 是默认选项。 推荐一个级别，并用一句话说明原因，同时让用户可以调整。如果用户选择更轻量的方案，请指出因此省略的具体领域，确保用户了解这一选择的影响。绝不要默认选择级别 3——对轻量级退役采用详尽的检查清单，会让团队觉得 EOL 流程只是走形式；下次真正需要时，他们就会跳过流程。

制定过程中可以随时更改级别。法务行揭示了某些问题后，听到“其实，把这份清单做得更全面一些”很正常。

生命周期关卡

• GA（General Availability）： 正在积极销售并提供全面支持
• NSC（Notice of Status Change）： 已传达决策；开始规划
• EOS（End of Sale）： 不再接受新客户购买
• EOE（End of Expansion）： 现有客户无法增加容量或席位
• EOR（End of Renewal）： 不再续签现有合同
• EOM（End of Maintenance）： 停止提供错误修复和补丁
• EOL（End of Life）： 产品退役
• EOSRV（End of Service）： 所有支持和服务义务终止

哪些关卡会成为检查清单阶段： GA 是一种状态，而非需要开展工作的阶段——因此不会列入检查清单。EOR 由合同决定，仅在涉及续约时才会出现。因此，执行清单通常涵盖六个可执行阶段：NSC、EOS、EOE、EOM、EOL、EOSRV；如果订阅或服务合同的期限晚于 EOS，则插入 EOR。

说明哪些关卡不适用，与说明哪些关卡适用同样有用。 级别 1 的检查清单应注明：“EOE 和 EOSRV 不适用——没有需要扩展的内容，也没有需要服务的对象。”

十五个职能领域

按级别筛选。括号中标明各领域首次出现的最低级别：

领域	级别
产品与战略	1
工程与技术	1
支持	1
文档与培训	1
法律与合同	2
财务规划	2
销售	2
营销	2
客户成功	2
IT 系统	2
数据管理	2
库存与供应链	3
渠道与合作伙伴管理	3
监管与合规	3
内部组织协同	3

便利贴规则

每个事项都应为 4 到 8 个词，包含一个动词，并指定一个明确的负责人（职能部门，而不是某个人的日程安排）。“法务审查合同”是一项事项。“确保面向所有客户妥善审查所有相关合同义务”则是一段披着复选框外衣的文字。

**负责人必须明确的原因：**没有负责人的事项只是愿望。要求每一行都指定一个职能部门，可以及早发现跨职能协作中的空缺——当你说不清谁负责“通知渠道合作伙伴”时，就已经发现这件事根本没人负责。

阶段关卡是承诺，不是日期

阶段关卡是指进入下一阶段前必须满足的条件，并且要指定审批人。“EOS 到 EOE：最后采购订单已关闭——审批人：销售副总裁。”这能防止 EOL 仅仅发布公告，六个月后又有人悄悄拔掉插头。

反模式（这不是什么）

• **不是项目计划。**没有甘特图、依赖关系图或资源分配。
• **默认不求面面俱到。**覆盖范围应与风险相称，而非追求繁文缛节。
• **不是决策本身。**如果是否要停止服务仍未确定，现在制定清单还为时过早。
• **不能替代沟通。**清单上写着“与法务协同”，并不代表已经与法务达成协同。

---

应用

步骤 1：确定级别

根据影响范围（客户、收入、合同、硬件、合作伙伴）提出建议，然后列出全部三个级别供用户选择。如果确实无法确定级别，请询问：

“这次停止服务有多复杂？

1. 轻量——某项功能、内部工具或未版本化的 API。用户较少，且都能联系到。
2. 标准——拥有付费客户和合同的商业产品。
3. 重型——对收入至关重要、已有硬件投入使用、有渠道合作伙伴，或受监管。

大多数停止服务属于标准级。哪种情况更符合你的需求？”

步骤 2：选择适用阶段

将级别对应到各阶段，然后检查以下两项例外情况：

• **合同期限是否晚于 EOS？**加入 EOR。
• **是否完全没有服务义务？**移除 EOSRV 并说明原因。

如果日期确实未知，请写 TBD；如果目前不应设定日期（尚无迁移路径），请写 Not scheduled，并添加一项，明确指出前置条件。捏造一个 EOL 日期，就是许下一个你会在公众面前违背的承诺。

步骤 3：按阶段和领域制定事项

对于每个适用阶段，逐一检查该级别要求涉及的职能领域。每项事项都应：

• 以动词开头
• 包含 4 到 8 个词
• 指定一个负责职能部门
• 只属于一个阶段——也就是实际开展工作的阶段，而不是宣布工作的阶段

至少涵盖停止服务时最常被遗漏的四件事：

1. 数据——导出格式、可用期限、删除计划
2. 合同——续约条款、SLA 条款、应付退款或抵扣
3. 访问权限——API 密钥、集成、SSO、读取相关数据的下游系统
4. 资金——预测调整、收入确认、停止服务本身的成本

步骤 4：编写关卡标准（级别 2+）

对于每个阶段转换，列出必须满足的条件以及签字批准的人。每个关卡列出三到五项标准就足够了。如果无法指定审批人，这个关卡就不是真正的关卡。

步骤 5：EOL 后续行动与假设

务必简要列出 EOL 后续事项——归档、最终报告和经验复盘。 复盘是团队最先砍掉、也最常后悔砍掉的环节；有人记录下这次过程中哪些地方出乎意料，下次退役时就会顺利得多。

最后列出待验证的假设——明确写出步骤 1 中的每一项未知信息。

最后一步：提供后续选项

“接下来做什么？

1. 规划利益相关方沟通——要和谁谈，以及按什么顺序谈（推荐）
2. 起草客户公告——参见 eol-message
3. 制作内部赋能资料包——支持 FAQ、销售沟通要点、异议处理
4. 将其转换为带日期的时间线——为每个阶段标注日历日期

请回复一个编号、组合（如‘1 和 3’），或提出你自己的方案。”

---

示例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS，级别 2，五个阶段）
• examples/sample-industrial.md — NFA-200 控制器产品线（工业，级别 3，六个阶段，并有意不标注 EOL 日期）

---

常见陷阱

陷阱 1：流程仪式化

症状： 每次退役都采用包含 15 个领域、六个阶段的操作手册，因为这样“更全面”。

后果： 团队会觉得 EOL 流程只是走过场，下次就完全跳过——而下一次涉及的正是那些合同。

解决办法： 有意调整流程规模。有人实际使用的级别 1 清单，胜过被束之高阁的级别 3 清单。

---

陷阱 2：事项无人负责

症状： “确保客户数据已导出。”负责人：空白，或“团队”。

后果： 每个人都以为有人会负责。到了关停那天，却发现谁都没负责。

解决办法： 每项都要指定一个职能负责人。如果无法指定，这本身就是问题——应当上报，而不是掩盖过去。

---

陷阱 3：凭空编造日期

症状： 因为清单模板里有日期空栏，就写下了 EOL 日期。

后果： 你宣布了日期，却发现迁移路径并不存在，只好推迟。按第一个日期做了安排的客户，将不再相信第二个日期。

解决办法： Not scheduled 是合理的填写内容。还应同时列出允许安排日期的前置条件。

---

陷阱 4：阶段合并

症状： 所有事项都被塞进一个名为“EOL”的阶段。

后果： 你在同一天停止销售、停止支持并关停服务。客户感受到的就是一次提前通知过的服务中断。

解决办法： 将各个关卡分开。停止销售成本低、时间早；停止服务成本高、时间晚。

---

陷阱 5：忘记下游使用方

症状： 清单涵盖了产品及其客户，却没考虑到有四个内部系统在悄悄调用它的 API。

后果： 产品按计划退役，第二天早上却导致三个仪表板、一个计费任务和一个合作伙伴集成发生故障。

解决办法： IT 系统和数据管理领域就是为此而设的。即使是级别 1，也要至少问一次：有哪些系统在读取这些数据？

---

参考资料

相关技能

这些技能都可以独立使用——它们不是本技能的前置条件，本技能也不是它们的前置条件。如果你已在其他地方选定了级别，只需说“级别 2”，本技能就会据此制定方案；无需移交任何材料。

• eol-readiness-advisor — 如果还需要论证是否做出退役决定，或希望由它为你推荐级别
• eol-stakeholder-sequence — 与谁沟通，以及何时沟通
• eol-internal-enablement — 为面向客户的团队做好准备
• eol-message — 面向客户的公告

外部框架

• 行业 EOL 生命周期实践（GA/NSC/EOS/EOE/EOM/EOL/EOSRV）
• RACI — 用于为每项任务指定负责人

来源

• 改编自 prompts/eol-checklist.md，源自 https://github.com/deanpeters/product-manager-prompts 仓库。