Business Analysis可视化表达软件业务需求分析BA-2020年-4月-上海

时间：2020年4月18-19日

讲师：Stephen Wang 王洪亮

地点：上海

价格：RMB 7000元每位，提早报名或团队报名有优惠。

联系方式: 021-34753688

Email: Service@uperform.cn

我要报名公开班

课程介绍

很多IT部门或企业都会面临一个共同的问题，就是业务需求比较模糊，无法快速的掌握需求，进而可能影响估算，排期和开发。

产品需求分析者需要能够从多个视角来进行需求的描述，从而让不同的角色都可以轻易地获得自己想要的信息。众所周知，一图胜千言，因此，如果多采用图形、表格的方式来表达需求的话，会让需求的分析变得更加容易理解。并且，图形的描画和表格的绘制是比书写大量文字并且调整格式相对来说简单的工作。这是一种可以通过更少的工作带来更多的产出的方式。从而解决了需求分析成为开发瓶颈的问题。

软件业务需求分析处在软件工程的上游，对下游有明显的杠杆作用，上游的改善能够大幅度的提升下游的质量和效率。这也是在若干项目上应用该可视化需求分析工具箱之后的效果，从而更高效地分配指导产品实施的具体开发工作，最终实现符合业务需求的高质量软件产品交付。

目标听众：

1. 业务部门的需求提出者（产品负责人）
2. IT部门的产品经理（业务分析师）
3. 对需求分析方法感兴趣的其他角色

授课顾问：

社区知名技术大牛，资深软件开发及敏捷咨询师，精益创业导师。十余年软件行业从业经验，精通日语和英语。多年来一直致力于软件代码开发方法和技巧的研究，是国内“自表达代码”方面的权威，并著有《会说话的代码》一书。擅长极限编程（XP）、测试驱动开发（TDD）、持续集成（CI）、重构（Refactor）、演进式设计（Evolutionary Design）以及降低代码的复杂度（Cyclomatic Complexity）。通过重构、重写，将代码量大幅度缩减，并且提高可读性、可扩展性、可变更性，从而大幅度降低开发成本。对测试用例设计、划分等有深入研究，对如何提高测试的稳定性以及测试覆盖率有丰富的经验。他也是北京和天津软件社区的活跃组织者和分享者。主要客户包括凡普金科，以及长期担任戴姆勒-奔驰创新实验室的精益创业导师和敏捷教练等。

课程目标：

该工具箱曾经帮助过多个项目成功的推进了进度，疏通需求分析过程，加速了开发，得到项目组的一致好评。该工具箱是有效工具集合，对于企业来说十分具有应用价值。该工具箱背后是“一图胜千言”，“完整性”，“一致性”，“正确性”等15个原则，对于BA的基本原则的掌握可以拓展出自己的适用工具，以便在自己的特定场景下能够更好的发挥价值。 本课程通过一个例子项目的方式进行整个需求分析的过程的演练，并且讲述相关的需求分析的工具的使用方法，通过实践练习，让学员真正掌握对应的工具的使用方法。 本课程不仅包含了实用的BA工具箱，还有对BA的定位的分析，如何和其他角色协作的建议，以及BA所面临的困惑，BA应该具备的技能体系的建议以及BA如何发展自己的职业生涯方面的建议。

课前准备

1. 学员自己准备的需求题目和问题列表

课程内容

