PBA！be stronger！
2018-11-26 08:59:21 0 举报AI智能生成
登录查看完整内容
(PMI-PBA) Business Analysis for Practitioners 全书解析
作者其他创作
大纲/内容
PBA
第一章 引言
定义
商业分析
识别商业需求、推荐相关解决方案、并启发记录管理需求 的一系列活动集合
需求
根据 合同或其他正式的强制性规范 产品/服务/成果 必须达到的条件或具备的能力
分类
pmp
项目需求、产品需求、质量需求、干系人需求
质量需求
必需达到的条件或具备的能力，借此验证成果属性的可接受性和评估成果的质量一致性
bap
产品需求
商业需求
抓住机遇 解决问题
干系人需求
客户、供应商、合作伙伴、内部商业角色
解决方案需求
功能需求
描述产品能开展的行为
非功能需求
产品有效的环境条件或必需品质
”服务质量需求“
= 产品质量状态需求
过度需求
“当前”到“将来”所需要的临时能力，如，数据转换/培训
需求评估
识别问题或机会，评估组织当前的内部和外部环境，组织当前能力，从而确定 可行的 解决方案选项
提供 思考、学习、发现、表述 商业问题和机会 的方法
提出
商业干系人依据内部方法论的要求正式提出
ba在 项目集或项目 开始前 建议
意义
需求评估和商业论证 是 确定项目目标的基础
为 项目章程 提供依据
如何做
识别问题或机会
识别干系人
工具
raci矩阵
responsible
accountable
consult
inform
调查问题或机会
情境（situation）
正在调查的问题或机会 的背景（context）
访谈
审查现有文件
过程建模
这特么是啥？？
观察
监察或观察正在运作的业务，发现“当前”过程的元素
收集数据评估情境
情境规模评估
测量 问题/机会的大小，确定得出的解决方案是否恰当
标杆对照benchmarking
帕累托分析法
20 80 谁在影响大局
趋势分析法
有关指标的各期对基期的变化趋势的分析
起草情境说明书 situation statement
格式
问题是啥、效果是啥、影响是啥
包含在 正式的 商业论证case 中
获取干系人对情境说明书的批准
ss 为 评估商业需要 提供指导
ba发起并促成批准
正式或非正式
技能方式：促进、谈判、决策
可能不会在初审获得批准，或需要修订或重申 已获得干系人同意
评估组织的当前状态
概述
评估 不是 完整的当前状态分析
意图
理解 组织当前 目的与目标 goals&objectives，阻碍达成目标的原因和目的，能够抓住机会的充要贡献原因
评估组织目标和目的
输入：组织的目标&目的
提供背景&方向
目的：宽泛、时间长
目标：具体，期限短
目的包含一个以上目标；目标在于成就目的
smart
明确性specific
可预测性measurable
可达成性achievable
相关性relevant
时限性time-bound
商业需求 是 目的/目标/组织的高层级需要，提供了 项目得以执行的依据
除了未预见，所有项目（集） 直接支持 商业目的和目标
swot分析
优势streng
劣势weakness
机会opportune
威胁threat
使用
内部
外部
将 情境 分解 为
根本原因 root causes
发现问题 的 深层原因
贡献因素 contributor
成功推出新品或服务的 可行性
潜在市场研究
作为标准
目的&目标 可以作为 决策进行哪一个项目（集）的 衡量标准
情境的根本原因分析方法
五问法
对问题5次提问或逐步深入5个层次，细化根本原因 VS 被访谈者的防备
因果图
跟踪造成 非预期成果的根本原因
鱼骨图（石川图）
关联图
识别产业问题的 首要原因
子主题
过程流
记录/分析 当前和未来的过程
分析由当前过程引起的特定问题的发生路径
确定解决情境的必要能力
能力表
问题、根本原因、新增能力
亲和图
构造主要原因的类别；关联问题和机会
标杆对照
外部组织，也强调 哪些建议不应采用
评估当前能力
方法
企业和商业架构
能力框架
识别能力差距
问题、根本原因、新增能力、填补差距的项目可交付物
建议满足商业需求的活动
纳入增加能力的高层级方法
增加能力的建议路径
征求 商业和技术架构师的初步意见
提供可选方案
原因
表明选择项已被考虑，并预先阻止这些方案支持者的反对
偏好的方案可能因为某些原因不被接受（成本/进度/成员），因此需要潜在可接受选项
ba不能决定最好方案，但需要提供建议及支持建议的事实和证据
解决方案决策 由 商业发起人或问题所有者 确定
识别每个选项的制约因素、假设、风险
Constraints
评估潜在解决方案的已知制约因素，需要尽早
Assumptions
被认为会是正确的、真实的活肯定的，无需实际证据或证明的因素
如有假设被证实不正确，则需重新评估需求，甚至整个商业论证
Risks
风险及减轻的策略/成本都应记录
任何需要作出反应的风险，都有可能增加潜在解决方案的成本
评估每个选项的可行性及对组织的影响
何为评估
包括比较潜在解决方案在关键变量或可行性因素上的可行度
为何评估
为最可行的选项保留成本效益分析工作
为最可行的选项执行完成的商业论坛，以节省时间
可行性种类Feasibility
运营可行性
技术/系统可行性
成本效益可行性
不必是完整的成本收益分析，而是对成本和收益价值的初步、高层级的可行性估算
完整的成本效益分析就在商业论证准备期间针对最可行的选项实行
时间可行性
评估因素
我也不知道为啥在这里
推荐 最可行选项
ba 推！荐！
如何排序确认优先
加权排序
评分*权重值 》分值&整体排名
投票
少数服从多数
询问干系人对投票结果的主观反映
若 团队不信任结果，则意味着标准/权重或投票方法需要改进
为建议选项执行成本效益分析
成本效益分析
投资回收期Payback Period (PBP)
月/年计算
越长，风险越大
一些组织设定 阈值a threshold level\u00A0
投资回报率Return on Investment (ROI)
净收益的雨季平均值/初始项目成本
缺陷：未考虑持续成本
通常有“门槛比率”，被选项目的理想roi需要超过以往
内部收益率Internal Rate of Return (IRR)
预期年收益，预计增长率百分比
包含 初始+持续 成本
通常设定 “门槛比率”，考量项目投资，需超过特定值
净现值Net Present Value (NPV)
投资收益的未来价值
现在、未来的收益、通过膨胀都考虑在内
vs收益，还考虑通过金融工具获得收益
>0，值得投资
政府项目，<0，也可能被批准
组合商业论证assemble
assemble 组合
商业论证需要什么内容，组织通常有自己的标准，并采用模版/软件使过程简化/标准化
基本（思维过程）需要包括
问题/机会Problem/Opportunity
情境分析Analysis of the Situation
建议Recommendation
估算Evaluation
商业论证的价值
动态文件，随着项目（集）的进展，需回顾、更新
ba规划
ba规划完成活动
与发起人、项目团队、关键干系人，一起设定要实施的ba活动期望
确保角色识别、理解，以及参与过程的所有人充分沟通
工作开展前，对ba过程的认同和支持
提供支持ba分析活动预估的环境context
创造运作更有效的ba过程
好处
减少与需求相关的大量风险
确保过程对项目（集）来说，不会太繁重或过于正式
不同生命周期类型
预测性：规划在启发之前进行
适应性：部分与预先执行，过程中不断适应、演进
故而，需要适当详细度忙族不同项目需求，如项目的规模、复杂度、风险级别等
ba规划 VS pm规划
干系人分析
技术（识别干系人）
询问其他干系人得到输入
现有文件帮助识别：组织结构图、流程图
通用技术
头脑风暴Brainstorming
数据搜集，自由、快速；所有想法被接受；想法的产生和分析；
组织结构图Organizational Charts
结构图定稿工作 通过乙烯利与建模部门的经理间讨论得出
定义干系人特征
最具意义 且 与项目最相关部分
通常包括
态度
支持
振奋团队
对解决方案提供支持
不支持
尚未表达的商业需要、需求、培训问题、资源制约因素、需要项目团队理解的重要历史经验和现有经验
或因没看到方案价值，需要理解这些干系人关注点及寻求争取他们参与项目方法
复杂度
包括，群体是否
干系人数量
大量受影响项目
商业过程中缺少一致行
与一系列商业单元的互动
通过it系统，或（和）组织外系统展开工作
有助于
量化、规划需要进行的需求访谈数量
交付成果的正式程度
评估 各解决方案及项目变更 对 干系人影响
*项目复杂的主要原因是 多个干系人以及项目功能模糊不清，ba能更有效的规划进行ba工作的最佳方法，包括选择启发和分析产品需求的最佳技术
文化
多样性
年龄、国际、群体、部门或组织文化
影响
进行工作
互动
决策过程
非语言沟通
理解团队主要的书面/口头语言
质疑权威or与权威互动
回顾团队角色
提出疑问/问题
协商
处理冲突
经验
识别项目干系人的经验，以确保具备充分广度的商业知识
干系人经验，将，影响如何确认和批准需求
识别差距后，需寻求更多资源为相关活动提供必需或者欠缺的经验
影响力水平
有助于 哪里可以称为激励因素
突出 帮助整合解决方案、阻碍项目的人，帮助ba识别，以建立与干系人在协作领域的联系
包括
组织中的职位
级别
回报关系
头衔
商业关系
信誉
知识水平
在组织中的成就
地点可用性
集中办公也需要理解是否支持远程协同工作
确定最佳协作方法
电话会议
桌面共享
网络会议
理解可用性
可用性
工作时间
弹性工作制度
如，关键干系人
本地：引导式研讨会，启发需求
分散/时差：访谈，调查
没时间：文件分析
技术（分析/分析干系人）
分组依据
共同利益
共同需求
重要程度
角色
动机
复杂程度
地点
分组原则
最接近分析目标的干系人
分组技术
工作分析
用于 创建新工作或修改现有工作
输出包括
类似的工作描述
工作环境叙述
执行活动的详细清单
所需要的人际关系技能清单
所需要的培训、学历、证书等清单
* 也可以用于定义培训，编写工作职位所需的格式信息，支持绩效评估过程
人物分析
分析 一类用户或执行过程者
理解感谢人需求、瞄准产品设计、每一类用户行为
虚构的特征，描绘一个用户组或有相似需求的干系人群体
理解不同干系人的群体特征
应用角色信息，选择最佳的ba方法来识别项目需求
人物
通常用于it系统开发和产品开发
帮助 设计或计划用户体验
干系人分组，定义用户类型，为每一类用户建立相应角色
目标：分析用户使用的信息或者拟定用户需求，来定义用户类别如何与系统交互，或用户将如何使用产品
人物VS干系人
人物包含
如何与问题/解决方案空间相互影响的细节
可能与项目成果汉武关系，如，一个普通用户
描述了用户类别的：目标、行为、动机、环境、人口特征、技能
行为性信息
干系人
识别类型或单个干系人
描述性信息
组织模型
过程模型
风险分析
干系人图
整合干系人分析结果
与pm、项目团队和发起人进行分享，来记录分析结果
信息敏感，发布时应当谨慎
更好的了解干系人，是制定的工作方法是最佳的，搞笑的完成ba过程
提供的干系人特征为 如何与干系人合作 提供了深刻见解
创建ba计划
用于记录如何执行商业分析的过程，以及项目统一的计划决策
文件可以是非正式（简单记录团队决策）的，但需要项目团队审查和批准
利用既有计划模版
现有的企业标准
文化被接受的实践
预料中的治理/管理步骤
并非所有信息都是已知的，做的假设内容需要在计划文件中列出
在规划阶段的前期做决策，降低在执行阶段因争论过程而被搁置的风险
某些情境，执行阶段的决策优于规划阶段的决策，因为信息的完整程度，不成熟的决策
滚动式规划：先做高层级规划，其后，渐进明细
ba需要平衡前期规划带来的优势和劣势
商业分析计划VS需求管理计划
有关 商业分析规划决策 的所有信息
描述 项目的整体需求如何发起、分析、记录以及在项目中如何管理
基线、更新、变更影响
ba计划的内容
编写原则：简单易懂 （因为审查需要关键干系人审批）
决策内容包括
产生的商业分析可交付成果
参与需求活动的角色和职责
需求的优先级分析、审批和维护
跟踪和管理项目需求的状态列表
如何确认和合适需求
如何确定/确认需求和解决方案所需要的验收标准
计划内容的详细程度
避免：太过拘泥于规划
滚动式规划：考虑规划范围，并支队近期活动进行做详细计划
平衡灵活性和管理
不为灵活性牺牲牺牲好的管理实践
记录关键决策，不应是图计划每个过程的每一步
了解项目环境context
了解项目特征和实施环境
内容
项目规模、复杂程度、类型、风险级别、风险承受力、干系人地域分布、时间紧迫性、选定的项目生命周期、强制的制约因素/法规、市场环境/竞争格局、技术趋势、可交付成果的详细程度和形式、市场需求时间、分配给项目的ba经验级别
了解项目生命周期如何影响决策制定
分类类型
预测型（完全计划驱动）
最大程度减少不确定性
范围完全预先确定
谨慎管理变更
又称 计划驱动、传统型、瀑布型
迭代/增量型
项目分为若干阶段，并有意义重复
前期定义高层级范围，想起范围在迭代中产生
前一阶段开始或完成时，定义下一阶段范围
产品迭代，功能叠加
ba分析大部分前期完成，小部分过程中
随着项目发展，需求和解决方案更加稳定
适应型（变更驱动）
通过减少不确定性增加商业价值
每次迭代更新时间和成本估算
快读迭代
早起商定总体范围，每次迭代定义详细范围和产品需求
变更，提出新需求，列入未完成项，并重新定义优先级
频繁的ba
需求和解决方案是未知和不稳定的
又称 变更驱动、敏捷方法agile methods
确保团队受过选定生命周期培训
借鉴历史经验
经验教训（大）
主要阶段结束or项目完成后
若需求产生重大变更，则频繁进行
ba寻求其他正在进行或已完成项目中，寻求类似的商业分析方法、审查相关的经验教训文件
提取预算指标，并寻找改进分析过程的方法
回顾（小）
适应型中定期举行
步骤
前期准备
收集数据
深刻理解
决定所什么
问题列表
？正常
？不正常
？需要变更
启发规划
需要考虑的因素
项目生命周期、技术特征、项目类型、时间制约、预算、干系人数量/地点、成果详细程度、参与的ba及技术
引导式研讨会、走进的访谈、发出的调查 都有 成本
因此，ba需要平衡 项目需求与需求启发 的数量，充分定义产品解决方案
启发规划，有助于确保分配充足时间开展启发工作，但容易误判工作量；
如，调查是启发的一部分，后续还有设计、构建、管理和分析调查结果
当后续工作依赖于调擦好结果是，ba需要确定并规划相应的工作
若时间估算不足，则下游任务获奖延迟
故而，需要采取合理方法提前规划
提前发现依赖关系，并据依赖关系安排下游任务downstream activities
排序策略（启发活动的最佳序列）
哪些需求需要被首先启发
大量重要的商业价值
更大的风险
未知&不确定性
重要的技术挑战
对其他组件/借口的依赖性
所依赖的第三方资源
有限/关键资源离开项目/公司的风险
干系人给定的项目期限
分析规划
在实际工作之前确定需要的工具、模版、培训
规划是迭代的，并贯穿于整个项目
定义需求优先级
管理产品范围，减少活动之间冲突，使用谈判和冲突管理技能
常见考虑因素
优先级何时发生
优先事项变更的可能性
参与的关系人
确定优先级的技术
用于优先级排序的标准
批准优先级决策的干系人
生命周期类型影响优先级排序的使用
适应型：每次迭代时
预测型：产品构造之前
瀑布型：产品构造前或过程中
优先级因素
价值value
成本cost
难度difficulty
监督regulatory
风险risk
优先级排序技术
MoSCoW
第四章
多票制\u00A0multivoting
时间盒timeboxing
加权排序weighted ranking
第二章
定义跟踪方法
跟踪Traceability
记录需求关系，用于ba维护产品范围
方向
向后跟踪识别需求来源
向前跟踪识别测试和实施需求
深入理解一组相关需求所能交付的价值
若：记录但跟踪不到，则超出范围，则识别了不符合需求的产品部分
充分的跟踪数量可以确保正确评估需求变更的影响，并从风险、成本、时间的角度进行量化
跟踪决策的类型
跟踪的需求类型
跟踪的详细程度
将建立和维护的关系
跟踪的需求属性
推动需求生命周期的状态（批准、拒绝、延迟等）
执行跟踪的工具
如何建立和维护跟踪的过程决策
项目规模、复杂性的增加，跟踪的的复杂性随之增加
更大、更复杂的项目增加了 组建之间需确立的关系数量，时间和成本随之增加
第五章
定义沟通方法
描述了如何构建商业分析信息，及何时与干系人沟通
正式记录
需考虑信息
沟通的需求及需求信息的类型
需要沟通的人及其期望信息
干系人的信息接受偏好（如，概括或详细程度）
分发或访问的需求及，首选传递方法
所需的正式程度
工具，包括干系人要访问的需求资料库
方式：难以直接沟通，则可能需要正式化，确保信息以清晰、明了、易于理解的方式传递给参与者
定义决策过程
干系人要做的决策类型，及在过程中评估授权级别
考虑信息
决策类型，如何审批
角色和授权级别
无法达成共识或需求升级时，应遵循的过程
达成决策需要的周转时间
记录决策和如何沟通，包括需求的牵手
评估备选方案的工具或技术
决策分析
决策模型
决策树
定义需求核实和确认过程
核实是：评价产品、服务或系统是否符合发亏、要求、规范或强制条件
确认是：确保产品、服务或系统满足客户或其他干特定干系人的需要
需求确认是确保所有需求正确的反应干系人的意图，并且每个需求对应一个或多个商业需求的过程
在规划时定义质量标准，核实过哼需要借助检查清单来定义质量属性
定义需求变更过程
不同生命周期
预测型：正式变更控制
适应型：灵活的需求变更方式
可能涉及
范围变更
重申商业目标
调价或删除赈灾开发的产品/服务的功能
如何提出
如何审查
如何记录变更决策
如何沟通变更需求
批准后，如何更新需求、模型、跟踪和其他相关需求的信息
确保项目团队理解变更流程中的角色与指责
谁负责提出变更
谁负责进行评估或影响分析
参与变更讨论的角色
谁负责审批变更
直接使用：变更请求表格、影响分析模版
定义解决方案评价过程
通过评价，ba确定解决方案是否已经达到所期望的商业结果
在实施解决方案之前或之后进行
生命周期 影响 评价活动的时间和频率
涉及定义内容
评价标准和接受级别
何时及每次间隔多久进行评价
使用的评价技术
如，焦点小组、观察法、调查等
是否需要特殊的测量工具
将如何分析及报告结果
第六章
规划ba工作
谁完成规划ba工作
项目经理和商业分析时的角色存在重叠领域
建立ba工作计划
商业分析师负责使用所有已知的项目和环境信息来鉴定这一工作，如，选定的项目周期、项目规模、已知风险和组织过程资产等
建立计划的第一步是 识别商业分析时负责产出的可交付成果
识别可交付成果
唯一的、可被核实的产品
确定结构or模版
不甚明了
确定任务和活动
迭代过程
使用多项技术
头脑风暴、访谈、经验教训
分解模型
概括性目标分解为较小的独立部分
解决方案范围、组织单元、工作成果、过程、功能等
层次关系通过 级别 描述
但，不能显示序列和过程步骤
也称：分解图decomposition diagrams
确定任务的时间和顺序
考虑因素
资源可用性
后继接受着的需要
与组织内其他工作的关系
合同和工作说明书的义务
培训和工具的依赖关系
（新）员工的需要
任务的风险和复杂程度
确定角色和职责
定义项目经理和商业分析师的角色责任
最大限度的减少混淆和冲突，尤其在责任重叠区域
识别资源
识别资源 过度分配和遗漏 领域
最低要求：获取、确认、批准过程中分配有资源代表
主题专家，商业分析师应该提出所有有可能的问题，以获得资源的承诺
预估工作
可靠性：同事、干系人、类似项目
需考虑因素
p100
整合ba工作计划
详细程度需依据
ba工作的复杂性
项目规模
跟踪的商业分析工作的数量
项目生命周期类型
记录ba分析方法的原理
与干系人共享 原理
对项目团队而言，回答为何工作需要进行，及目前具体的方式
对项目经理而言，提供了需要支持、资助、管理的情景，并验证了为完成工作所需要的角色和资源
记录 原理
为未来项目团队提供有价值的信息
商业分析实践中心：收集和存储这些资产
or，非正式过程：共享知识库
与干系人审查ba计划
审查应单独进行
干系人的问题应直接反馈
目的
减少干系人不支持的风险
减少冲突
增加归属感
及时发现未知的风险，如，资源短缺、进度冲突、所分配的角色顾虑等
应邀干系人
负责审批、排序，或确认需求的
变更控制过程中的角色
有管理职责的人
主题专家
发起人、项目经理、需求后继接受者
获得ba计划的批准
请求增加了项目的风险，或降低了商业分析过程的质量和有效性
商业分析师给出方案，有利于避免干系人气馁或放弃
有助于降低这些风险
干系人不予支持
项目团队低估了活动所需时间
分配给需求阶段的资金不足
关键干系人低估所需参与的资源和级别
关键资源不能为需求活动所用
干系人需求记录和沟通的期望被忽视
正式/非正式
获得发起人或关键干系人的批准
计划的更新应以受控的方式进行
需求启发和分析
需求启发
迭代
计划、准备、实施来自干系人的启发信息
分析和记录着香工作的结果
最终定义组足够想尽的需求，一边定义和选择最好的解决方案
不仅是指“收集”or“汇总”
重要性，ba工作的核心输入
支持行政决策
成功运用影响力
协助谈判或调解
解决冲突
定义问题
启发计划
启发的优点
p110
制定启发计划
启发计划的元素
要启发什么信息
在哪里可以获取这些信息
个人、模型、文档资料
至少两个信息来源
如何获取信息
技术
排序启发活动
依赖关系
启发准备
确定目标
开展启发活动的目标
确定参与者
高管时间更少
确定讨论问题
准备多量问题
问题具有目的性
开展启发活动
引言
与参与者一起，讨论建立框架、设立基调和融洽的氛围
工具“停车场”
减少目标转移、偏离主题、打乱节凑
主体
软技能
积极倾听、移情、肢体语言、选择要提问的问题、问题的排序、影响力技巧等
高校表现/积极参与，提供大量信息
问题类型
开放式问题
封闭式问题
语境问题
语境无关问题
提出恰当的问题
倾听
需要重复或者复述所听到的内容，以确保正确理解沟通的内容
暂不做判断，识别差异，不增加引发冲突的可能性
获得细节
“不要以为自己知道，不要以为别人知道”
结尾
讨论结束前可提问
你们是否有其他问题
我们提问是否有遗漏
谁还可能掌握有助于启发目标的信息
出现的问题成为帮助构建后续跟进阶段讨论目标的材料
后续跟进
确认整合信息的准确性和完整性
启发信息综述小结的作用
p118
替代方法
将笔记写在白板上，当场纠正信息
启发技术
头脑风暴
文件分析
优点
客观
无人所知
更准确
多了背景和解释
了解结构&功能
缺点
无法获得
文件实效性
引导式研讨会
也称 需求研讨会
建立信任、促进关系、加强沟通、达成共识
团建
达成共识
直接接触，积极性
认知基础
需求更易实现
准备
议题
议程
决策流程
足够的材料
按照角邀请参与
避免不需出席，或遗漏
tips
减少交叉讨论
按时开始
指派角色（引导者、记录员、引导负责人）
结束的提示
跟进的提示
尽快将总结反馈给参与者
焦点小组
8～12人
讨论既定的目标大纲或清单
群体压力
类型
结构化访谈
非结构化访谈
同步访谈
异步访谈
专注
肢体语言
更合适的访谈环境
虚拟访谈的缺点
不专注
干扰
缺少虚拟访谈经验
设备故障
也称 工作见习
获取大量、无偏见、客观、真实的信息
p128
被动观察
不打断、不提问、不寻求说明
将干扰降到最低
缺点：被观察人不信任观察员，并以非常规方式工作
主动观察
观察者中断过程或活动、询问
信息的即时性，信息量的增加
缺点：中断工作流，降低生产效率
参与式观察
参与执行活动
允许提问且不引起误会
发现引导式研讨会中不会讨论的功能、特征、改进
仿真
再现过程
启发更多细节
人们在被观察时，会以不同的方式进行行动
管理者不支持中断，或不允许第一手的观察
原型法
渐进明细
低保真原型
高保真原型
抛弃式远行
演进式原型
敏捷方法
案例
故事版
先是序列或导航
侧重产品感受、体验、观感
线框图
静态蓝图/用户界面示意图表
说明具体逻辑和业务流程
问卷和调查
快速、大量
没有澄清机会
封闭问题
数量不足以具有代表性
限制调查风险的方法
规定对象数目
返回曲解信息
申明调查重要性
发送提醒，鼓励促进
高层倡导
启发输出
形式
草图、图标、模型、挂图、便签、索引卡
完成启发
如何确定是否完成
p135
启发的问题和挑战
困难
建议
如，不能访问到合适的干系人，则，关注信息而非个人
如，干系人不知道自己所想，则，原型/故事版，可视化，适应型生命周期
如，干系人难以定义需求，则，帮助澄清问题，防止直接跨越到解决方案
如，干系人无法提供足够细节，则，可视化模型启发需求，分层级，可视化细节
需求分析
分析计划
检查、分解、合成信息，以进一步了解、完善和改进信息的过程
渐进迭代
一方面细化到较低层级，一方面抽象到较高层级
用来提供需求和相关信息的结构
预先思考
那些活动和技术可能有用以及应该何时使用
使用多样化的技术
尽可能掌握多项技术
选定模版可以当作项目起点，也为ba分析的过程发生意外做好准备
分析什么
选择正确的信息分析
分离妨碍正确分析的信息
利用可视化模型帮助建立ba边界
促进感谢人和主题专家进行讨论
针对需求启发活动的输出进行分析
启发和分析都是迭代的
建模与细化需求
模型
描述
模型即可视化的表达形式，以简洁的方式有效的整理和传递大量信息
如，结构化的表达方式包括
图
表
结构化文本
建模工具
建模工具formal modeling tools
白板whiteboards
艺术软件artistic software
有助于发现差距和识别外部信息
更好的理解，更清楚的传递信息
获取更大的情绪堵和正确性
模型帮助可视化，并归纳了复杂的信息
范围模型scope m
结构化和组织特性、功能和分析商业边界
目的和商业目标模型
生态系统图
系统交互图
功能模型
组织结构图
用例图
鱼骨图
swot图
过程模型process m
描述干系人参与业务过程的方法
用例
用户故事
规则模型rule m
定义或约束各方加强建立商业政策和概念
商业规则目录
决策表
数据模型data m
用于记录过程或系统生命周期的数据
实体关系图
数据流图
数据字典
状态图
状态表
接口模型interface m
辅助理解特定系统即其在解决方案中的关系
报告表
系统接口表
用户界面流
显示-操作-响应
选择
多个正确模型中，根据 适用性 优先选择
需考虑
方法论
项目特征
项目生命周期的时点timing
早期、进行中、低层级
模型类别
抽象程度
示例
敏捷项目/报告分析项目/系统迁移项目
项目早期/后期
使用模型细化需求
确定重要的和有价值的，以便创建正确需求
启发会议：与干系人、专家一起细化需求
建模语言
商业过程建模符号
用于复杂商业过程
需求模型预言
用于需求可视化，便于干系人理解
系统建模语言
用于分析复杂系统
统一建模语言
用于特定设计
其他建模语言
每次使用统一的语法以避免混淆干系人
模型描述包括：语法、实例、常用方法，以及模型与需求如何相互关联
记录解决方案需求
重要性
核实干系人需求的基准
商业问题或机会解决的基准定义
相关工作人员的工作主要依据
用户手册及其他文档的基础
需求文件是项目说明说的核心输入
解决方案演进的出发点
过程中提供复用基础
监管行业和高风险项目的审计基准
需求文件的特点
记录需求是确保所有感谢人如何对实施方案达成共识的多项技术之一
文档无法取代沟通和协作
商业需求文件
分为
高层级需求
系统需求、技术需求之外的所有需求
解决方案文件
包含
产品或服务的特征、功能，及特性，用以忙族商业和干系人需求
是团队构建产品的蓝图
需求文件
书面的用户故事
产品未完成项的列表项
描述了项目正在构建什么，产出什么，或者商业问题的解决方案是什么
项目需求
描述了项目顺利完成的制约因素和必要条件
过滤器
范围过滤器
功能过滤器
优先级过滤器
可测性过滤器
需求规范
描述了可能发生的各种状况、条件、行动、反应、结果和错误条件
记录假设
完整的信息是不存在的
项目的成功取决于未来发生的事情
假设是基于目前存在的因素，但这些因素可能未来不存在
假设不一定一致成立，因此也产生了一定水平的风险
需制定应变计划
记录制约因素
产品或解决方案的制约因素
地理、法规、组织政策、文化
限制访问信息
禁止使用某种建材
安全限制
访问时间段限制
项目的制约因素
引导使用预定设备、组织标准、首选供应商
限制：资源、数据、软件
时间、成本、范围
VS需求
需求正面，如何做
需求编写指南
格式：条件、主语、祈使句、助主动词、对象、商业规则、结果
特点
明确性
精确性
一致性
正确性
完整性
可测量性
可行性
可跟踪性
可测试性
需求优先排序
moscow法
多票制
时间盒法
加权排序法
技术需求规范
有些p需要详细的技术文件
记录用例
可能表示一个或多个功能需求
是文本需求的补充，擅长描述复杂的系统和用户的之间的交互需求
记录用户故事
制作索引卡，将复杂功能分解为简单、可定义的要素
未完成事项
包括优先级产品需求和待完成的可交付成果
确认需求
持续确认
确认不等于批准
需求巡检
与干系人一起评审需求 ，并得到他们对于需求有效性的确认
核实需求
同行审查
确保可交付成果满足标准和通用需求的编写准则
技术：屏幕共享，直接修改文件
检验
更严格的同行审查
需求文件的接受者进行，不包括干系人、管理者或检验部门的直线领导者
批准会议
vs确认会议
会签：商业负责人、解决方案团队接受人、商业分析师
寻求批准的流程，高层为例行步骤，问题可能出现在低层级经理或工人
解决和需求有关的冲突
德尔斐技术
匿名投票，消除数据偏差
多选项、多轮，最后的最高选项即为决策
跟踪&监督
跟踪
从产品需求起源到可交付成果，整个过程中 对 产品需求进行跟踪的能力
向前&向后
商业需求、目的、目标
项目目标
项目范围/wbs可交付成果
产品设计租金啊
测试策略和测试场景
高层级需求到具体需求
具体需求到更高层级需求
不同类型的相关联需求
验收测试用例
需求相关的模型和图表
“适应型”项目
史诗故事、用户故事、功能及验收测试
看板面板
好处/收益
确保每项需求都能满足商业价值
满足客户期望
管理范围
决定最优跟踪数量的因素
生命周期模型
预测性/适应型
是否高度规范
组织政策和过程
跟踪的实际使用程度
跟踪矩阵
从需求源头到可交付成果
需求属性
需求及事实的简短描述
选择属性类型/数量
适合项目生命周期类型
正式跟踪
非正式跟踪
不漏项、不重叠
制定流程确保信息保持一致
典型类型
需求编号，唯一识别属性
需求的简短文字描述
目标
商业目的和目标
产品开发阶段
设计
构建
测试
实施
验证
wbs
状态
激活、批准、延期、取消、增加
列入理由
优先级
负责人
来源
版本
完成日期
干系人满意度
稳定性
复杂性
验收标准
矩阵层级
原则
高层级需求开始，渐进明细，填入细节
提供需求的逻辑顺序，不因信需求而被打乱
允许对需求增量式开发
无隐含顺序，易分解
高低层级需求目标一致性
关系和依赖性
对 需求集 据 依赖关系 进行分组
依赖关系分类
子集
实施中的依赖性
收益/价值依赖性
批准需求
正式签字批准/非正式口头批准
确定批准过程避免实施过程的冲突
工作授权系统
过程步骤、所需文件、跟踪系统、批准级别
超出项目团队掌控
批准级别
提供由谁批准新需求及需求变更
若不涉及，则由商业分析师、项目激励、发起人在 商业分析规划中 明确
批准VS签字确认
商业干系人批准，发起人唯一签字确认
每个组织不尽相同
审议者VS批准者
批准授权VS问责
需求否决
变更控制委员会及变更批准 ccb
专家判断和批准过程
安排足够时间
已批准需求基准化
需求基准
所有获批需求aching的边界，涵盖了项目、阶段、迭代、增量或者所有已批准的需求
基准：比较机制
变更正式程度，依据项目生命周期以及项组织变更管理过程 而不同
预测型：正式、复杂
适应型：非正式变更控制过程
vs
项目范围
为交付产品、服务、成果而必须完成的工作
产品范围
交付的产品、服务、成果所具有的特征和功能
米阿树了产品、服务、成果的特征和功能
未完成项
定义需求基准是通过维护未完成项完成
产品负责人对产品需求（功能）负责，并基于最高商业价值排序
表述形式：用户故事
新需求：每次迭代结尾的产品审查会议后浮现，但任何时候都可以提出需求
用户故事的优先级随时变化
跟踪变更，并据已定的沟通计划与干系人保持沟通
使用跟踪矩阵
随着细节被启发，将越加丰富
作用
监督需求的收益
确保
详细的需求被连接到基准需求
打造某项特性的具有的所有细节
如需要，为基准需求创建商业分析工作成果
各项工作成果为需求创建，如设计文件、测试文件
却把需求与已构建、一测试需求间的差距未被忽略
防止范围蔓延
适应型：重新排列优先级
需求生命周期
开放
已提出、已批准、过程中、已完成
关闭
已否决、已取消、已推迟、已实施
需求变更管理
关于任何文件、可交付成果或基准的正式提议
ba工作：
做出变更、成本影响、风险影响，以及对已完工作或已批准需求的影响
评估提交的变更，可能要求项目变更所需时间
变更管理中，ba 需要维护需求及关联可交付成果和工作成果的完整性
变更管理的应用级别取决于多重因素
应用领域
企业文化
组织过程资产
特定项目及最终结果的复杂性
合同需求
项目生命周期
项目进行的背景和环境
变更控制工具&技术
配置管理系统cms
文件记录、跟踪过程、审批变更所规定的级别
需求及相关文件易查看、不丢失
可以查看以往文件版本
版本控制系统vcs
跟踪修改历史，并不纵欲软件相关
简单
文件名反应日期、时间、版本号
正式
签出、强制变更注释、自动维护版本
影响分析
对需求基准的影响
是否于其他需求发生冲突
对商业分析的影响
对项目管理的影响
范围管理计划
商业分析计划
进度管理计划
成本管理计划
质量管理计划
人力资源管理计划
采购管理计划
风险管理计划
干系人计划
范围基准
进度基准
成本基准
行动方案推荐
一种以上的备选方案，包括：利弊、假设、风险等
结果
批准
推迟
否决
要求更多信息
控制缺陷相关的变更
解决方案评价
解决方案评价的目的
评价的建议思维
尽早&经常
将需求分析、跟踪、测试和评价作为部不行活动对待
结合用途和价值的语境来评价
确认软件解决方案的预期价值
解决方案评价计划
需要考虑
活动会监督、跟踪或确认项目或组织的那些目的、目标、风险
谁将承担评价花费的时间和工作量成本
解决方案或 基础架构是否具有对评价标准的内置测量能力
是否已有存在手段来抽取测量数据以用于评价
选择评价的方法是否有效且相对经济
现有方法是否已经可以用来汇报和公布评价结果
确定评价什么
商业目的&目标
kpi
附加的评价指标和评价验收标准
项目指标
客户指标
销售和市场营销指标
运营指标和评估
功能
确认组织能够继续负担继续评价的成本
何时几如何验证解决方案的结果
评价技术
调查和焦点小组
探索性测试和用户验收测试
无脚本、形式自由的确认或评价活动
生活时光测试结果
半正式，半脚本的探索性测试
集成测试结果
在组织中其他正在进行的业务和系统运营更大规模的环境中是否符合预期
对比功能的预期结果和实际结果
是否自动化
对比非功能需求的预期结果和实际结果
合理范围的非功能需求的验收标准，可以是服务级别协议的基础
成果测量和收益的财务核算
评价验收和解决缺陷
预期于实际结果比较
检查公差范围和确切数字
最可能的值应对目标值
记录&解决缺陷
通过额外的需求分析、影响分析和变更请求（如果适用）来解决
促进（不）通过的决策
评价结果以表格或直观的形式来表示，以便决策者抓住重点，做出决策
获得解决方案签字
评价解决方案的长期绩效
确定指标
获得指标/测量绩效
分析结果
评估解决方案和组织的局限性
建议提高解决方案绩效的方法
解决方案替换/淘汰
策略
淘汰以前所有方案的大规模一次性割接
分段式割接为替换方案
方案以时间盒的方式共存（所有新业务使用替换方案）
前1比后2，更容易引起风险
可以通过成本效益分析确定使用那种办法
存在两个解决方案在操作层面的影响
是否存在全部客户同时新方案进行交互
替代方案是否涉及团建
是否可接受部分用户使用旧方案
沟通注意事项
于受影响（直接/间接）干系人充分沟通
完成所需材料，并提供培训
完成更新标准操作流程sop和工作指导书
购买、许可和安装第三方软件
协调以确保中断业务可被识别、沟通、接受
0 条评论
回复 删除
下一页
