business case 成本效益分析,不一定是客观的
dominated alternatives 劣势选择
context diagram 数据流图 项目早期确定的范围包括接口
用例之间的关系:include多个用例之间是重用的
extend是在某个用例上扩展功能
business case 成本效益分析,不一定是客观的
dominated alternatives 劣势选择
context diagram 数据流图 项目早期确定的范围包括接口
用例之间的关系:include多个用例之间是重用的
extend是在某个用例上扩展功能
governance 流程、批转、决策依据。流程管理
personas 虚拟人物画像
6.1现状分析
目标:
BA要了解现有的组织架构,现有的
输入:Needs和4.3信息搜集的结果
过程:定义商业需求(定义问题)
BA要回答的问题是What,但是定义What之前要清楚Why
Supervised: 输入大量规则、依据,然后做出判断
Unsupervised:无监督,从数据本身出发,发现趋势等等,不需要输入大量规则
diagnostic:针对问题寻找潜在原因
predictive:根据关联关系建立模型进行预测
data minging use consideration:了解
8.1 Measure Solution Performance:搜集和business objectives相关的数据
Qualities Measure:can be implemented through focus grop, obtainging users's feedback and suggestion related to product
Currency: current 时效性
Defining acceptance criteria can be viewed as defining requirements.as solution must meet acceptance criteria. So acceptance criteria also can be viewed as one type of R.
介绍各种收集信息的方式
1、协作的方式,需要不同的干系人进行接触,收集不同信息
2、做研究,独立进行对数据分析和挖掘,不一定需要和干系人进行沟通
3、观察、验证,
在收集信息过程当中,可能一种方法可能不够,需要多种信息收集方式
输入:
4.1需求收集的互动计划
需求收集活动指导
1、在需求收集过程当中,应该围绕主题展开
2、在过程中要做一些记录,录音或者笔记
指导方针和工具
1、之前的需求工作计划
2、已有的需求信息
3、干系人的沟通计划
4、支持的材料
目标:
文档分析:
目标:L对现有客户文档进行分析和收集,,步骤
1、目前该领域的文档、白皮书、功能介绍,组织内部的流程、规范和要求
2、文档的回顾和分析,关注根据具体需要,把问题记录下来,把不同的收集信息进行比对,
3、把文档进行汇总
文档的要注意的内容和注意事项、局限性
1、文档分析的有点:获取成本较低,文档
2、可以和现有状态进行验证
3、要保证现有文档不过时
4、文档的作者可能不在组织中,要确认可能找不到人了,可以在访谈过程中再确认文档的内容
5、通常是来评估现有的制度、流程,评估现有的状态
6、文档比较花时间和枯燥
技术:4.2在做详细介绍
干系人:
1、在准备阶段,可以询问领域专家得到一些信息
2、项目经理,该活动也是项目过程中的重要活动
3、发起人,从发起人火气一些资源,获得一些批准
输出
信息收集活动当中的时间、如何进行、目的、范围是什么,期望收集到的信息是什么,可以提前准备一些问题的列表,后勤的准备。为后续4.2具体执行收集信息做准备
内容:
1、过程:搜集和需求相关的信息4.1、4.2、4.3,内容不多,但是会涉及到很多
2、沟通:沟通相关的信息和干系人相关的活动,前提是3.2范锡仁的沟通计划和写作计划,以及沟通过程发现的问题,以及改进
Elicitarion:意在挖掘潜在的需求,或者引导除需求的信息和反馈,主意在于需要引入干系人,发掘干系人需要什么,需要BA帮助他们徐思考和梳理
3.5 分析工作的效果:有的组织有定期的绩效考核,还有一些非正式的评估绩效,包括书面、口头的形式
收集定量的评估定义,包括一些已经存在的考核定量内容,也包括定性的考核内容,可以通过和BA有交集的干系人,灵粮的内容可以使用报告的统计内容,考虑内容有:
1、工作的准确性、完整性
2、专业知识的撞我成都
3、工作的有效性
4、组织的支持程度
5、重要性
6、战略性
7、时效性
根据收集的指标进行分析:可能会有老板进行分析,也有可能有专门的组织进行分析
基于分析的结果,发现一些问题,基于根本原因需求改进措施:
1、预防性的措施,再评估和预测过程中发现的问题
2、修正型的措施,当问题发生时,需要进行的问题修正
3、改进型的措施,当问题需要完善
在制定计划刚开始的阶段,问题不太可能进行修正和改进,但是随着需求的进行,那么需要进行进一步的改进和修正
3.5识别在BA工作当中的一些绩效,并且寻求一些改进,要考虑计划和实际的一些偏差,在组织层面制定一些考核工作的标准,有一写外部的输入,作为绩效考核的目标Performance Ojectives
输入
1、Performance Ojectives绩效目标(外部)
2、商业分析方案
哪些信息需要做管理的:
需求、需求的评估结果、设计,可选的方案都是一些信息,需要进行有效管理的,在管理过程中需要考虑的因素有:
1、信息本身的种类/量级
2、需要哪些干系人访问这些哪些信息
3、信息的变化程度和规模
4、内在的关联关系,对关系进行一个保存和维护
抽象程度/详细程度:比如需求文档的详细程度,比如需求把用例的详细程度有什么样的要求,如果过于详细,考虑是否进行拆分,和进一步细化,在过程中要考虑一下因素:
1、干系人的需要
2、分析内容本身的复杂程度
3、变化本身的重要程度,可能重要的内容可能要更详细一点
计划可追溯到方法:跟踪需求之间的关联关系,例如变更会和其他一些内容有一些关联,所以考虑要不要做,做到什么程度,有以下因素要考虑:
1、业务领域的复杂程度
2、去了解需求的数量,方式方法的选择
3、风险、价值有多大
4、成本
计划需求重用:可能会参考之前的所写的一些需求,或许可能会给其他团队作为参考,给一个比较通用好理解的明明方式,所以要为重用做一些准备,根据名称就能了解内容,使用专门的保存、分享方式,i有哪次要考虑:
1、有些需求要持续得到满足的,比如在线率的需求,可能在整个解决方案中要考察是否得到满足
2、一般的的功能,比如登陆页面,是很多场景都要用到的,可以和其他团队进行分享
保存和访问的机制(仓库):例如在服务器上存放一个共享文件夹,翻遍信息的查看,要注意以下问题
1、谁需要访问这些信息
2、什么样的频率访问这些需求
3、在什么情况下需要进行访问,可能是内部团队进行访问,但是外部团队是没有办法访问的,因此可能要导出来进行分享
4、组织标准,使用安歇工具进行保存和分享
定义需求的属性:比如有识别号、作者、复杂程度、优先级、复杂程度、来源、风险、目前的状态是否得到批准,紧急程度等等
3.4计划BA信息管理,相比3.3来说。3.3是与决策相关的方法,3.4更多的对常规性的需求管理的工作,确保所有BA相关的信息进行保存、分享,在这些信息的生命周期中,得到有效的保存维护和分享
输入:3.1计划有哪些活动、3.2干系人计划(对干系人进行沟通需要那些干系人掌握i哪些信息).3.3(需要对信息进行审查和批准)
Stakeholders,在做决策和流程中涉及到业务领域展架,衡量变更的价值,对于业务的影响程度
项目经理,每个变更可能会影响到资源、进度、成本等因素
监管层面:要满足监管的要求
Sponsor:需求发起人的统意是重要的
输出:Governance Approach具体的需求的管理的计划、变更管理的计划,考虑的使用的方法;在每个项目中涉及到的要走流程都是不同的,但是包含人员、相关衡量的依据的制定
3.3相关的技术
Item Tracking:问题的跟踪,先把问题记下来,然后把问题进行分配,这些问题可能是风险、产品的缺陷、或者一些提出的变更请求、或者其他问题,各种需要跟踪的对象,需要一个机制和工作把问题记录下来,包括问题内容的属性:问题的代号、简短的描述、分类、识别的时间,发现人、优先级,负责人,谁解决问题,解决时间,不同的状态,不同的解决方法,如果解决不了,那么需要怎么杨的提升机制,以便进行管理,在管理的过程中会记录一些解决问题的效率,比如一个过程出现了多少个问题,文档中出现了多少个错误,每个问题的提出到解决所经历的时间长度,帮助我们评判解决问题的效果效率,衡量我们工作的效果的指标,以便我们发现问题去解决问题
使用限制:优点是可以帮我们发现要解决的问题,而不被忽略掉,有可能发现数量非常庞大的问题清单,如果每个都去解决,可能无法对优先级更高的为你进行解决,所以我们要注意不是所有问题都是值得去解决的,因此要注意优先解决重要的问题
3.3 的指导工具:
1、之前BA的绩效给予一些指导
2、业务的政策制度,可能有些组织已有一些制度
3、现有的组织的状态,组织结构,干系人的状态
4、法律法规以及组织的政策,包括内外部的法律法规和一些工作要求
3.3 Governance 是说在需求相关的活动中,要走一些流程,决策的过程是什么,参与决策的人包含哪些,决策的依据是什么
3.1计划方案和3.2干系人计划作为本身的输入,
这个计划是要让所有干系人理解
输出:干系人计划,干系人的登记册、清单,沟通计划,协作计划,也可能是整合到一个计划当中去
完成3.2需要的技术:
1、通过头脑风暴的方式分析
2、通过访谈,调研、研讨会的方式
10.32组织模型:
目标,通过组织架构图分析不同的的角色,人员之间的汇报关系,组织架构,花店案例描述了组织结构和人员关系,体现在组织架构图中的信息
组织结构的模式:
1、职能导向Functionalaly Orientd
2、市场导向Market-Orientd,根据服务不通过的时间地理区间,或者不同客户的类型,大客户中客户等
3、矩阵导向的模型 Matrix Model,前两种模型的叠加,
体现组织部门人员汇报关系
Interfaces:依据汇报关系,沟通的方式构成的组织关系
组织模型:
1、影响,通常是说组织明显的划分,也会出现隐含的汇报渠道,在组织加沟通通常体现不到,但是也是一种汇报方式
2、使用场景和制约因素,组织的变化和过失会影响组织架构的体现
干系人清单、图谱(10.43)
1、干系人列表,通过一个表格描述干系人的角色、类别、期望、影响程度、权限、沟通方式,可以整理一些模板来收集一些信息
洋葱图Onion Diagram,中心的就是Solution Delivery 例如项目经理,实施团队等
1、Affected Organizational Uint 。例如最终用户、Help desk服务台呼叫中心、其他当方案实施过程中收到影响的人员和组织,例如店员、花艺师、技术部
2、Organization or Enterprise。包括Sponsor发起人、executives执行者、领域专家Domain SMEs、其他在有效组织中互动的人员和组织,例如经理、采购、财务
3、Affected External Stakeholder,客户、供应商或者其他部门
Matrix 影响力坐标图,四个象限。行轴:利益,纵轴:影响力
1、关键干系人Key Players,Work Closely with them
2、Satisfy thair needs,组织内部间接收到影响的干系人,和需求工作本身关系不大的人员和组织
3、Keep them informed;show consideration。可能会收到影响的,但是利益相关,但是力量不足,在沟通过程中适当关心
4、Monitor changes,随时关注可能会出现的变化,可能随着项目范围的变化,可能会出现该类干系人的移动到其他象限的变化
Responsibilities(RACI) Matrix:把每个成员的角色分为【R】esponsibile,【A】ccountable,【C】onsult,【I】cform
【R】esponsibile:具体执行某县工作的人
【A】ccountable:对某项工作负责的,是说每项工作都有很多人执行,但是这个人是唯一对这些那个工作负责的
【C】onsult:咨询,做这个事的时候需要对这个人进行咨询。获取一些建议和知识
【I】cform:告知,这个活动的进展情况需要让这个人悉知
对于每项任务,团队中每个人都有不同的负责的角色
Personas:虚拟人物,在很多干系人分析中,有些用户在互联网中,他的需求是否能够代表所有用户的需求,让他尽可能接近所有用户的需求,比如某一年龄层次的人群,我们可以认为他是某一个人,年龄、居住区域、受教育程度,要根据掌握每一种虚拟客户进行功能的设计
花店的例子,列出任务的特征、特点
方法使用的限制或前提条件:
1、根据不同特殊干系人,需要用不同的方法
2、在项目进行中是持续的一项工作
3、干系人分析的结果,有些信息是公开的,但是有些干系人是存在敏感的信息,要紧系特殊的考虑,包括特殊办法的分享,例如小区的业务的出行时间等设计业主安全信息不能将这类信息分享,所以不是所有信息能够在干系人或者项目组内部进行分享的
制定干系人计划
1、干系人分析。识别干系人,收到影响和施加影响的干系人,可能就会有不同的干系人,收集需求过程中,干系人的角色、态度、决策的权限、权力或影响力大小,干系人的分析在需求持续过程中要持续的去做
2、进一步定义干系人需要协作的活动。干系人的参与时间、地点,以及如何参与,参与的方法:在线的会议,面对面的沟通,远程视频会议的沟通方式,另外还要注意干系人的偏好(什么样的沟通方式)
3、沟通相关的需要,每个人需要的信息不同,详细程度、格式,和方法、以及信息的种类,交付的方式,在什么时间,地理分布,沟通的重视程度,针对特定的要求
注意干系人扮演的角色:
1、干系人的角色
2、干系人的态度
3、干系人决策的权限,决策需求、变更需求
4、干系人影响力大小、决策力大小