导图社区 PBA考试-拆解-商业分析实践指南
"掌握商业分析核心工具,轻松驾驭项目全流程!本指南涵盖商业分析全生命周期:从需求评估、规划到解决方案发布,结合PMP经典公式(如EV、CPI)与实用图表(帕累托图、龙卷风图)。重点解析5大关键步骤:1.需求评估→2.规划→3.启发分析→4.跟踪监督→5.执行评价,并详解需求分类、变更管理和跟踪矩阵等实战技巧附赠成本控制(BAC/EAC)与风险管理(蒙特卡洛分析)方法论,助你精准把控项目质量与风险" .
编辑于2025-09-19 12:19:58"掌握商业分析核心工具,轻松驾驭项目全流程!本指南涵盖商业分析全生命周期:从需求评估、规划到解决方案发布,结合PMP经典公式(如EV、CPI)与实用图表(帕累托图、龙卷风图)。重点解析5大关键步骤:1.需求评估→2.规划→3.启发分析→4.跟踪监督→5.执行评价,并详解需求分类、变更管理和跟踪矩阵等实战技巧附赠成本控制(BAC/EAC)与风险管理(蒙特卡洛分析)方法论,助你精准把控项目质量与风险" .
1.组建产品创新改进跨职能团队,要有高级管理层代表支持。2.识别那些真正提现产品创新并能够实现整体经营目标的关键绩效指标。3.将组织与其它组织总结的最佳实践进行对标。
(第二版)NPDP考试——第5章-市场研究知识梳理,包括一级与次级市场研究、市场研究方法、定性市场研究方法、多变量研究法等内容。
社区模板帮助中心,点此进入>>
"掌握商业分析核心工具,轻松驾驭项目全流程!本指南涵盖商业分析全生命周期:从需求评估、规划到解决方案发布,结合PMP经典公式(如EV、CPI)与实用图表(帕累托图、龙卷风图)。重点解析5大关键步骤:1.需求评估→2.规划→3.启发分析→4.跟踪监督→5.执行评价,并详解需求分类、变更管理和跟踪矩阵等实战技巧附赠成本控制(BAC/EAC)与风险管理(蒙特卡洛分析)方法论,助你精准把控项目质量与风险" .
1.组建产品创新改进跨职能团队,要有高级管理层代表支持。2.识别那些真正提现产品创新并能够实现整体经营目标的关键绩效指标。3.将组织与其它组织总结的最佳实践进行对标。
(第二版)NPDP考试——第5章-市场研究知识梳理,包括一级与次级市场研究、市场研究方法、定性市场研究方法、多变量研究法等内容。
商业分析实践指南
1.需要评估
需要评估的步骤
1、识别问题或机会
内容
识别干系人
分类
项目发起人
获益人
财务提供者
使用人
被影响人
能对方案作出部分或全部限制的人
参与执行者
支持者
output
干系人登记册
一份涵盖了项目干系人的识别、评估、分类的文件
【工具与技术】
RACI模型
R-Responsible-负责
谁负责执行
A-Accountable-批准
谁负责批准
C-Consulted-咨询
谁提供咨询
I-Informed-通知
谁被通知
调查问题或机会
收集相关数据来评估情境
起草情境说明书
对商业问题或机会的客观说明,包括说明本身、情况对组织的影响以及由此产生的影响
格式
问题或机会是a
具有的效果是b
产生的影响是c
获取干系人对情境说明书的批准
有了情境说明书,就意味着获得了已识别出的受影响干系人的同意
可正式或非正式
【工具和技术】
标杆对照
竞争分析
文档分析
访谈
市场分析
原型
2、评估组织的当前状态
步骤
评估组织目的和目标
商业需求是目的、目标及组织的高层级需要,提供了项目得以执行的 缘由
目的和目标
目的
通常更广义并可能延续一年以上
目标
在于成就目的。目标更为具体,通常比目的期限更短,比如一年或更短
SMART目的和目标
S-Specific-具体
M-Measurable-可测量
A-Attainable-可达成
R-Relevant-相关性
T-(Time-bound)-时限性
SWOT分析
内忧
SW
外患
OT
衡量相关的标准
衡量标准与目的目标相结合
对情境进行根本原因分析
定义
根本原因分析
确定引起偏差、缺陷或风险的根本原因,可用于发现问题的潜在原因
机会分析
关于潜在机会的主要方面的研究,以确定成功推出新产品或使其成就的服务的可行性
方法
5Why
因果图
鱼骨图
关联图
过程图(流)
确定解决情境所需的必要能力
方法
能力表
用于分析当前或将来的状态的能力
亲和图
标杆对照(Benchmarking)
评估组织的当前能力
方法
过程流
企业和商业架构
能力框架
定义
关于对组织的关键技能、知识、行为、能力、系统和整体能力的一组描述
要素
物理
金融
信息
知识
人员
卡诺分析
目的对齐模型
识别组织能力的差距
产出物
《组织能力差距》
差距能力分析表
3、建议满足商业需求的行动
纳入增加能力的高层级方法
为满足商业需求提供可选方案
识别每个选择项的约束条件、假设和风险
约束条件
对团队执行项目集或项目的选择的任何限制,可能与商业 或技术相关
假设
被认为正确的、真实的或肯定的,无须实际证据或证明的因素
风险
是不确定的事件或情形,假如发生的话,可能对一个或多个项目目标产生正面或负面的影响
风险管理
目的
促进机遇并降低威胁
风险识别
关注问题,从问题源和问题本身来进行风险的识别
风险分类
将风险根据影响、概率或其他因素分成不同的领域,便于更好地分析
初步风险分析
分析潜在的危害事件,这些潜在的危害有可能转化为事故
风险分析
定义和分析潜在的威胁,对个人、企业和政府机构造成的危害因素
定量风险分析
蒙特卡洛
敏感性(龙卷风图)
工具
访谈
通过采访相关方来获得相应信息,它依赖于经验和历史数据来估算风险对项目目标的影响概率
定性风险分析
定义各种威胁,确定风险大小,并制定可能的应对措施
承受力(容忍度)
风险追求
风险中立
风险厌恶
风险控制
应对策略
开拓
提高
接受
缓解
转移
避免
风险治理
目的是通过前中后台的合作,形成风险控制机制,以达到有效检查和平衡的效果
评估每个选项的可行性以及对组织的影响
可行性因素
运营可行性
解决方案能在多大程度上符合【商业需求】
技术/系统可行性
保障性
成本效益可行性
企业的根本
时间可行性
文化可行性
评估因素
评估每个预期方案选项的可行性因素来确定这些选项对之前评估的目的和目标能有多大程度的贡献
推荐最可行的选项
没有选项时
不要做任何事
多个时
方法
加权排序
标准范围
3-9个方案
为建议的选项执行成本收益分析
投资回收期(PBP)
越短越好
投资回报率(ROI)
越高越好
初始投资的回报百分比
内部收益率(IRR)
>基准收益率,越大越好
给定项目期望获得的估计增长百分比
净现值(NPV)
>0且越大越好
收益成本比(BCR)
(项目总金额+利润)/利润
投资收益率(BOI)
利润/项目总金额
4、组合商业论证
意义
一致性地审查项目集和项目
使决策者确定项目集和/或项目是否值得所需的投资
提供有据可查的可行性研究
确定组织是否应该解决问题或机会
要素
问题/机会
详细说明什么是正在刺激行动的必要
情境分析
列出组织目的和目标以评估一个潜在方案如何对目的和目标提供支持和产生贡献,包括问题的根本原因或机会的主要贡献因素
建议
呈现每个潜在选项的可行性分析的结果,识别每个选项的任何约束条件、假设、风险和相关性
估算(评价)
包括测量收益实现的计划
2.规划
商业分析规划的重要性
商业分析规划的意义
定义了与商业分析活动的规划和监督相关的任务
人
识别干系人
定义商业分析中干系人的角色与责任
规划商业分析师如何与干系人沟通
流程
定义与确定商业分析流程
量
确定商业分析产出的可交付成果
制定商业分析任务的估算
规划需求将如何被处理、跟踪与排序
标准
确定监督商业分析工作的衡量标准
重要性
理解项目工作范围
了解干系人期望
了解项目所需的恰当商业分析工作量和程度
要完成的事项
和发起人、项目团队以及关键干系人一起设立对于将要采取的商业分析活动的期望
确保对角色进行了识别、理解,并和参与商业分析过程的所有人进行了充分沟通
在工作开始前取得对商业分析过程的认同和支持
提供支持商业分析活动评估的环境
创造一个更有效运作的商业分析过程,前提是没有遗漏或过度执行任何活动
商业分析规划和项目管理规划
商业分析师会开发一个工作计划来涵盖他们负责执行的活动,工作计划应由项目经理纳入整个项目管理规划。
步骤
1、引导或提炼干系人分析
识别干系人
技术
头脑风暴
组织结构图
流程图
定义干系人的特征
特征
态度
支持/不支持
积极/消极
复杂度
干系人群体是否
人太多
由需求大而不同的干系人组成
有大量业务过程受项目影响
商业过程中显示出缺少一致性
与一系列商业单位互动才能完成他们的工作
需要通过一系列IT系统,以及外部系统才能完成工作
文化
文化差异的影响
进行工作
与其他团队成员互动
致力于决策过程
进行非语言沟通
理解团队主要的书面和口头语言
质疑劝我还是与权威互动
回顾他们在团队中的角色
提出质疑或问题
协商
处理冲突
妥协
各方要放弃一些条件,达成一致
合作
让团队加强协作,减少冲突
强迫
问题必须快速解决,摒弃个人意愿
经验
参加需求研讨会或需求验证方面的经验
行业经验年限
商业知识了解程度
影响力水平
位置与可用性
影响
确定最有效的启发需求技术
评估需要多少时间完成商业分析活动
决定商业分析可交付成果所需的正式性和详细程度
决定使用的模型类型
确定合作的方法和频率
确定如何管理和维护需求,以及如何与项目干系人分享需求
分组或分析干系人
分组属性
兴趣
共同需求
重要程度
角色
激励
复杂度
地点
称号-主要/次要
技术
工作分析(描述性)
识别有效执行所需要的能力、任务
人物分析(行为性)
理解不同干系人群体的特征
产生一个角色组织图作为其建模的工作
干系人地图
干系人矩阵
洋葱图
输入
企业架构
商业需要
组织过程资产
整合干系人分析结果
与项目经理、项目团队、发起人分享。谨慎考虑分享的对象
2、创建商业分析计划
流程
1、商业分析计划和需求管理计划的概念
商业分析计划用于记录如何执行商业分析过程,包括项目团队同意的计划决定
需求管理计划是项目管理计划的一个组成部分,它描述了项目的整体需求将如何发起、分析、文档化和在整个项目中如何被管理。需求管理计划涵盖了产品和项目需求的规划决策
2、商业分析计划的内容
内容
产生的商业分析可交付成果
参与需求活动的角色和职责
将要开展的启发活动类型
7、启发规划
考虑因素
干系人
干系人群体的特征和动态
干系人的数量
干系人的地域
项目
项目生命周期
项目的类型
时间制约因素
技术的特点
预算
成果
产出的需求可交付成果的类型
商业分析可交付成果需求的详细程度
参与的商业分析人员和关键干系人熟悉的相关技术
启发活动的排序策略
获得大量重要的商业价值
更大的风险
项目的许多未知和不确定性
重要的技术挑战
对于其他组件或接口的依赖性
项目所依赖的第三方资源
有限的资源或一个关键资源可能离开项目或公司的风险
所需或期望的需求分析模型
8、分析规划
需求将如何分优先级、审批和维护
9、定义需求优先级的过程
考虑因素
需求优先级何时将会发生
优先事项变更的可能性
将参与确定优先级过程的干系人
用于确定优先级的技术
用于确定优先次序的标准
批准优先级决定的干系人
判断准则
价值
首先处理能先获得较高的财务或商誉收益的需求
成本
基于财务成本或机会成本评估需求
难度
考虑实现需求有多困难
监管
首先处理需要遵守的法规或法律的迫切需求
风险
先执行高风险的需求,从而尽早发现问题
技术
MoSCoW
多票制
时间盒
方法类型
全部包含
先有初始列表,然后逐一移除
全部移除
选择法
加权排序
标准范围
3-9个方案
在项目仲跟踪和管理的需求状态
10、定义跟踪方法
跟踪决策类型
跟踪的需求类型
跟踪的详细程度
将要建立和维护的关系
跟踪的需求属性
推动需求生命周期的需求状态(例如,批准、推迟、拒绝等)
用于执行跟踪的工具
有关如何将建立和维护跟踪的过程决策
如何记录需求并将其传达给干系人,包括如何使用专用工具
11、定义沟通方法
考虑因素
需要沟通的需求以及与需求相关信息的类型
哪些人需要沟通和他们期望得到什么信息
干系人接收信息的偏好(例如,概括或详细程度)
分发或访问需求,以及与需求相关信息的首选传递方法
沟通所需的正式程度
工具,包括干系人要访问的需求资料库
沟通渠道计算
N(N-1)/2
N=团队成员+干系人
出书文档
商业分析沟通计划
12、定义决策过程
确定优先级、记录、验证、沟通、批准和更改需求,消除冲突的观点
如何确认和核实需求
13、定义需求核实和需求确认过程
需求核实
实是关于产品、服务或系统是否符合法规、要求、规范或强制条件的评价
需求确认
确认是对产品、服务或系统能满足客户和其他特定干系人需要的肯定
14、定义需求变更流程
流程
如何提出需求变更
如何审查变更
如何记录变更管理决策
如何沟通需求变更
一旦变更得到批准,如何更新需求、模型、跟踪和其他相关需求的信息
人
谁负责提出变更
谁负责进行评估或影响分析
参与变更讨论的角色
谁负责审批变更
如何确定“确认需求”和“解决方案”所需的验收标准
15、定义解决方案评估过程
考虑内容
评估标准和接受级别
进行定性、定量的评估活动
将如何评估解决方案
何时及每隔多久会进行评估
使用的评估技术。例如,焦点小组、观察法、调查等
是否需要特殊的测量工具
将如何分析和报告结果
详细程度
平衡灵活性和管理
不要为了灵活性而牺牲好的管理实践
3、了解项目环境
项目属性
项目规模
项目复杂程度
项目类型
项目时间紧迫性
选定的项目生命周期
风险
风险级别
风险承受力
市场
市场环境/竞争格局
市场需求的时间
空间
干系人地域分布
法规
强制的制约因素或法规
技术趋势
可交付成果的详细程度和形式
分配给该项目的商业分析师的经验级别
4、了解项目生命周期如何影响规划决策
生命周期模型
预测型(瀑布式)(计划驱动)
大多是在前期进行商业分析,在产品开发前定义好需求
适应型(敏捷式)(变更驱动)
早期商定总体范围,每次迭代时定义详细的范围和产品需求,商业分析是持续不间断的
迭代/增量型
项目被分成若干阶段,每个项目阶段刻意进行重复
大部分商业分析在前期完成,小部分在项目进行中完成
生命周期模型对商业分析过程决策的影响
要执行的商业分析活动
活动完成的顺序
活动的时间
可交付成果
可交付成果的正式程度
确定需求优先级的方法
处理需求变更的方法
5、确保团队完成项目生命周期培训
6、规划时借鉴历史经验
经验教训
特点
主要阶段结束或项目完成后:事件驱动
更正式,需要做记录
回顾
特点
固定时间表驱动
节奏快,简单记录
目的
提高团队绩效
步骤
搭建舞台
收集数据
问题列表
什么是正常的?
什么是不正常的?
需要变更什么?
产生深刻理解
决定做什么
结束回顾
【工具和技术】
燃尽图
如果新增加了功能,是放在下次迭代的下方
分解模型
把一个概括性的目标分解为较小的独立部分的技术
估算技术
亲和估算
自下而上估算
汇总低层级任务的估算
德尔菲法
估算扑克
相对估算
找最相似的做参考
宽带德尔菲
规划技术
产品待办事项
滚动式规划
迭代式的规划技术,对近期要完成的工作进行详细规划,对远期工作制作粗略规划
故事地图
工作分解结构(WBS)
3、规划商业分析工作
确定谁完成规划商业分析工作
项目经理主负责,商业分析师辅助
建立商业分析工作计划
6个活动
识别可交付成果
例子
需求文档
软件需求规格书
用户故事
商业规则目录
非功能性需求列表
考虑因素
将产生什么可交付成果
其他团队成员和关键干系人如何使用可交付成果
如何管理可交付成果变更
可交付成果所需的形式
可交付成果将被如何访问,被什么人访问
产生、维护,或储存可交付成果所需的工具
需求是否在未来的项目中被重新使用
确定任务和活动
技术
分解模型
把一个概括性的目标分解为较小的独立部分的技术
头脑风暴
访谈
经验教训
确定任务的时间和顺序
考虑因素
完成工作所需资源的可用性
工作依赖于商业分析成果的后继接受者的需要
项目工作与组织内其他工作的关系
合同和工作说明书的义务
商业分析工作的培训和工具的依赖关系
员工和新员工的需要
任务的风险和复杂程度
确定角色和职责
RACI模型
识别资源
确定哪些资源对于工作是需要的,并识别任何可能资源过度分配或遗漏的领域
预估工作
考虑因素
项目规模和复杂性。
选定的项目生命周期。
含糊不清的已建议的解决方案的数量(例如,当利用新兴的技术或使用该组织没有太多经验的解决方案时,模糊性会更高)。
参与到启发活动中的干系人和干系人群体的数量。
考虑的启发技术的类型。
参与到商业分析活动的人的位置(包括商业分析将要对口的产品开发和测试资源)。
进度和预算的约束。
任何已知的假设。
已产生的商业分析可交付成果数量。
商业分析可交付成果的正式手续与详细程度。
项目团队的经验水平(包括分配到项目的商业分析团队和参与需求相关活动的干系人)。
整合商业分析工作计划
详细程度考虑因素
商业分析工作的复杂性。
项目规模。
被追踪的商业分析工作的数量。
项目生命周期类型。
图例
记录商业分析方法的基本原理
商业分析方法
定义
商业分析方法描述了如何完成商业分析的方法
输入
组织过程资产(过程模板)
商业需要
专家判断
原因
对团队
回答工作为何要进行
对未来
有助于未来规划工作
和关键干系人审查商业分析计划
目的
减少干系人在工作开始时不支持商业分析活动的风险
邀请谁?
负责审批、排序,或确认需求的。
对变更控制过程中某个角色负有责任的。
对参与到需求活动中的人员有管理职责的。
作为该项目的主题专家而负有责任的。
获得商业分析计划的批准
目的
商业分析过程开始后干系人不给予支持。
项目团队低估了商业分析活动需要的时间。
分配给项目的需求阶段的资金不足。
关键干系人低估了需求活动所需的参与资源或参与者的级别。
在需要时,关键资源不能参加需求活动。
审批格式
正式
非正式
审批人
发起人
关键干系人
3.启发与分析
启发
定义
【启发】是一项从干系人和其他来源提取信息的活动
启发过程不仅仅是收集或汇总需求
清晰的需求
收集、汇总
潜在的需求
引导、验证
重要性
支持行政决策
成功应用影响力
协助谈判或调解
解决冲突
定义问题
步骤
规划启发
制定启发计划
计划中的元素
要启发什么信息
在哪里可以找到这些信息
如何获得信息
排序启发活动
输出
启发计划
准备启发
内容
确定目标
获得信息的价值和效益
确定参与者
参与者的经验与背景
识别资源
信息、位置、设置、帮助
确保启发活动的资源得到承诺,以使启发活动顺利开展
确定启发活动的问题
设置议程
资料分发;待准备的分析模型
安排启发活动
适当的时间;确保支持资料
例子
输出
启发笔记
开展启发活动
步骤
引言
确定活动基调,并提出启发讨论的总体目标
主体
软技能
积极倾听
移情
肢体语言
选择要提的问题
问题的类型
开放式问题
封闭式问题
选择题式
语境问题
围绕主题的问答
语境无关问题
任何情境下可问
问题排序
影响力
结尾
结束前提问
你还有其他的问题吗?
我们是否有遗漏,或我们还有什么应该谈论却还没有谈论的事情吗?
还有谁可能掌握有助于启发目标的信息?
跟进
综述小节的好处
提供了对收到的所有信息进行全面分析的机会,同时消除那些无关的材料。
为核实和澄清讨论中所做的笔记留出了时间,尤其是那些为了获取完整的信息而使用的首字母缩略词和缩写。
发现讨论会议中应该被提起但是没有提及的问题。
重申参与者提供的信息非常有价值,值得人们理解、分析和总结。
让每个参与者有机会为综述小结提供补充资料。
为参与者提供一次澄清或纠正先前所说内容的机会。
输出
启发总结
工具与技术
协作游戏
产品盒
快艇
蜘蛛网
完成启发
启发完成的情况
干系人或问题所有者批准了结果。
基于信息的模型是可以被完成的。
试运行或成功的原型已经完成。
目标已经实现。
解决方案已经确定。
干系人开始重复之前提供过的信息,并提供一些冗余信息。
从相同的干系人那里获得答案要使用更长的时间。由于启发仍在进行中,干系人努力地想出与之前所提供的信息不同的新信息。
属于高优先级需求的所有信息都已经被至少两个独立的来源证实。
输出
启发文档
启发技术
头脑风暴
文档分析
优点
记录信息往往更客观
文档可能包含无人所知的信息
书面对信息把握更加准确
对相同材料,书面比个人说明提供更多信息
缺点
可能找不到
可能信息过时
引导式研讨会
意义
快速定义跨职能部门的要求和消除干系人差异
达成共识
内容
概述
研讨会准备
按照角色邀请参与者
研讨会提示
结束的提示
跟进的提示
形式
时间
1.5-2小时
人数
8-12人
对象
跨职能部门干系人和项目团队
焦点小组
需要主持人
8-12人一组
单面镜
对象
干系人和主题专家
访谈
类型
结构化
从预设问题清单开始,目标要求是在分配的时间内提出清单上所有问题并获得答案。
非结构化
从预设问题清单开始,但只有第一个问题是确定会提出的。接下来的问题将取决于上一个问题的回答。
进行方式
同步访谈
同时进行,包括面对面或通过网络
异步访谈
非同时进行,例如e-mail或录音录像
观察
类型
被动观察
旁边看,过程中不打扰人
主动观察
旁边看,过程中会提问,打扰人
参与式观察
观察者参与其中,可以问人
仿真
使用模拟的工具去模拟目标活动、操作、工作流程
特点
对使用产品的人不愿意表达要求时有帮助
原型法
类型
低保真原型
高保真原型
抛弃式原型
一旦界面被确认,就将被废弃的原型。这类似于由制造企业开发的产品原型。原型用来帮助定义产品制造的工具和过程,但原型本身不卖。
演进式原型
在过程中的实际成品,第一个经过检查的原型是最终产品最早的可工作版本。在每个后续的原型会上,更多的功能被添加或对现有的功能改进,以达到一个更高的质量水平。
水平原型
只需要制作网站首页和第一层链接层面的原型
垂直原型
只具备某一项功能的原型,这是从操作层出发的深层原型
技术
故事版
线框图
关键因素
迭代过程
问卷和调查
调查
调查可用于从规模巨大且/或地理上分散的人群中收集信息和启发需求
启发过程的挑战与对策
商业分析师不能访问到合适的干系人。
关注信息而不是关注个人
干系人不知道他们想要什么
使用原型或故事板等技术
干系人难以定义他们的需求
保持专注于高层级的需求
干系人没有提供足够的细节
可视化模型技术启发需求。
分析
步骤
准备分析
分析需求
分析计划
分析定义
分析是检查、分解、合成信息以进一步了解、完善和改进信息的过程。
预先思考分析
哪些类型的模型最有利于已知的项目
分析什么
选择正确的信息来分析,分离出那些妨碍正确分析的信息
执行分析
模型化与优化需求
模型描述
以图表、表格或结构化文本的形式,以简洁的方式有效排列和传达大量信息
模型目的
识别信息差距
识别无关信息
为更好地理解和更清晰地转化信息提供背景
识别并完善重要且有价值的需求,以确保创建正确的需求
需求分析工具和技术用于开发相关方需求和解决方案需求
模型分类
5种模型概况
范围模型(分析前)
目的模型和商业目标模型
组织并反映目的、商业问题、商业目标、成功衡量标准和高层级功能的图标,呈现项目价值的来源
生态系统图
理解所有可能受影响的系统或将会影响范围内其他系统的系统。用于业务层分析
系统交互图
开发中的系统和其他系统或人之间所有外部触点,确定哪里有接口需求或数据需求
有时被称为
0级数据流图
功能模型图
有助于说明功能是如何组合在一起的,以及哪个功能是其他功能的子功能
用例图
概括解决方案的范围,突出添加的主要功能(即用例)。这些图还显示了直接与解决方案交互的干系人(参与者),以及在系统功能(用例)和参与者之间需要创建的接口
规则模型(分析前、分析中)
商业规则目录
商业规则目录是商业规则和相关属性的表格,商业规则本身不是过程或程序,而 是描述如何限制或支持行为
决策树和决策表
决策树和决策表都是用来建模复杂的分支逻辑
决策树
决策表
决策分析
基于组织的需求和目标对可用的方法进行评估和决策
重点关注成本收益分析,即解决方案成本与收益
过程模型(分析中)
过程流(泳道图)
通过跟踪需求的各个步骤,用来识别丢失的功能或需求
用例
用例用于用户和系统之间有复杂的来回作用的场合
用户故事
作为一个(参与者),我希望能够(功能),这样我可以(业务原因)
INVEST原则
I-independent-独立
N-negotiable-可协商
V-valuable-有价值
E-estimable-可估算
S-small-小
T-testable-可测试
数据模型(分析中)
实体关系图(商业数据图)
是项目中有数据管理组件的基础模型,它有助于识别那些被创建,被使用或从系统输出的数据
数据流图
描述数据在参与者和系统之间经过一个或几个过程中的流动
数据字典
用于明确数据非常详细的方面,并从商业干系人的视角获取数据域和属性
状态表和状态图
帮助商业分析师明确解决方案中一个对象的生命周期
状态表
状态图
椭圆
状态
箭头
过渡事件
接口模型(分析后)
报告表
有助于提供关于报告的附加细节,这些细节不能通过看实体模型来收集
系统接口表
用来详细说明解决方案中系统间每个接口的细节
用户界面流
帮助跟踪所有需要进一步定义的屏幕界面(界面跳转逻辑)
线框图和“显示——操作——响应(交互说明)”
识别页面元素和功能
线框图
“显示——操作——响应(交互说明)”
模型选择
考虑因素
方法论
项目的特征
项目生命周期的时间点
模型类别
抽象程度
使用模型细化需求
使用模型来确定什么是重要的和有价值的,以便创建正确的需求
建模语言
记录解决方案需求
需求文档化的重要性
作为核实干系人需要的基准。
作为商业问题或机会解决方案的基准定义。
作为设计团队、开发人员、测试人员和质量保证人员工作的主要依据来源。
用户手册等文档的基础,无论它是输入形式还是直接嵌入形式。
在特定情况下,它就是合同的支持性细节。例如,对于招标书( RFP)来说,需求文件是项目工作说明书(SOW)的核心输入项。
解决方案演进的出发点。
项目可重用性的基础。为想了解该项目细节的其他项目团队提供文档,无论该项目是处于运行中还是已经结束。
监管行业和高风险项目的审计基准。
商业需求文件
商业需求是组织的目标、目的和高层次需要,也为新项目提供了论据。
解决方案文件
内容
包含产品或服务的特征、功能,以及特性,用以满足商业和干系人的需求
形式
商业需求文件
系统/软件/功能需求规范
书面的用户故事
包含非功能性需求的用例集
产品未完项列表
需求
商业需求
干系人需求
解决方案需求
功能性需求
非功能性需求
过渡需求
输入
部署的解决方案
规定的需求
组织准备评估度
需求分类
过滤器
范围过滤器
功能类别过滤器
优先级过滤器
可测性过滤器
需求规范
记录假设
记录制约因素
常见制约类型
地理
法规
组织政策
文化
需求编制指南
功能要求
高质量需求特点
明确性
精确性
一致性
正确性
完整性
可测量
可行性
运营可行性
技术/系统可行性
成本效益可行性
时间可行性
可跟踪性
些能够追溯到需求来源,并能够依据开发生命周期跟踪到测试用例的需求
可测性
需求应该以易于测试的方式来描述
需求优先级排序
技术
MoSCoW
多票制方法
让参与者对一组需求清单进行投票,基于得票数来确定答案
时间盒法
先分析项目团队在特定时间段能够交付的工作量,然后据此对需求进行优先级排序的技术
加权排序
先确定决定的标准。可能的选项有:效率、易用性、吸引力等。一旦标准列表确定,则 为每个标准分配一个分数
参与干系人
事项专家
领域主题专家
项目经理
技术需求规范
元素
线框图
模拟界面
数据模型和模式
详细流程。例如数据流图
详细要求。例如技术参考
记录用例
记录用户故事
未完项
是一份具有优先级的产品需求和待完成的交付物,通常以故事形式记录
核实需求
定义
检查需求是否满足质量要求的过程;审查要求和其他产品信息是否存在错误、冲突和遵守质量标准的情况;评估需求和其他产品信息是否符合法规、规范或强制条件
技术
同行审查
确保书面商业分析成果包括各种形式的需求文件,满足组织的标准和通用需求编写准则。
走查
材料的作者通过讲解撰写的信息引导同行评审
检查
更严格的同行审查方式。
《需求检查清单》
同行审查取决于专家的知识,而检查则利用了已知产品缺陷的清单
确认(验证)需求
定义
检查需求是否满足商业目标和目的;确保产品满足客户和其他识别相关方的需要
类型
持续确认
有助于将需求文件按照功能进行分组,也有助于让干系人确认和他们相关的需求。【确认】不等于【批准】
需求巡检(例行检查)
用于与干系人一起评审需求,并得到他们对于需求有效性的确认
滚动式
完成分析
排序需求和其他产品信息
了解产品如何实现干系人目标的过程,并使用该信息以及其他商定的优先级因素来促进工作的排序
常见的排优先级方案
购买特性
使用虚拟钱购买相关方自己选择的功能;通过计算所有相关方每个功能花费的总金额来确定优先级
德尔菲法
MVP
MoSCoW
多重投票法
目的对齐模型
时间盒
设置严格的时间限制,并仅优先考虑团队在该时间段内可以完成的工作
加权排序
标准范围
3-9个方案
加权最短优先作业
主要用于适应型框架,根据商业价值和工作量以外的更多维度对用户故事进行排名
批准(审批)会议
获取需求签署;与“确认会议”分开进行
需要的签字
商业负责人(发起人) – 需求代表解决问题的完整和准确的解决方案
解决方案研发团队接收方(客户) – 足以构建记录的解决方案
商业分析师 – 准备可交付成果
解决和需求有关的冲突
德尔菲技术
多票制方法
加权排序
标准范围
3-9个方案
4.跟踪与监督
跟踪
定义
建立对象之间连接的方式来跟踪整个产品生命周期中的信息。这些连接也被称为关系或依赖关系
作用
跟踪项目中的问题状态和解决情况
需求跟踪的收益
有助于确保每项需求都能增加商业价值。
有助于满足客户期望
有助于管理范围
跟踪范围
商业需求
项目范围
产品组件
需求模型
功能需求
测试用例
可交付成果
跟踪矩阵(RTM)
作用
明晰需求间逻辑关系
启发更多需求细节
为项目的落地与推进提供保障
防止项目范围蔓延和镀金情况
跟踪矩阵层级
分层的作用
提供需求的逻辑顺序
利于需求渐进明细
利于工作分解
图例
监督
定义
确保产品信息从产品信息通过审批开始到最终实施的整个期间都是准确的
内容
管理产品信息的变更
确定维护产品质量需要开展的工作
关系和依赖性
关系的3种类型
子集
一项需求可能是另一项需求的子集
实施依赖性
有些需求依赖于其他需求的实施,即其他需求实施后他们才能实施
收益或价值依赖性
有时除非先实施另一项需求,否则某项需求的收益无法获得
跟踪与监督的3种关系
正向
反向
交互
批准(审批)需求
工作授权系统
定义了授权工作的过程,包括过程步骤、所需文件、跟踪系统,以及批准(审批)级别。
批准(审批)级别
是工作授权系统的组成部分。批准(审批)级别提供了关于谁有权力批准(审批)新需求和变更需求的详细内容
【工具与技术】
力场分析
可用于帮助产品团队分析是否有足够的支持来追求变革的决策技术
群体决策技术
可用于群体活动,使参与者对正在讨论的问题作出最终决定;也可用于解决与需求相关的冲突
基准化已批准需求
需求基准的定义
所有获批需求组成的边界,涵盖了项目、项目阶段、迭代、增量、发布或项目任何部分的所有【已批准需求】
需求基准、产品范围、和项目范围的关系
项目范围是为交付产品、服务或成果而必须完成的工作
产品范围包含了产品、服务或成果所具有的特征和功能
需求描述了最终产品、服务或项目成果的特征和功能
维护产品未完项
产品负责人对产品需求(也称为功能)负责,以及基于哪些需求或用户故事能提供最高的商业价值来进行优先级排序
使用跟踪矩阵来监督需求
使用跟踪来监督需求的收益
随着需求渐进明细以及更多细节的出现,需求间的关系也日渐清晰
完整的一组基准化需求具有打造某项功能或一组功能所需的细节。
如果需要,支持为每项基准化需求创建商业分析工作成果。
各阶段产生的工作成果是为每项获批需求创建的,如设计文档和测试文档。
防止范围蔓延
需求生命周期
管理需求变更
变更管理与商业分析的关系
商业分析师在变更管理中负责维护需求及关联的可交付成果和工作成果的完整性,以确保每项新需求与商业需求、商业目标及项目目标保持一致。
项目经理关注与项目范围、时间、成本和资源相关的变更,而商业分析师关注与需求、可交付成果和工作成果相关的变更
商业分析师在监管变更请求中的任务
监督变更请求
根据变更的工作量、成本影响、风险影响以及对已完成工作或现已审批需求的影响来收集信息
评估提交的变更申请的影响
商业分析师在管理变更中的任务
保持需求和相关交付成果、工作成果的完整性
确保每个新需求都符合商业需求、企业和项目目标
变更方案推荐
批准变更
更新商业分析可交付成果
推迟变更
记录决策及原因;反映在相关的计划当中
否决变更
记录决策和原因
要求更多信息
新一轮启发和分析,更新到影响分析并再次提交
控制缺陷相关的变更
建议的变更并不是都是针对新功能或新需求的请求,有些变更请求是为了修改解决方案中识别出来的缺陷
这种缺陷可能是在正式或者非正式审查后提出的,或者相关方与解决方案交互时可能会复现一些缺陷
引出解决方案评价
【工具与技术】
影响分析
定义
评估提议的更改,包括确定与更改相关的风险、纳入更改所需的工作,以及相应的时间和成本
分析的内容
对需求基准的影响
提出的需求是否与其他需求发生冲突的影响
对商业分析的影响
对项目管理的影响
IT系统
配置管理系统(CMS)
需求及需求相关文件(如模型、跟踪矩阵及问题列表)保存在项目干系人容易查看到的地方,并确保不会丢失;
需要时能查看以前的文件版本
版本控制系统(VCS)
版本控制系统(VCS)是配置管理系统(CMS)的一部分,是配置管理的过程之一。
5.评价
规划评价
评价的目的
提供了评估一个解决方案是否已达到预期的商业结果的能力,可以识别收益递减点
让解决方案与相关方的意图相匹配
评价的建议思维
尽早并经常评价
将需求分析、跟踪、测试和评价作为互补性活动来对待
牢记借助用途和价值的语境来评价
确认软件解决方案的预期价值
评价方式的类型
解决方案绩效评价
描述了运营解决方案如何在执行中贴近商业目的和目标
解决方案确认评价
评估了解决方案在可接受的质量水平上能够达到的商业需要的能力
组织准备度评估
干系人是否能接受解决方案相关的变化以及相关方能够有效利用解决方案能力的准备度
建议解决方案评价
评估了建议解决方案交付的价值,并推荐最佳解决方案
输入
解决方案选项
需求
假设和约束
规划评价活动
考虑因素
项目以及企业目标、目的或待监督/跟踪/确认的风险
谁会承担进行评价所需花费的时间和工作量成本?
对评价标准的内置测量能力?
是否存在已有手段来抽取测量数据用于评价?
选择的评价方法是否有效且相对经济?
报告和发布评价结果的方法
确定评价什么
考虑商业目的和目标
考虑关键绩效指标(KPI)
考虑附加的评价指标和评价验收标准
项目指标
项目成本、努力和时间
客户指标
满意度
销售和市场营销指标
市场占有率
运营指标和评估
功能指标
确认组织可以继续评价
必要时,重新确认发起评价并承担成本费用的组织或部门仍然能够或愿意这么做。
何时以及如何验证解决方案的结果
何时验证
预测型生命周期
在发布前或发布后的一个确定时间点
迭代/适应型生命周期
在每次迭代、冲刺或发布前
如何验证
【评价技术】
调查和焦点小组
调查
调查可用于从规模巨大且/或地理上分散的人群中收集信息和启发需求
焦点小组
焦点小组给个人提供了机会,就一组设定的主题其中之一来提供想法和主意,同时讨论和评论其他参与者的意见
探索性测试和用户验收测试
探索性测试
由具有精深业务或测试知识的人员进行的无脚本、形式自由的确认或评价活动
用户验收测试
确认解决方案符合规定的验收标准的正式测试活动,由具有精深业务知识的人员进行。
生活时光测试(用户的一天)
生活时光测试由一组用例场景、多个用户故事或功能需求组成(半正式)
集成测试
用于确认或评价解决方案在组织中其他正在进行的业务和系统运营更大规模的环境中是否能够符合预期
系统测试是证明开发中的解决方案何时能与其他系统和组织进行交互的一种核实形式
对比功能的预期结果和实际结果
对比非功能需求的预期结果和实际结果
成功测量和收益的财务核算
执行评价
评价验收标准和解决缺陷
活动
预期结果与实际结果的比较
检查公差范围和确切数字
最差值
目标值
最佳值
记录和解决缺陷
意义
决定如何处理验收标准与解决方案对比结果的过程; 通过比较验收标准和验收测试的实际结果,提出应如何处理解决方案不符合验收标准的建议
【工具与技术】
优先级方案
根本原因分析
跟踪矩阵
偏差分析
一种确定原因和差异程度的技术
解决方案发布
发布前
促进通过/不通过的决策
通过
完整发布
部分发布
不通过
推迟发布
反对发布
获得解决方案的签字确认
需要“正式签字”的特征
项目具有商业范围或企业范围内的影响。
产品的错误或公差范围内的失败可能导致死亡或不可接受级别的生命、财产或财务偿付能力的风险。
组织中严格遵循预测型生命周期的项目。
监管严格的行业,如银行、保险,或医疗设备、临床研究,或制药公司
获得解决方案验证
是否将部分或完整的解决方案发布到生产中并最终交接给运营团队做出决策,以及转移关于产品、风险、已知问题和这些问题可能出现的权变措施等信息
解决方案替换/淘汰
4种策略
一次性大规模割接
分阶段割接,例如按地区、角色
替换方案与正被淘汰的方案以时间盒的方式共存,在未来特定日期进行最终割接
旧方案和替换方案永久共存,旧的业务继续用旧方案,新业务用新方案
过渡缓冲活动
与受新解决方案直接或间接影响的干系人进行充分的沟通。
完成所需的培训材料并提供培训。
完成或更新标准操作流程(SOP)和工作指导书。
购买、许可和安装任何必要的硬件和支持解决方案所需的第三方软件
与组织的其他活动进行协调,确保每次企业接受变更并且部署时不与其他过程中的项目集和项目工作发生冲突时即可实施。
协调以确保任何业务中断都被明确识别、沟通,并为客户所接受。
发布后
评价解决方案的长期绩效
步骤
确定指标
获得指标/测量绩效
分析结果
明白各种指标对应的影响表现,进一步研究和根本原因分析可以识别影响绩效的负面问题。
评估解决方案和组织的局限性
建议提高解决方案绩效的方案
与评价的其他方面相同,用于提出初始解决方案的分析技术,同样也适用于建议提高解决方案绩效的方法
评价解决方案绩效
评价内容
解决方案的实际商业价值
获得结果背后的根本原因
【工具与技术】
产品组合矩阵(BCG金牛瘦狗)
概论
商业分析的定义
确定问题和机会
识别商业需要并提出可行的解决方案,以满足这些需要并支持战略决策
启发、分析、明确、沟通和管理需求和其它产品信息
定义测量和实现价值效益的方法,并对结果进行分析
商业分析的价值
满足商业需要
管理风险并减少返工
减少产品缺陷、召回、诉讼和消费者信心下降
实现干系人满意度
谁来做商业分析
敏捷团队成员
商业结构师
商业情报分析师
商业流程分析师
商业专家
项目经理
数据、功能、运营、系统或用户体验分析师
产品经理或产品拥有者
需求,软件需求,系统或价值工程师
需求经理
需求的分类
商业需求
整个组织的高层级需要
干系人需求
干系人或干系人群体的需要
解决方案需求
分类
功能需求
描述产品能开展的行为
非功能需求
描述确保产品有效的环境条件或必需品质
过渡需求
从“当前状态”过渡到“将来状态”所需的临时能力
公式
EAC(Estimate at Completion 完工估算)
AC+ETC
BAC/CPI
BAC-CV
ETC(Estimate to Completion 完工尚需估算)
(BAC-EV)/CPI
EAC-AC
BAC(Budget at Completion 完工预算)
AC(Actual Cost 实际成本)
EV(Earned Value 挣值)
CV(Cost Variance 成本偏差)
EV-AC
CPI(Cost Performance Index 成本绩效指数)
EV/AC
PMP图例
控制图
控制质量过程
直方图
控制质量过程
帕累托图
控制质量过程
【紧急、快速、关键问题】
散点图
管理质量、控制质量
气泡图
实施定性风险分析
蒙特卡洛图
实施定量风险分析
亲和图
收集需求、管理质量
影响图
实施定量风险分析
敏感性分析图(龙卷风图)
实施定量风险分析