2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。

你如果是产品经理、业务分析师，或者负责把业务诉求翻译成可交付方案的人，你一定对“需求”这两个字既熟悉又警惕：熟悉在于每天都在接，警惕在于越接越发现——需求本身并不可靠。

有些需求是症状，不是问题；有些需求是局部诉求，不代表端到端价值；有些需求来自一次偶发事故，解决了反而引入更大风险；更常见的是：需求写得很漂亮，上线后却没带来任何可感知的成果，甚至让体验更差。

所以 ITIL 第5版把 Discover（发现）明确放在生命周期第一步，不是形式上的排序，而是方法论上的纠偏：先别急着接需求、排期、立项，先把机会找对、把价值假设说清、把验收准则写明。你在第一步偷的懒，后面会用更长的交付周期、更高的返工率、更糟的用户体验来还。




一、更新内容概述：六个要点如何决定 Discover 为什么必须是第一步


我们先来回顾一下 ITIL 第5版的核心更新内容概述，但我会用“为什么 Discover 变得更重要”来解释它们与第一步的关系。

1、定位升级：数字化产品和服务管理
端到端价值创造意味着你不能只满足某个部门的需求表达，而要理解真实使用场景与服务旅程，找到能带来成果的机会点。

2、生命周期模型升级：八个活动覆盖从发现到支持
把 Discover 放在第一步，是为了让后续 Design、Acquire、Build、Transition、Operate、Deliver、Support 都能围绕同一价值假设对齐，避免各做各的。

3、人工智能进入方法论核心
AI 能加速方案生成，但不能替你定义价值与边界。Discover 的任务反而更重：你要明确哪些问题适合 AI，风险边界在哪里，数据质量是否支撑得住。

4、指导原则更强调取舍：尤其是优化和自动化
取舍从第一步就开始：要不要做、先做什么、先试点还是直接推广。Discover 必须把取舍依据讲清楚，避免把“想做”当成“该做”。

5、实践从清单走向组件库：强调适用性与可裁剪
Discover 阶段就要决定你后续需要哪些能力组件来支撑，而不是到交付阶段才发现缺知识管理、缺配置记录、缺度量与报告。

6、持续改进的对象扩大
Discover 不只是为了新需求，也为了发现改进机会：瓶颈在哪里、体验断点在哪里、返工源头在哪里。持续改进要靠“发现”来不断供给机会池。

你会发现，ITIL 第5版越强调端到端、越强调价值流、越强调 AI 与自动化，Discover 越不可能只是“收集需求”。它必须承担“定方向、定边界、定验证方式”的职责。




二、先把 Discover 的“主语”说清：你不是在收需求，你是在寻找可验证的机会


很多组织把 Discover 做成一件行政工作：开需求会、写需求文档、排需求优先级。这样做的问题在于，你把“输入”当成了“结论”。

ITIL 第5版的 Discover 更像一次有目的的探索：

• 你要找的不是需求条目，而是机会 (opportunity)
• 你要输出的不是愿望清单，而是可验证的假设 (hypothesis)
• 你要推动的不是立项，而是价值共创的对齐
  

对产品经理来说，这个转变尤其关键。因为需求往往是“想要”，机会才是“值得”。值得的标准，是它能带来成果 (outcome)，并且成本与风险在可控范围内。

所以我建议你用一句话来定义 Discover 的产出：
Discover 的产出，是一组被清晰描述、可验证、可度量的价值假设，以及与之配套的验收准则。




三、从接需求到找机会：你需要换三种问法


在 Discover 阶段，最重要的不是你会用什么工具，而是你问问题的方式。你如果仍然用“需求问法”，你得到的只会是更多需求；你换成“机会问法”，你才会看到价值流里的真正断点。

我给你三种最实用的问法，你可以直接带进会议里用。

1、从“你要什么”换成“你要解决什么，为什么现在”

• 这个问题在价值流的哪个环节发生
• 它造成了什么成果损失、成本增加或风险上升
• 为什么现在必须处理：是频率上升、影响扩大，还是战略目标变化
  

2、从“功能怎么做”换成“成功长什么样，失败长什么样”

