产品经理学商业分析-.跟踪与监督

当需求已交付项目团队设计和开发,BA应针对需求进行跟踪和监督,确保信息的传承无误,不出现任意程度上的产品or项目蔓

当决定项目是否立项的商业需要已经评估和获得批准,商业分析规划已完毕,面向相关方的需求启发既已完成,且经过需求分析产出项目团队认可的解决方案需求(功能需求+非功能需求),项目团队就可以开始将需求承接过来,进行设计、开发和测试

对商业分析师(Business Analyst,以下简称BA)来说,下一步要对整个开发过程中的需求的一致性,和一切可能发生的变更进行管理,这就是PBA方法论中,对应的需求跟踪与管理环节,也属于“P-D-C-A”戴明环中的D步骤

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

跟踪和监督的核心,就是对需求的两个管理:一致性管理+变更管理,一个确保需求在开发全程中不被各方理解错误而发生偏差,另一个针对随时提出的需求变更进行管理,避免项目和产品范围的随意蔓延

1. 跟踪监督是什么

定义:由确保需求在整个项目生命周期中获得批准,并得到有效管理的一组活动组成,跟踪监督过程中创建和应用跟踪矩阵及其相关属性,以便监控产品范围

跟踪从产品需求的起源,到满足需要的可交付成果的整个过程中,对产品需求进行追溯,可以前向识别到如何测试和实施,也可以后向识别出对应哪个具体的商业需要和应用情景;在需求的整个生命周期中,监督需求按照既定的规划往前推进,对随时可能发生的需求变更保持理性和规范的处理思路,避免项目和产品范围的不可控

而企业组织选定跟踪和监督的细化程度,取决于项目的复杂性,对风险的态度和可调用资源等因素的影响,比如载人航空这种超大精密型项目,项目失败将导致重大安全事故和经济损失,要尽量避免而非拥抱风险,而且可调用资源足够丰富,所以要规划足够详细的跟踪和监督计划,并予以实施

2. 为什么要做跟踪监督

BA对需求的跟踪和监督,可以获得相关方对需求的理解和批准,在项目工作中获得一致认可,确保其在整个项目生命周期中得到有效管理,根据PBA的理解,需求跟踪和监督可以为项目组织带来如下3点收益:

1.有助于确保实施中的每项需求,都能为组织增加商业价值

检查每项需求对标的商业需求、目的和目标,是否能匹配就位和足够详尽;由于需求在传递和加工过程中可能造成信息表意的偏移,在需求生命周期的全过程中,如果发现某些需求无法对应到商业需求和目的时,要分析其关联性,修正调整不相干的部分

ps,一个典型的需求理解偏差示意图

2.有助于满足客户期望

从启发得来的用户or客户需求,到分析过后的产品需求,再到建模后的解决方案需求(功能+非功能需求),在项目团队的开发实现中,合理的跟踪可以让需求始终围绕解决实际的用户场景而不会偏离方向,确保已批准的需求在项目结束时得以交付,且被相关方所认可

3.有助于管理产品和项目范围

需求生命周期全过程中都有可能发生增删改,合理的跟踪和监督可以让只有能增加价值的需求才会获得批准,而不随意给项目和产品镀金,损失不必要的项目资源

ps,产品范围和项目范围的区别

产品范围:产品、服务或成果所具备的能力、特征或品质,所组成的边界

项目范围:为产出产品、服务或成果所需要开展的、必要的项目工作边界

3. 什么时候做跟踪监督

如前文所述,需求的跟踪和监督一般发生在解决方案需求既已明确、项目团队承接过来进行设计、开发和测试时,BA开始应对需求的一致性和变更管理,进行跟踪和监督

4. 怎么做需求的跟踪与监督

PBA中介绍的跟踪与监督的子活动,在逻辑上不是很清晰,按照跟踪监督的实际操作安排,包含以下5个子活动:

4.1 读取跟踪计划

