PBA®培训:大陆首批PBA®认证经验分享

发布时间:2018-01-15

起因

在第五空间培训PBA®完全是一个偶然加偶然的事情。
2016年年初我的工作就受到了极大的打击,导致我开年比较灰心丧气。所以原本2016年我只想好好的做一个堕落的美男子,安安静静恶补一下自己在产品方面的欠缺,然后向着产品经理+项目经理的混合角色前进。

直到一个叫菜妈的人告诉我要考PBA®,我的堕落算是彻底告一段落。

菜妈很有魄力,在中国第一批考PBA®的时候就报名。而当这位美女人妻拉我一起考试的时候,时间上已经彻彻底底来不及了。所以我只能说:这次算了,等你考完了我就去考试。

嗯,作为一个说话算话的人,在菜妈考完之后,我也就选择去学习。

这里还有一个小插曲,就是当我准备报名的时候,座位已经满了,囧。此时感谢我前些年修行的厚面神功发挥了作用,腆着脸求菜妈去说情,OK,终于赖到了一个加座,耶!


学习的过程

学习过程最让我诟病的,就是每次只有一天课啊(捂脸)。要知道作为一个在旧都上班的社会主义接班人(虽然现在我还不知道我到底要接谁的班,到底谁叫“社会主义”!),每周六周日难道默认不应该是一觉睡到吃晚饭么?当时每周一次课的设定,让我每周六早上4点钟就要爬起来往火车站跑,然后坐着一个5点钟的动车,接着在8点钟赶到上海站。嗯,现在回头看看,真的是很有趣的经历。


在PBA®上课之前,我就从菜妈那边得到了血泪的教训——说什么PBA®,就是PMP®嘛~所以我还是很纠结到底要不要带着PMBOK®的书上课。好在Jason的话直接打消了我的念头。Jason表示不用慌,后面会对PBA®中与PMP®有关的内容进行总结和梳理,所以不用带PMBOK®。我是暗暗松了一口气:终于不用背着大部头跑来跑去(好像有点画风不对)。


在PBA®之前,我只上过PMP®和ACP®的课,所以在上PBA之初,我还是比较震惊。首先,人数上面严格控制,而且对报名人员有PMP®要求。这点是其他培训机构所没有,毕竟招生进来都是钱,控制人数的事情第一次见到。另一点就是上课的方式。原本以为会有比较严谨的PPT内容,然鹅并没有。虽然有PPT,但更多的是针对实例来说,并非针对PBA®自身。PBA®自身的学习更多的是放到了课后,而课堂上讲的很多的是串讲,同时对我们提出的疑问进行解答,这点是非常棒的。


最难能可贵的是,Jason讲的不仅仅是PBA®,同时也会给我们说不少关于项目中实战的问题,我至今都能记得那次关于“项目组成员不配合该如何处理”的话题。至今记忆尤深,且在后续我和我的朋友遇到类似问题时,也都是依样处理,疗效相当好。至于具体方案是啥,请下次来第五空间学习,当面和Jason交流吧,保证你醍醐灌顶,大呼过瘾。


学习以外

1.Jason的口头禅:“伤身体”。作为有样学样的代表,我现在公司内训时都或多或少会有这句话蹦出来(捂脸);

2.貌似Jason很喜欢喝咖啡,连下午茶点的都是咖啡;

3.学友里面卧虎藏龙,各行各业都有很多牛人,让我学到了很多东西;


对PBA®的感觉和总结

我对PBA®的感觉是非常亲切的。

我在2012年考PMP®的时候,我就有一个疑问,那就是项目需求是怎么来的。

这个疑问一直困扰我很久。当时与老师沟通过,老师只是简单的说:项目需求的确定是在项目管理过程组之外,而且作为项目章程的输入存在。至于怎么个存在,怎么存在完全没有将明白。

而PBA®彻底解决了这个问题。如果用一句话来说PBA®的作用,那么就是解决了PBMOK 4.1.1中的输入“商业论证”的问题,也就是PBA®其实可以看作是PMP®过程组的前置过程,是项目“合法”的前提。它承担着项目需求来源的重任,是项目成功的标准“客户满意”的基石。

同时PBA®也并不限于传统的瀑布项目管理,在敏捷中同样适用。项目开发的内容都是来自于需求,所以对项目的过程模型并不限定,无论你是Waterfall、Scrum、XP还是Lean,难道还有人敢不去做需求分析?还敢在需求不明确的情况之下就去开发项目?嗯,这很伤身体啊;)

对于我而言,因为有产品设计与开发的工作经历,所以我在看PBA®里面很多内容,比如线框图、UML之类还是比较亲切和简单,对于一些在产品设计中也会出现的名词的理解也就会轻松一点。所以对PBA®中的工具的还算是比较熟练,所以第四章绝大多数的工具根本都不会考,但是如果想做好一个BA,这部分工具一定要用心去学习、实践,你会获益匪浅。

PBA®的结构也是比较明确,除去第一章的总结性说明之外,后面的五章(需要分析,商业分析规划,需求启发、追踪与监控、解决方案评估)基本上是对应了商业需求、干系人需求、解决方案需求和过渡需求等在PMBOK®中提到过的各种需求,这就很好的将PBA®和PMP®中的知识点联系在一起,让我们可以更好的理解局部与整体的关系。

另外在Jason的讲解之下,我们也发现PBA®的结构与PMP®的五大过程组是紧密对应的。这种对应并非是名称的对应,而是实际内容的对应。我来用我的简单的话语来说一下,大家就会明白了。

PBA®的目标是交付“可用的商业分析”。如果我们将它看成一个项目,那么对找一下我们就会发现PBA®中的五个过程其实是可以这么与PMP®对应的。

PBA®

PMP®过程

需要分析

启动过程组

在这个过程中,我们明确了“提供商业分析”这个事务本身的合理性

商业分析规划

计划过程组

我们怎么去做分析,找哪些人做分析?

需求启发

执行过程组

不用多说,直接干活吧

追踪与监控

监控过程组

活干的好不好,我要看看,适当的情况下要进行改进

解决方案评估

收尾过程组

事情办完了,看看事情结果怎么样,用户是否满意?同时我们要将成果交付给用户,这个交付的过程怎么完成?


所以这么一来大家是不是可以很明确看出来PBA®的结构其实和PMP®是高度一致的呢?


后话

PBA®很重要,它很好的关联了需求与项目管理模型,从而可以拓展到产品层面,让我们可以“做正确的事”,而不是孤单单的只关注“正确的做事”,这对项目经理后续的职业发展有着非常良好的帮助,所以如果不是真的忙到飞起,还是请去学习一下,你不会感到后悔。

如果感觉这还不够,那么Jason的人格魅力、三位美女员工的颜值、无限量的零食会不会让你更有动力一些呢?

最后,一点小福利:根据Jason的建议,我将PBA®书本的目录整理出来,供大家参考。有png版本和mindnode版本。谢谢大家!

Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1