• 成功的验收准则是什么：用户体验如何变化，周期时间如何变化，返工率如何变化
• 失败的信号是什么：哪些风险指标会恶化，哪些控制点会被触发
  

3、从“谁提的需求”换成“谁在使用，谁在承担代价”

• 真实用户是谁，服务消费者是谁，客户组织是谁
• 谁在等待、谁在返工、谁在升级、谁在承担隐性成本
  

你会发现，提出需求的人不一定是承担代价的人。Discover 的价值就在于把这两类人重新对齐。




四、把洞察变成可验证的假设：你至少要写清四件事


Discover 最常见的失败，是洞察停留在“感觉层面”：大家都觉得这是痛点，但没人能说清楚怎么验证。结果到交付阶段才发现方向不对，返工不可避免。

一个可验证的假设，至少要写清四件事：
1、价值主张：我们要创造什么成果
例如：缩短交付周期、降低重大事件频率、提升用户满意度、减少升级次数
不要只写“提升效率”，要写清楚对谁、在哪个触点、提升什么。

2、目标受众：谁会感知价值

• 是服务用户、客户组织，还是内部业务团队
  

不同受众决定你后续的设计重点与度量方式。

3、约束与风险：我们担心什么

• 数据质量是否够
• 自动化会不会放大错误
• 合规与保密性边界在哪里
  

这一步是为了让取舍更真实，而不是为了吓退项目。

4、验证方式：怎么证明假设成立

• 用什么指标验证
• 验证窗口多长
• 通过什么试点或 A/B
  

如果你写不出验证方式，这不是假设，是愿望。




五、验收准则：让团队对齐“做到什么算完成”，而不是“做了什么算完成”


在我看来，Discover 阶段最值得你花时间写好的，就是验收准则。因为它决定团队后面会围绕什么对齐。
很多组织的验收准则写得像活动清单：

• 完成开发
• 完成测试
• 完成上线
  

这些只能证明你忙过，不能证明你有效。

ITIL 第5版更鼓励你把验收准则写成“成果型”：

• 用户申告的平均处理时间下降多少
• 关键路径的周期时间缩短多少
• 返工率下降多少
• 重大事件数量或影响范围是否下降
• 服务体验相关指标是否改善
  

验收准则写对，价值流才会被推动；写不对，团队就会把交付物当作终点。




七、Discover 为什么一定要与价值流绑定：否则你会把机会做成局部最优


Discover 阶段有一个特别隐蔽的坑：你发现的机会如果不放进端到端价值流里看，很容易变成局部最优。

举个常见例子：业务说“审批太慢，能不能取消”。如果你只看这个局部，你会倾向于简化审批。但如果你放到价值流里看，你可能会发现：

• 审批慢只是表象，真正慢的是信息不完整导致反复确认
• 审批背后承担的是高风险变更的控制点
• 真正该优化的是前置的验收准则与数据质量门禁，而不是一刀切取消控制点
  

所以 Discover 阶段就要做一个基本动作：把机会点放进价值流，确认它影响的是哪段流动，改变后会不会引入新的瓶颈与风险。




八、把 Discover 做成“可持续供给机会池”的机制：这才符合 ITIL v5 的持续改进精神


Discover 不是一次性的前期工作。ITIL 第5版强调持续改进，你就需要让 Discover 成为一个机制：不断发现机会、不断验证假设、不断把有效改进扩展到更多价值流。

你可以这样做一个轻量机制：

• 每月或每个迭代固定一次机会回顾
• 用数据挑选机会：周期时间、升级率、返工率、满意度等
• 每次只挑 1 到 2 个机会做小试点
• 用验收准则验证，验证通过再扩展
  

这比“做一个大项目把所有问题都解决”更符合复杂性情境下的真实节奏。


Discover 之所以必须是第一步，是因为它决定你后面所有活动是在走直路还是在绕路。你只要从“接需求”转为“找机会”，把洞察写成可验证的假设，把验收准则写成成果型，并把机会放进端到端价值流里检验，你就能把 ITIL 第5版真正用在产品与服务的价值创造上，而不是把生命周期做成新的流程模板。


欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。