1. 几个小练习
a. 通过几个小练习掌握可视化表达需求和文字表达需求的区别
2. 需求分析中常见的问题
a. 遗漏、矛盾、错误都是怎么产生的
b. 需求理解为什么会有偏差
3. 需求分析的15个基本原则
4. 需求分析需要多视角
5. 认识BA的角色及价值
a. BA的角色位置
b. BA的困惑
c. BA的价值
d. BA所需的技能
6. 其他的业务分析方法
a. SRS
b. PRD
c. 用户故事
7. 需求分析对于项目管理的杠杆作用
a. 需求分析和计划会
b. 需求分析和估算
c. 需求分析和开发
d. 需求分析和测试
e. 需求分析和迭代
8. 介绍一个可视化需求分析的具体的例子，看看和传统以及现在的方法的不同以及价值。
9. 介绍案例项目，用于本次课程全程练习
10. 业务部门的需求问题如何解决
a. 一句话需求
b. 我也不知道自己想要什么
c. 我知道我想要什么，但是我表达不出来
d. 我知道我想要什么，但是缺少素材
e. 业务部门到底要的是什么
i. 一组完成功能的软件
ii. 软件背后的商业价值
f. 如何应对一句话需求或者一页纸需求的案例讲解
i. 如何发现遗漏场景
ii. 如何发现潜在需求
iii. 如何发现商业价值
11. 纲举目张的需求分析方法
12. 影响力地图
影响力地图是解决为什么要开发系统，系统为谁解决问题，系统如何解决问题的总体方向性问题的工具。
13. 事件风暴
事件风暴是解决微服务的领域事件识别的一种方法。通过事件风暴可以解决事件遗漏的问题，并且可以通过抽象层次提高，解决需求变更的应对问题。
14. 泳道式流程图
泳道式流程图解决的是各种角色在系统流程的步骤中如何参与的问题，避免系统集成的时候有遗漏角色场景的情况。
15. 决策矩阵
决策矩阵解决需求遗漏的问题，并且同时能够引导程序员以面向对象的方法来书写代码，并且响应变化。
16. 状态图
17. 判定矩阵
判定矩阵是解决多因素场景的覆盖全面的问题的。通过判定矩阵可以全面的覆盖到所有的场景以防止遗漏，并且为后续的测试提供完整的测试用例。
18. 需求变更
a. 开发人员为什么会抵触需求变更
b. 应对变更的技巧
c. 需求变更不可避免
d. 让开发和测试参会与需求讨论
e. 需求变更的预告
f. 如何说服开发人员接受需求变更
19. 事先准备的检查单
a. 事先准备好的检查单可以有效地帮助梳理需求的各种场景。
20. 时间轴
a. 时间轴解决在时间线上不同的事件按照不同的顺序发生的时候，对于业务结果的影响
b. 时间轴的多种形式
c. 时间轴的应用
21. 需求分析的时候做了多少不切实际的假设
22. 探寻需求背后要解决的问题
23. 需要事先声明的内容
24. 异步处理
25. 基础数据
26. 样例数据
仅仅通过其他形式不太容易理解的情况下，通过样例数据更好的展示了实际的效果。
27. 权限矩阵
28. 领域统一语言
领域统一语言是解决领域专家和技术专家之间沟通的问题的。它定义了通用术语，并且通过定义了英文名称避免了团队内用词不一致的问题。
a. 介绍什么是领域统一语言
b. 领域统一语言的各种分类介绍
29. 技术型需求
a. 技术型需求的多种类型
b. 技术型需求应该如何描述
30. 界面原型
原型解决了系统界面以及流程跳转的问题
a. 原型介绍
b. 界面原型
c. 界面流程图
d. 界面校验分离
31. 用户故事、用户故事地图、验收条件及需求梳理优化
a. 用户故事
b. 用户故事地图
c. 验收标准
d. JIRA管理用户故事的方法
e. 需求梳理及优化
32. 防止业务漏洞
a. 业务漏洞的发生可能的场景
b. 业务漏洞如何规避
33. 国际化和本地化
34. 思维导图 – 用于分解需求
35. 需求收集和探索
36. 数据建模
37. 需要有模板的需求
38. 报表及下钻
39. 需求管理
40. 外部依赖
41. 可审计性需求
42. 非功能性需求
43. Q&A表
44. BA工具箱的总结
45. BA所需要的技能
46. 如何和其他角色协作，知己知彼，百战不殆
a. 如何和程序员协作
i. 如何应对让做什么就做什么，毫不思考的程序员
ii. 如何激励程序员
iii. 程序员常犯的错误有哪些
b. 如何和Stakeholder协作
i. 阻止需求变更
ii. 防止需求蔓延
iii. 拒绝没有价值的功能
iv. 推动需求确认
v. 当需求部门迟迟不能确认需求的情况
vi. 当需求部门不知道应该提供什么资料的情况
vii. 共情，设身处地的收集需求
c. 如何和UI设计师协作
i. 最基本的设计知识
ii. 最基本的设计沟通方式
d. 如何和测试人员协作
i. 测试人员关注什么
ii. 提供必要的信息和资料
47. 需求评审会
a. 需求评审会做什么
b. 需求评审会怎么开
48. 需求梳理会
a. 需求梳理会做什么
b. 需求梳理会怎么开
49. 需求的验收
a. 用户故事和验收条件
b. 测试
i. 手工测试
ii. 自动化测试
iii. 集成测试
iv. 系统测试
c. 用户验收测试
50. 总结，Q&A，推荐阅读

报名咨询及获取详细课程大纲：

Tel: 021-34753688

Email: Service@UPerform.CN