定义:根据商业分析规划中既定的需求跟踪计划,跟踪从产品需求起源到满足产品需求的可交付成果,整个过程中,产品需求的生命周期

通俗地说,包括以下2个步骤:

step1. 读取需求跟踪计划。在商业分析规划步骤中,对需求跟踪已有计划,包括:

1.执行跟踪的工具,比如用看板方便项目的状态、进展、问题等以直观形式展现,或者用线上协作平台方便项目团队成员对需求信息、状态变更都有清晰的认识

2.双向跟踪,对每一项解决方案需求(功能+非功能需求),能前向识别到如何测试和实施,后向识别出对应哪个具体的商业需要和应用情景

3.跟踪的详细程度,相比适应型项目,预测型生命周期的项目对跟踪的关注点可能要多很多,比如商业需求、项目范围、产品组件、需求模型、测试用例等

4.需求生命周期的管理,比如新增,已审批,延期,取消,设计中,开发中,测试中,已验收,已实施

等等,准备以此开展工作

step2. 制作跟踪矩阵。跟踪矩阵是在项目生命周期中 将项目需求从源头到满足需求的可交付成果 联系起来的表格,里面包含每项需求及有关需求的事实 的简短描述,目的是让每项需求都通过与商业和项目目标的联系

跟踪矩阵的典型属性包括:需求编号,需求描述,目标(商业需求,商业目的和目标,项目目标),产品开发阶段(设计,构建,测试,实施,验证),WBS,状态(已激活,已批准,已延期,已取消,已增加),列入的理由,优先级,负责人,来源,实现的版本,完成日期

一个典型的需求跟踪矩阵:

摘自《PMI-PBA认证与商业分析实战精析》

4.2 确定需求的关系和依赖性

发现需求彼此间的依赖性关系,比如A1是A的子集,必须在B完成以后才能实施,一旦完成可以实现并明显提升C的创收,那么需求的完成顺序应该是B>A1>C

4.3 批准需求,并将其基准化

定义:由商业分析规划中确定的规则,让具有批准权利的相关方对需求进行审批,将审批后的需求进行基准化,从而组成产品的标准边界

通俗地说,包括以下2个步骤:

step1. 准备和进行需求审批。从商业分析规划部分定义的决策流程中,读取一系列与批准需求相关的信息,比如 BA是发起人,项目团队可以参与评审,BA负责执行需求,项目经理负责管理需求,老板可以否决需求,专家团批准需求变更,BA对最终产品负责等

通过企业组织既定的工作授权系统批准和签字确认,建议在项目实战中尽早确定批准过程,以防止后面在需要进行批准时因各方不认同流程,而陷入沟通冲突和撕逼中

step2. 根据需求基准形成产品边界。由所有被批准的需求组成的产品边界,任何项目工作都应该在基准以内,超出基准的都需要获得批准,需求变更只有通过变更控制流程才能执行,所有需求变更都要被记录和追溯,从而杜绝临时随意追加、更改需求

在适应型生命周期的项目中,每次迭代结束的产品回顾会议上,新发现的需求通常会以用户故事的形式加入产品未完项清单中,由实际承担BA工作的产品负责人维护,基于哪些需求或用户故事能提供最高的商业价值 来进行优先级排序

4.4 使用跟踪矩阵,跟踪和监督需求

通俗地说,包含以下2个过程:

step1. 进行跟踪和监督,发现其中的偏差、缺陷和变更。需求基准确定后,在付诸项目团队开发的全过程中,需要持续与相关方沟通需求状态,及时调整需求细节,避免到最后完成交付和实施后,再进行调整,确保其与商业目标的一致性

随着项目推进,有时候会发现某些需求没有对应的工作成果时,这时存在遗漏重要组件的风险;又可能发现某些需求没有指向的商业需要和价值,这很可能是团队临时YY出来的镀金需求,需去除以防产品和项目的范围蔓延

step2. 采取对应应对措施,调整需求。针对偏差、缺陷和变更,可以采用细化方案完善、寻找替代措施、或直接更改解决方案,来应对