2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。

你如果是产品经理、业务分析师，或者负责把业务诉求翻译成可交付方案的人，你一定对“需求”这两个字既熟悉又警惕：熟悉在于每天都在接，警惕在于越接越发现——需求本身并不可靠。

有些需求是症状，不是问题；有些需求是局部诉求，不代表端到端价值；有些需求来自一次偶发事故，解决了反而引入更大风险；更常见的是：需求写得很漂亮，上线后却没带来任何可感知的成果，甚至让体验更差。

所以 ITIL 第5版把 Discover（发现）明确放在生命周期第一步，不是形式上的排序，而是方法论上的纠偏：先别急着接需求、排期、立项，先把机会找对、把价值假设说清、把验收准则写明。你在第一步偷的懒，后面会用更长的交付周期、更高的返工率、更糟的用户体验来还。




一、更新内容概述：六个要点如何决定 Discover 为什么必须是第一步


我们先来回顾一下 ITIL 第5版的核心更新内容概述，但我会用“为什么 Discover 变得更重要”来解释它们与第一步的关系。

1、定位升级：数字化产品和服务管理
端到端价值创造意味着你不能只满足某个部门的需求表达，而要理解真实使用场景与服务旅程，找到能带来成果的机会点。

2、生命周期模型升级：八个活动覆盖从发现到支持
把 Discover 放在第一步，是为了让后续 Design、Acquire、Build、Transition、Operate、Deliver、Support 都能围绕同一价值假设对齐，避免各做各的。

3、人工智能进入方法论核心
AI 能加速方案生成，但不能替你定义价值与边界。Discover 的任务反而更重：你要明确哪些问题适合 AI，风险边界在哪里，数据质量是否支撑得住。

4、指导原则更强调取舍：尤其是优化和自动化
取舍从第一步就开始：要不要做、先做什么、先试点还是直接推广。Discover 必须把取舍依据讲清楚，避免把“想做”当成“该做”。

5、实践从清单走向组件库：强调适用性与可裁剪
Discover 阶段就要决定你后续需要哪些能力组件来支撑，而不是到交付阶段才发现缺知识管理、缺配置记录、缺度量与报告。

6、持续改进的对象扩大
Discover 不只是为了新需求，也为了发现改进机会：瓶颈在哪里、体验断点在哪里、返工源头在哪里。持续改进要靠“发现”来不断供给机会池。

你会发现，ITIL 第5版越强调端到端、越强调价值流、越强调 AI 与自动化，Discover 越不可能只是“收集需求”。它必须承担“定方向、定边界、定验证方式”的职责。




二、先把 Discover 的“主语”说清：你不是在收需求，你是在寻找可验证的机会


很多组织把 Discover 做成一件行政工作：开需求会、写需求文档、排需求优先级。这样做的问题在于，你把“输入”当成了“结论”。

ITIL 第5版的 Discover 更像一次有目的的探索：

• 你要找的不是需求条目，而是机会 (opportunity)
• 你要输出的不是愿望清单，而是可验证的假设 (hypothesis)
• 你要推动的不是立项，而是价值共创的对齐
  

对产品经理来说，这个转变尤其关键。因为需求往往是“想要”，机会才是“值得”。值得的标准，是它能带来成果 (outcome)，并且成本与风险在可控范围内。

所以我建议你用一句话来定义 Discover 的产出：
Discover 的产出，是一组被清晰描述、可验证、可度量的价值假设，以及与之配套的验收准则。




三、从接需求到找机会：你需要换三种问法


在 Discover 阶段，最重要的不是你会用什么工具，而是你问问题的方式。你如果仍然用“需求问法”，你得到的只会是更多需求；你换成“机会问法”，你才会看到价值流里的真正断点。

我给你三种最实用的问法，你可以直接带进会议里用。

1、从“你要什么”换成“你要解决什么，为什么现在”

• 这个问题在价值流的哪个环节发生
• 它造成了什么成果损失、成本增加或风险上升
• 为什么现在必须处理：是频率上升、影响扩大，还是战略目标变化
  

2、从“功能怎么做”换成“成功长什么样，失败长什么样”

