课程简介
1)本课程全程采用“真·工作坊”的战训营方式讲练结合，暨：学员将被分为若干小组，6~8人一组；每个小组分别使用各自的项目场景顺序完成4个内容垂直关联的实战演练，演练内容涵盖含有AI交付内容的数智化软件项目（被冠以“智能XXX系统”、“智慧XXX业务”名称的项目最为典型）需求分析与需求管理全过程的4个重要的节点：引导式需求调研、场景化需求分析、结构化需求规格、共情式需求验证；
2)特别的，我们邀请贵公司学员直接采用您的公司实际的项目（已完成或者正在交付过程中的）作为各个学员分组的演练场景。此举可以保证以“真项目，真场景，真战训”的方式，既能让学员以“身临其境”式的培训体验，又可以对如何精细化贵公司数智化项目的需求分析与需求管理工作给予建设性建议；
3)本课程全程采用互动式教学、实战式演练，包含有大量相关领域实际案例分析；并且，将数智化项目需求过程中如何避免“踩坑”的方法总结为15个应对策略（在下面的课程大纲中将标注为红色），在课堂中与您充分分享。
目标收益
认知层：理解数智化项目需求“模糊性”的根源（技术不确定性、业务未知性）；
方法层：掌握从“用户想法”到“功能需求”，再到“技术指标”的结构化拆解方法；
实操层：学会编写可测试、可验证的验收标准，并建立需求全链路追踪机制；
产出层：输出一套针对企业实际场景的需求转化模板与指标定义清单
培训对象
准备担当产品经理、需求分析师、系统架构师或项目经理的专业人士
课程大纲
| 1、从“雾里看花”到“清晰画像”——模糊需求的解构与共识 |
案例分析与研讨：一个典型的失败项目复盘——老板说“我们要做个智能决策系统”。 数智化软件项目的“变革”——从“数据”到“数据资产”再到“数据资产化”；从“解放手和脚”到“解放头脑”再到“生成式AI”；从“单一的、离散的产品/应用”到“集成化、一站式的综合解决方案”再到“360度产品应用生态” 小结：对于To B类型的项目，当年的“信息化”与今天的“数智化”的区别与联系——信息化帮助客户“省钱”（规范管理，减员增效），而数字化帮助客户“赚钱”（提高企业效能，改善业务业绩）； 案例分析与研讨：数智化软件项目的“不变” 数智化软件项目的“不变”——始于“干系人的诉求”，终于“基于价值的交付”；自动化、场景化、个性化，围绕核心需求的解决方案，直击客户/用户的痛点 小结：做好数智化软件项目管理的第一要素——我们交付的是项目的价值，而不是项目本身！ 数智化/AI给需求分析与需求管理带来的新挑战 数智化特性：模型即需求 需求更加不明确，边界更加不清晰——区分“模糊”（Ambiguity）与“不确定”（Uncertainty） 数智化系统特有的陷阱：技术可行性黑洞、数据质量陷阱、AI“黑盒”带来的预期偏差……于是需求分析与管理的过程更加曲折，验收更加严格 大概率上，这些项目在客户方还承担有“示范性项目”、“标杆型项目”的额外要求 核心方法论：需求分层模型（业务目标 → 用户场景 → 系统功能及非功能约束） 热身演练(10:40~11:00，包含是点评时间，下同)： 各学员小组挑选并明确自己用于后续演练的真是项目场景。而后，对本项目做一个不超过5分钟的介绍，要求至少包含以下3点： 项目在贵公司业务蓝图中的位置、承担的业务要求（注意是贵公司而不是客户）； 验收项目“商业成功”的标准有哪些（注意是商业成功不是交付成功）； 列举该项目中遇到的“最模糊最离谱”的需求 |
| 2、未有需求之前——需求调研与价值主张映射 （上） |
本章开题：数智化项目的启动过程必需要实现的转变——从“调研”跃迁为“引导” 从一个实际案例说起：某AI项目的早期“调研过程”——客户的输入只有一句话：“实现供应链的智能预警” 应对方法之一——认识项目的干系人 = （识别干系人+识别干系人的期望值） * 在此基础上的抽象 应对方法之二——Before AI Vs. After AI分析 小结：数智化项目需求调研工作的核心任务，就是要解决“我们到底要做什么”的问题，就是要将非结构化的业务痛点转化为结构化的功能假设。 |
| 3、未有需求之前——需求调研与价值主张映射 (下） |
如何有效且有限地引导客户对于数智化项目的期望值？ 为什么提倡“有效且有限”？一言以蔽之：为了经营，为了回款，为了避免成本超支！ 实例分析与研讨：某型“智慧XX系统”项目的四层阶梯业务模型——讲得清楚项目“智”在哪里、“惠”在哪里是极端重要的 应对方法之三——从“业务需求”到“业务主题”再到“阶梯状业务模型”，一层一层引导客户期望值 如果客户方提出来“弯道超车，跨越式发展”，那该怎么办？ 实例分析与研讨：脱离成本预算支撑的“跨越式发展”都是陷阱！ 应对方法之四——怎样摆脱陷阱？“三段式项目策划方案”标准模板 本章总结：数智化项目/解决方案的交付价值 = VOA（项目交付物对于用户的应用价值）+ VOG（项目交付物对于客户的成长价值）+ VOB（项目对于组织自身的商业价值） 分组演练1(15:10~16:10)： 各分组根据选定的项目场景，分析项目干系人对项目的期望，明确定义： 本项目将在数字化和智能化方面做出哪些创新，以及，更为关键的，这些创新点对客户/用户的价值是什么？ 结合第1）项的结论，用一句话总结概括本项目的“建设目标”； 规划本项目下一期、下两期的建设内容，从而完善本项目的“阶梯状业务模型” |
| 4、系统的应用场景分析 |
本场开题——从系统的建设目标到应用场景，从仰望星空到脚踏实地 实例分析与研讨：构成场景的3个主要要素，特别关注—— 如何将“提高效率”转化为具体的用户任务（Task） 如何将“智能化”拆解为“感知-认知-决策-执行”四个环节 应对方法之五——使用用户故事地图（User Story Mapping）梳理数智化场景，从系统的业务流程主干中拆分细节，同时分析与判断AI应用的必要性与重要性 |
| 分组演练2 |
分组演练2：各小组使用“用户故事地图”来梳理本项目的应用场景，完成如下任务： 1)本系统的业务流程主干； 2)本系统的关键业务环节； 3)在本系统的哪些关键业务环节中加入怎样的AI应用； 4)评估上述内容的必要性与重要性，从而确定各个应用场景的优先级 |
| 5、从“场景”到“规格”——结构化需求编写（上） |
本章开题：需求资产化与结构化描述 标准规范：统一需求描述语言 应对方法之六——针对数智化场景的 GWT 变形 Given 数据状态（数据分布、数据量级、特定特征值） When 触发动作（数据元输入、模型推理、定时任务） Then 可观测结果（返回数据、界面展示、日志记录、模型输出分布） 应对方法之七：针对 AI/数智化特性的特殊写法 案例分析与研讨：如何描述“基于数据的策略推荐”（定义输入、策略逻辑、输出格式） 案例分析与研讨：如何描述“异常处理”（数据缺失、置信度过低时的兜底策略） |
| 6、从“场景”到“规格”——结构化需求编写（下） |
非功能需求的实质：——从“交付价值”到“技术指标”的映射 核心概念：建立北极星指标 → 业务指标 → 技术指标的因果链 案例分析与研讨：推理延迟（影响体验）、召回覆盖率、排序 NDCG（归一化折损累积增益） 非功能性需求的指标化、可视化 案例分析与研讨：给一个“智慧园区大脑”定义其关键的非功能性指标 难点剖析：性能、安全、可扩展性在数智化项目中的具体体现。 应对方法之八：转化技巧 将“系统要快”转化为具体的响应时间、并发量。 将“模型要准”转化为准确率、召回率、F1 值，并明确基线和目标值。 将“系统要稳”转化为可用性 SLA（99.9% vs 99.99%）及数据一致性要求。 分组演练3（14:30~15:30）：各小组为本系统一项功能需求（由讲师指定）与非功能需求编写规格化的描述文本 |
| 7、从“规格”到“验证”——需求沟通、追踪与验证确认 |
需求沟通实例分析：业务方提出“我觉得这个算法不准，能不能换个逻辑”。 应对方法之九：利用第一天的“非功能指标”作为谈判筹码（改变逻辑是否影响响应时间 SLA？）；利用第二天的“验收标准”判断是否属于范围蔓延（Scope Creep）；厘清数智化项目的变更代价评估（数据重标、模型重训的成本）。 需求跟踪 应对方法之十：“模型即需求”，如何管理模型的版本迭代与需求版本的对应关系？ 应对方法之十一：数据血缘与需求血缘的结合——当上游数据源变化时，如何快速评估对需求指标的影响？ 数智化项目需求验证与确认时的被关注重点——AI运算与分析结果的“可用性” 实例分析与研讨：某型“智能XXX系统”的验收过程 应对方法之十二：AI运算与分析结果的“可用性测试”的基本过程与管控要素 功夫诗外：如何在整个项目期间，防止系统需求蔓延？ 应对方法之十三——强调：因为要实现如此的“智慧”、“智能”内容，所以对客户方IT技术设施建设提出哪些要求，实现哪些升级 应对方法之十四——强调：因为要实现如此的“智慧”、“智能”内容，所以对客户方既有的相关联系统提出哪些要求，实现哪些升级 应对方法之十五——强调：因为要实现如此的“智慧”、“智能”内容，所以对客户方既有的管理模式、管理机制与流程提出哪些要求，实现哪些变革 分组演练4(15:40~17:10)：假定项目可以正常结项，请各个小组撰写本项目“AI运算与分析结果可用性”的测试方案，包括： 1)测试场景及其测试方法； 2)各个测试场景的执行顺序； 3)各个测试场景的通过准则 |
| 8、培训总结与答疑 | 培训总结与答疑 |
|
1、从“雾里看花”到“清晰画像”——模糊需求的解构与共识 案例分析与研讨：一个典型的失败项目复盘——老板说“我们要做个智能决策系统”。 数智化软件项目的“变革”——从“数据”到“数据资产”再到“数据资产化”；从“解放手和脚”到“解放头脑”再到“生成式AI”；从“单一的、离散的产品/应用”到“集成化、一站式的综合解决方案”再到“360度产品应用生态” 小结：对于To B类型的项目，当年的“信息化”与今天的“数智化”的区别与联系——信息化帮助客户“省钱”（规范管理，减员增效），而数字化帮助客户“赚钱”（提高企业效能，改善业务业绩）； 案例分析与研讨：数智化软件项目的“不变” 数智化软件项目的“不变”——始于“干系人的诉求”，终于“基于价值的交付”；自动化、场景化、个性化，围绕核心需求的解决方案，直击客户/用户的痛点 小结：做好数智化软件项目管理的第一要素——我们交付的是项目的价值，而不是项目本身！ 数智化/AI给需求分析与需求管理带来的新挑战 数智化特性：模型即需求 需求更加不明确，边界更加不清晰——区分“模糊”（Ambiguity）与“不确定”（Uncertainty） 数智化系统特有的陷阱：技术可行性黑洞、数据质量陷阱、AI“黑盒”带来的预期偏差……于是需求分析与管理的过程更加曲折，验收更加严格 大概率上，这些项目在客户方还承担有“示范性项目”、“标杆型项目”的额外要求 核心方法论：需求分层模型（业务目标 → 用户场景 → 系统功能及非功能约束） 热身演练(10:40~11:00，包含是点评时间，下同)： 各学员小组挑选并明确自己用于后续演练的真是项目场景。而后，对本项目做一个不超过5分钟的介绍，要求至少包含以下3点： 项目在贵公司业务蓝图中的位置、承担的业务要求（注意是贵公司而不是客户）； 验收项目“商业成功”的标准有哪些（注意是商业成功不是交付成功）； 列举该项目中遇到的“最模糊最离谱”的需求 |
|
2、未有需求之前——需求调研与价值主张映射 （上） 本章开题：数智化项目的启动过程必需要实现的转变——从“调研”跃迁为“引导” 从一个实际案例说起：某AI项目的早期“调研过程”——客户的输入只有一句话：“实现供应链的智能预警” 应对方法之一——认识项目的干系人 = （识别干系人+识别干系人的期望值） * 在此基础上的抽象 应对方法之二——Before AI Vs. After AI分析 小结：数智化项目需求调研工作的核心任务，就是要解决“我们到底要做什么”的问题，就是要将非结构化的业务痛点转化为结构化的功能假设。 |
|
3、未有需求之前——需求调研与价值主张映射 (下） 如何有效且有限地引导客户对于数智化项目的期望值？ 为什么提倡“有效且有限”？一言以蔽之：为了经营，为了回款，为了避免成本超支！ 实例分析与研讨：某型“智慧XX系统”项目的四层阶梯业务模型——讲得清楚项目“智”在哪里、“惠”在哪里是极端重要的 应对方法之三——从“业务需求”到“业务主题”再到“阶梯状业务模型”，一层一层引导客户期望值 如果客户方提出来“弯道超车，跨越式发展”，那该怎么办？ 实例分析与研讨：脱离成本预算支撑的“跨越式发展”都是陷阱！ 应对方法之四——怎样摆脱陷阱？“三段式项目策划方案”标准模板 本章总结：数智化项目/解决方案的交付价值 = VOA（项目交付物对于用户的应用价值）+ VOG（项目交付物对于客户的成长价值）+ VOB（项目对于组织自身的商业价值） 分组演练1(15:10~16:10)： 各分组根据选定的项目场景，分析项目干系人对项目的期望，明确定义： 本项目将在数字化和智能化方面做出哪些创新，以及，更为关键的，这些创新点对客户/用户的价值是什么？ 结合第1）项的结论，用一句话总结概括本项目的“建设目标”； 规划本项目下一期、下两期的建设内容，从而完善本项目的“阶梯状业务模型” |
|
4、系统的应用场景分析 本场开题——从系统的建设目标到应用场景，从仰望星空到脚踏实地 实例分析与研讨：构成场景的3个主要要素，特别关注—— 如何将“提高效率”转化为具体的用户任务（Task） 如何将“智能化”拆解为“感知-认知-决策-执行”四个环节 应对方法之五——使用用户故事地图（User Story Mapping）梳理数智化场景，从系统的业务流程主干中拆分细节，同时分析与判断AI应用的必要性与重要性 |
|
分组演练2 分组演练2：各小组使用“用户故事地图”来梳理本项目的应用场景，完成如下任务： 1)本系统的业务流程主干； 2)本系统的关键业务环节； 3)在本系统的哪些关键业务环节中加入怎样的AI应用； 4)评估上述内容的必要性与重要性，从而确定各个应用场景的优先级 |
|
5、从“场景”到“规格”——结构化需求编写（上） 本章开题：需求资产化与结构化描述 标准规范：统一需求描述语言 应对方法之六——针对数智化场景的 GWT 变形 Given 数据状态（数据分布、数据量级、特定特征值） When 触发动作（数据元输入、模型推理、定时任务） Then 可观测结果（返回数据、界面展示、日志记录、模型输出分布） 应对方法之七：针对 AI/数智化特性的特殊写法 案例分析与研讨：如何描述“基于数据的策略推荐”（定义输入、策略逻辑、输出格式） 案例分析与研讨：如何描述“异常处理”（数据缺失、置信度过低时的兜底策略） |
|
6、从“场景”到“规格”——结构化需求编写（下） 非功能需求的实质：——从“交付价值”到“技术指标”的映射 核心概念：建立北极星指标 → 业务指标 → 技术指标的因果链 案例分析与研讨：推理延迟（影响体验）、召回覆盖率、排序 NDCG（归一化折损累积增益） 非功能性需求的指标化、可视化 案例分析与研讨：给一个“智慧园区大脑”定义其关键的非功能性指标 难点剖析：性能、安全、可扩展性在数智化项目中的具体体现。 应对方法之八：转化技巧 将“系统要快”转化为具体的响应时间、并发量。 将“模型要准”转化为准确率、召回率、F1 值，并明确基线和目标值。 将“系统要稳”转化为可用性 SLA（99.9% vs 99.99%）及数据一致性要求。 分组演练3（14:30~15:30）：各小组为本系统一项功能需求（由讲师指定）与非功能需求编写规格化的描述文本 |
|
7、从“规格”到“验证”——需求沟通、追踪与验证确认 需求沟通实例分析：业务方提出“我觉得这个算法不准，能不能换个逻辑”。 应对方法之九：利用第一天的“非功能指标”作为谈判筹码（改变逻辑是否影响响应时间 SLA？）；利用第二天的“验收标准”判断是否属于范围蔓延（Scope Creep）；厘清数智化项目的变更代价评估（数据重标、模型重训的成本）。 需求跟踪 应对方法之十：“模型即需求”，如何管理模型的版本迭代与需求版本的对应关系？ 应对方法之十一：数据血缘与需求血缘的结合——当上游数据源变化时，如何快速评估对需求指标的影响？ 数智化项目需求验证与确认时的被关注重点——AI运算与分析结果的“可用性” 实例分析与研讨：某型“智能XXX系统”的验收过程 应对方法之十二：AI运算与分析结果的“可用性测试”的基本过程与管控要素 功夫诗外：如何在整个项目期间，防止系统需求蔓延？ 应对方法之十三——强调：因为要实现如此的“智慧”、“智能”内容，所以对客户方IT技术设施建设提出哪些要求，实现哪些升级 应对方法之十四——强调：因为要实现如此的“智慧”、“智能”内容，所以对客户方既有的相关联系统提出哪些要求，实现哪些升级 应对方法之十五——强调：因为要实现如此的“智慧”、“智能”内容，所以对客户方既有的管理模式、管理机制与流程提出哪些要求，实现哪些变革 分组演练4(15:40~17:10)：假定项目可以正常结项，请各个小组撰写本项目“AI运算与分析结果可用性”的测试方案，包括： 1)测试场景及其测试方法； 2)各个测试场景的执行顺序； 3)各个测试场景的通过准则 |
|
8、培训总结与答疑 培训总结与答疑 |
近期公开课推荐
