任你选择
课程大纲
1. 课程的假设与前置条件
这门课程是讲给技术人员听的，即：技术团队中负责需求分析的人员。在不同的组织、不同的研发流程体系下，他们的头衔不尽相同，可能是“产品经理”，可能是“产品负责人（PO）”，也可能是BA（商业分析人员）。
设置这门课程，基于以下几个假设前提——
i. 认为业务人员永远讲不清楚需求。所以我们课程的着眼点是“如何在业务人员讲不清楚需求的情况下，技术人员还能做对需求、做准需求”；
ii. 认为需求分析必须要分成两个递进的阶段——1）着眼于系统整体的需求分析，即：该系统将会解决哪些问题，给用户/客户（特别是客户）带来怎样的交付价值；2）着眼于需求条目的具体需求分析——注意，通常我们观察到的情况，需求分析人员（技术）往往欠缺对第1）部分的把控，进而导致需求蔓延、需求变更等许多问题；而业务人员往往在这方面也不会给予清晰的信息，他们只会给予点状的、碎片化的“需求”（往往还是伪需求）。我们可以称呼这两个递进的阶段为“两种眼光看待需求”；
iii. 认为需求变更并非因为“提出者提出需求变更”占据主要原因，认为所谓的“需求变更”大多数都是因为分析者无法掌握“两种眼光看待需求“的能力而导致的。所以，我们的课程重点不在于“有了变更怎么办”，而是“如何从源头上消除变更或者减少变更，最起码也得是减轻需求变更对系统开发的负面影响”；
iv. 认为“需求做不好”永远不是沟通问题，亦不是流程问题、模板问题或者规范问题，是需求分析人员缺乏相关技术、技能的引导，缺乏有效的方法指引。所以，我们的课程中遴选了一批被若干企业证明行之有效的方法和技术，通过大量实例剖析和实战化演练过程教给学员；并且，更为关键的，这些方法和技术都可以嵌入受训组织/企业现有的流程当中固化下来，成为受训企业/组织的持续发展和改善的需求分析能力。
2. 课程方案说明
我们定义“B端系统”为：客户（付钱购买项目产出的产品/服务的人士）与用户（项目产出的产品/服务的最终使用者）不是同一批人的系统/产品。典型的B端软件系统包括：企业信息化系统、政务信息化系统。
一般的，B端系统建设过程中有关“需求分析”的活动，将会以线性的顺序或者迭代的方式完成如下的工作——
1) 在对原始需求（也可以称之为“相关方期望”）进行调研与挖掘基础上，明确各个相关方对系统的期望与要求；
2) 信息系统的商业价值分析，即：建立对系统的全局意识，明确系统商业化的交付价值；
3) 业务需求分析，即：建立起系统的 “用户场景”，以及使用合适的工具（例如：“用户故事”技术）与各个相关方沟通、遴选以及确认系统的应用场景；
4) 业务需求的规格化，即：以规格化文本，同时使用自然语言与符号化语言（例如：数据流图）精确描述业务需求，经过评审等验证活动后交付给开发团队；
5) 贯穿在以上1~4项活动中的所有有关业务需求的沟通、协调与平衡；
6) 必要时，完成对系统未来拓展的“阶梯化”建模工作，即：系统的版本化规划——系统在未来1~2年内将分别交付哪些版本、每个版本的核心诉求是什么、每个版本将交付哪些业务层级的需求。
我们以下图来更清晰地展示“需求分析”在整个B端系统建设周期中的位置以及前后承接关系。在下图中，前四个步骤即行对应需求分析的1~4项工作，漏斗状的图形是在强调这一过程中不断取舍、不断精细化的特性。下图的红色闭环箭头用来展示需求分析过程中系统的版本规划工作——
为了保证在上图6大领域内，业务需求分析人员的能力得到全面系统地提升以达到“可操作“程度，我们规划了3天共13个培训主题的课程方案，并且在培训结束后安排有一小时的针对学员的培训效果测试（由单选题、是非题和论述题三大类提醒构成）。下一章将详述在上述6大领域内的受训学员需要得到赋能的内容与课程方案的对应关系。
3. 课程方案详解
【特别说明】：本课程方案全程采用Workshop工作坊方式组织实施，即：受训学员将被分为若干小组，每个小组使用同一个项目场景顺序完成6个实战演练，内容涵盖上述6大领域。
【特别企划】：强烈建议直接采用贵公司的实际存在的信息系统建设项目（已完成的或者正在进行的）作为学员分组演练案例，以提升学员“身临其境”的体验。另外，课程中所有用于讲解的案例都将根据贵公司的业务领域特点、过程体系与产品研发生命周期进行定制化。
序号 | 过程领域 | 赋能内容 暨培训主题 | 培训主题的内容讲解 | 培训日程安排 | 备注 |
1 | N/A | 概述 | “B端系统”的定义、与“C端”的区别 “B端系统”的需求分析工做的8项难点列举 需求的全量定义，特别甄别业务需求与项目管理需求、软件需求之间的区别与联系 | Day 1 上午 | 安排有热身演练，一个简化的需求分析过程；旨在让学员清楚认识在以往需求开发与需求管理的常见误区与缺失 |
2 | 需求分析过程的两大常态及其应对策略 1) 讲不清楚需求 2) 需求处于不断的变化中 | 案例剖析 | |||
3 | 原始需求的调研与挖掘 | 前端业务部门（销售、客服、市场等）同事提出的原始需求通常存在哪些问题 | 列举原始需求的5大类问题 | 案例剖析 | |
4 | 原始需求的调研与挖掘 | 详细介绍需求调研的常用的3种方法： 1）访谈 2）业务逻辑捕捉 3）联合需求工作会议 以案例剖析的方式，详细介绍每一种方法的操作步骤、交付件以及实施要点 | Day 1 下午 | 分组演练1：各组为自己的项目定义访谈问题列表 | |
5 | IT系统的商业价值分析 | 通常，B端系统的交付价值主张是什么 | 促使学员牢固树立“我们交付的不是系统本身，而是系统的价值”的认识 | 3~4个相关实际案例的解析与讨论 | |
6 | “相关方期望值”分析中可资应用的BBR（帮忙不惹事）模型 | 1）相关方的期望对B端系统建设影响 2）依照帮忙-不惹事两个维度分析四大类不同相关方的诉求 | Day 2上午 | 3~4个相关实际案例的解析与讨论 | |
7 | 目标用户与相关方期望值分析 | 使用“用户画像“和”移情映射“技术，分析不同类型的目标用户对系统不同的诉求/期望/约束 相关实际案例的解析与讨论 | 分组演练2：各组定位各自项目的交付价值，明确各自项目里不同相关方角色的期望/要求/约束 | ||
8 | 业务需求分析（上） | 业务场景，以及如何定义业务场景 | 使用“时间-人物-亚文化“的三维模型构造与平衡系统的典型应用场景 相关实际案例的解析与讨论 | Day 2 下午
| 分组演练3：定义各自项目面对不同用户角色的典型应用场景 |
9 | 业务需求分析（下） | 使用“用户故事”技术分析系统的业务场景 | “用户故事“的详细讲解，包括其难点与重点 相关实际案例的解析与讨论 | 分组演练4：定义5条本项目典型的用户故事 | |
10 | 使用“用户故事地图”技术规划系统各个MVP（最小可应用产品）的业务场景 | “用户故事地图“技术的详细讲解、难点与重点 相关实际案例的解析与讨论 | Day 3 上午 | 分组演练5：使用“用户故事地图技术，为本项目规划前三个MVP的主要功能项 | |
11 | 如何以“场景扩增模型”规划系统的版本路标 | 以“诺兰模型”为例，讲解如何定义分领域的“场景扩增模型“，以及如何使用该模型引导用户的需求，规划系统的版本路标 | 分组演练6：定义各组项目的“场景扩增模型“ | ||
12 | 需求建模与规格化 | 使用“符号化语言”的需求建模手段 | “数据流图“和“实体-关系图”技术的详细讲解、难点与重点 | Day 3下午 | 相关实际案例的解析与讨论 |
使用自然语言的需求规格化手段 | 如何保证需求的自然语言描述过程中的一致性、正确性、无二义性…… | 相关实际案例的解析与讨论 | |||
13 | 需求验证 | 需求评审 | 需求评审的过程 | ||
N/A | 考试 | 培训效果测试 | 1小时测试 |
4. 课程结束后的交付件
所有课程结束之后，讲师将为贵公司提交如下的交付件/文档模板，供贵公司在后续的持续改善和提升过程中参考——
1) 需求调研报告模板（三种格式）；
2) 系统商业价值分析报告模板；
3) 用户画像（模板）
4) 第3级、第4级业务流程梳理模板；
5) 业务先导原型与业务功能对照表模板；
6) 用户故事列表模板
7) 需求规格说明书模板（IRF格式）；
8) 需求规格说明书模板（UseCase格式）；
9) 需求差异化分析列表模板
5. 附录
截至2022年01月，已经引入本课程作为内训的部分B端顶级客户名单（排名不分先后）
中国银联（China Unipay）旗下广州银联网络支付
中国联通软件研究院
上海证券交易所
深圳证券交易所，及其旗下深圳证券信息有限公司、深圳证券通讯有限公司
中国南方航空信息科技部
中国国际航空信息中心
中国化工集团信息科技部
中国人民保险（PICC）
太平洋保险
河南信产集团（政信）
央广新媒体（中央人民广播电台旗下子公司，互联网和新媒体方向）
大连期货交易所旗下大连飞创信息技术有限公司
郑州商品交易所旗下郑州易盛信息技术有限公司
上汽大众（数字化营销团队）
平安科技
花旗软件（花旗银行IT服务）
中国工商银行（总行）数据中心
中国农业银行（总行）技术中心
华润集团
厦门航空信息科技部
浦发银行信用卡中心、文思海辉、用友集团……等100余家客户。