• 成功的验收准则是什么：用户体验如何变化，周期时间如何变化，返工率如何变化
• 失败的信号是什么：哪些风险指标会恶化，哪些控制点会被触发
  

3、从“谁提的需求”换成“谁在使用，谁在承担代价”

• 真实用户是谁，服务消费者是谁，客户组织是谁
• 谁在等待、谁在返工、谁在升级、谁在承担隐性成本
  

你会发现，提出需求的人不一定是承担代价的人。Discover 的价值就在于把这两类人重新对齐。




四、把洞察变成可验证的假设：你至少要写清四件事


Discover 最常见的失败，是洞察停留在“感觉层面”：大家都觉得这是痛点，但没人能说清楚怎么验证。结果到交付阶段才发现方向不对，返工不可避免。

一个可验证的假设，至少要写清四件事：
1、价值主张：我们要创造什么成果
例如：缩短交付周期、降低重大事件频率、提升用户满意度、减少升级次数
不要只写“提升效率”，要写清楚对谁、在哪个触点、提升什么。

2、目标受众：谁会感知价值

• 是服务用户、客户组织，还是内部业务团队
  

不同受众决定你后续的设计重点与度量方式。

3、约束与风险：我们担心什么

• 数据质量是否够
• 自动化会不会放大错误
• 合规与保密性边界在哪里
  

这一步是为了让取舍更真实，而不是为了吓退项目。

4、验证方式：怎么证明假设成立

• 用什么指标验证
• 验证窗口多长
• 通过什么试点或 A/B
  

如果你写不出验证方式，这不是假设，是愿望。




五、验收准则：让团队对齐“做到什么算完成”，而不是“做了什么算完成”


在我看来，Discover 阶段最值得你花时间写好的，就是验收准则。因为它决定团队后面会围绕什么对齐。
很多组织的验收准则写得像活动清单：

• 完成开发
• 完成测试
• 完成上线
  

这些只能证明你忙过，不能证明你有效。

ITIL 第5版更鼓励你把验收准则写成“成果型”：

• 用户申告的平均处理时间下降多少
• 关键路径的周期时间缩短多少
• 返工率下降多少
• 重大事件数量或影响范围是否下降
• 服务体验相关指标是否改善
  

验收准则写对，价值流才会被推动；写不对，团队就会把交付物当作终点。




七、Discover 为什么一定要与价值流绑定：否则你会把机会做成局部最优


Discover 阶段有一个特别隐蔽的坑：你发现的机会如果不放进端到端价值流里看，很容易变成局部最优。

举个常见例子：业务说“审批太慢，能不能取消”。如果你只看这个局部，你会倾向于简化审批。但如果你放到价值流里看，你可能会发现：

• 审批慢只是表象，真正慢的是信息不完整导致反复确认
• 审批背后承担的是高风险变更的控制点
• 真正该优化的是前置的验收准则与数据质量门禁，而不是一刀切取消控制点
  

所以 Discover 阶段就要做一个基本动作：把机会点放进价值流，确认它影响的是哪段流动，改变后会不会引入新的瓶颈与风险。




八、把 Discover 做成“可持续供给机会池”的机制：这才符合 ITIL v5 的持续改进精神


Discover 不是一次性的前期工作。ITIL 第5版强调持续改进，你就需要让 Discover 成为一个机制：不断发现机会、不断验证假设、不断把有效改进扩展到更多价值流。

你可以这样做一个轻量机制：

• 每月或每个迭代固定一次机会回顾
• 用数据挑选机会：周期时间、升级率、返工率、满意度等
• 每次只挑 1 到 2 个机会做小试点
• 用验收准则验证，验证通过再扩展
  

这比“做一个大项目把所有问题都解决”更符合复杂性情境下的真实节奏。


Discover 之所以必须是第一步，是因为它决定你后面所有活动是在走直路还是在绕路。你只要从“接需求”转为“找机会”，把洞察写成可验证的假设，把验收准则写成成果型，并把机会放进端到端价值流里检验，你就能把 ITIL 第5版真正用在产品与服务的价值创造上，而不是把生命周期做成新的流程模板。


欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。