4.5 管理需求变更

需求变更可能发生在项目中的任何过程中,比如

1. 第一次开发项目需求(以餐厅点餐为例,客人一开始点的红烧茄子,好在后厨还没开始动手,大堂经理跑来说客人改了回锅肉)

2. 与相关方在项目需求上取得一致意见后(回锅肉有咸辣和麻辣口味,客人确定要麻辣,可以开始搞)

3. 需求被正式批准,形成需求基准后(后厨回锅肉的所有配料已经就位,肉都回锅了,准备正式搞)

4. 项目产品成功交付,且已将成果部署到运行环境(按客人要求的回锅肉已经翻炒完毕,正准备上桌,客人说小孩子表示肚子不舒服不要了,改清蒸鲈鱼了)

针对需求变更,BA在考虑商业分析规划时,要注意给出以下信息:

1.谁能提出变更,以及提出的形式。不是所有人都有权提出,为保障项目的严谨型,也不能随意提出变更,为沟通协作和避免后续陷入撕逼,最好是以书面形式正式发起,可以是口头,但一定要留底,方便记录和跟踪

2.谁能参与评审需求变更。也不是所有人能参与评审,要规划好可以参与讨论和决策的相关方,比如项目团队都可以参与,但决策人只能是发起人和BA,以及对应的变更控制流程,是书面报备+线下会议审核,还是线上流程一级一级批示

3.需求变更的结果。在不同的企业组织中,需求变更的结果基本是一致的,比如被批准从而调整项目工作、变更合理但本次不需要加入而被延迟、变更不合理被直接否决,或者要求提交更多信息再次发起变更。每当出现尝试插入的新需求,BA和项目经理都要评估其对项目和产品的影响,并提交给相关方进行审批,最后一步一定是根据根据变更批准后的需求,发布新的需求基准,形成新的产品范围

一个需求变更的典型流程包括,记录变更申请(提出人,内容,原因,时间), 对项目和产品的影响范围分析,变更评估,实施变更和变更验证,如下:

摘自华夏智诚《PBA培训讲义》

ps,要注意需求变更和正常的需求细化是有区别的。对部分项目来说,特别是适应型生命周期的项目前期,很多需求并不是一开始就能足够细化的,随着项目推进,不断会有细节来完善这些需求,部分细节的调整,比如网页产品的页面风格、app产品的启动splash停留时间更改,并不能算入需求变更中,但项目经理在规划进度时要预留时间和资源来考虑这些buff,不过这又属于项目经理的工作范畴了,BA要予以支持即可

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

在需求进入开发验证阶段,BA的责任重心是维护所开发需求与关联的可交付成果,以及工作成果的完整性和一致性;当组织成员希望更改需求,或者尝试加入任何新需求,要确保每项更改都与商业需求、商业目标及项目目标保持一致,才能接受更改

因临时决策、弥补缺陷、市场干扰、客户调整、运营需要等带来的需求变更,在项目工作中会经常发生,除自身影响以外,还可能对其他需求、项目计划、决策分析、相关方满意度、资源要求等方面造成影响;由于项目经理关注项目范围,已批准的变更请求一定会对整体的项目管理计划和其他项目文件造成影响,特别是要对既定的项目风险管理中的应对措施进行调整;而BA关注产品范围,需求变更意味着对产品的功能范围、结构组成、品质特征等造成影响,所以正常来说需求变更要项目经理和BA共同处理,积极与相关方沟通,确定对项目和产品的影响

在IT行业采用敏捷开发模式管理的项目,由于每个迭代都是一个冲刺,即时反馈就显得尤为重要,实际充当BA角色的产品负责人,要定期梳理以用户故事形式存在的产品未完项清单,任何用户故事的增删改行为,对商业需求来说是增值的,才能接受

需求跟踪监督的方法过程,可以关注公众号:白猫与黑猫,回复gzjd,获取链接咯

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表