算起来,这是第一次以项目PMO人员的身份参与项目,虽然很可惜没有从头参与,也没有参与到项目结束,只有短短的两个月,但对项目PMO也可略窥一斑,现在就当个流水账写一写吧。
进项目组的时候,是中午,初春的中午阳光灿烂,照的整个人都是暖的,乍一进了办公室,有点阴阴的凉,眼睛也有点不太适应。拿东西、放东西、塑料袋哗啦啦,这时一个怒极的声音响起:“你是干什么的?!”话说我都没看到有人在角落里蒙着脑袋睡觉,结结实实的被吓了一跳啊!初来乍到,果然够“乍”!
这个吓了我一跳的人,是客户方的PMO人员,最大的爱好是看球,每逢有球赛,第二天必会在办公室发表这个好那个坏的相关评论,第二大爱好是展示自己的学识渊博,每天的午饭时间都是他的演讲时间,几乎不管当时谈论的是什么,他都能引到自己知道的内容上去,并滔滔不绝。两个月的时间,关于他的工作,只听他打过三个电话,类似这样:“领导,我是XXX,跟您汇报一下这个周的工作,我们这个周接了3个反馈单,做了一轮8个系统的代码走查,做了8个系统的单元测试报告收集,做了5份SIT测试进度报告,另外每天统计测试案例编写情况。”其他时间,10次中有8、9次看到都是在抠手机,当然,抠手机也可能是在工作哈,大家都懂的。
进入项目组之后,派到脑袋上的第一件事是参加测试计划评审会议,事前没拿到什么资料,到了会议室一看,这不就是网上的模板吗?这个还需要评审吗?不过看到大家都煞有介事讨论的挺欢,觉得认认人也不错,于是评审就在认人中过去了。
认完人之后干什么呢?看看这个,抠手机,再看看那个,还是抠手机,要不我也抠手机?(忘了说了,这里没有外网,内网只能访问配置库,没有邮件系统,通讯基本靠吼,联络基本靠腿,所以才只能抠手机。)
抠着抠着,领导的领导的领导,总之不知道是哪个领导说,要做代码走查。怎么做呢?客户与开发经理沟通,PMO与开发经理沟通,各方的沟通结果是,客户提供工具,查代码的规范性,这个工具的执行结果,就是代码走查报告了,那PMO做什么呢?有能猜到的吗?反正我是猜不到。PMO负责数数,数每次执行结果中有多少行有问题,每半个月催着各系统负责人出一次报告,统计其中的问题行数,这就是代码走查工作了。
代码走查工作提出来后没多久,客户某领导发现SIT测试的压力太大,而要缓解压力,最好的办法就是把单元测试做好,于是我们又有了新工作——单元测试。单元测试怎么做呢?嗯,在项目组转了一圈,没人愿意做这事。那就只能当成任务派下去了,并且下达指标,测试用例数不能比客户方低(客户方有同一内容的单元测试),于是PMO就负责传达单元测试要求、收集单元测试报告、催着大家做单元测试,单元测试报告收上来,并达到要求之后,单元测试也就结束了。
接着上面的SIT测试说,先是测试案例编写,这段时间,项目组拼命写,PMO人员就拼命数,每天统计当天每人写了多少案例,每个系统有多少个案例,这事说起来简单,真做起来的时候就发现对这个加上客户方至少5方合作的项目来说,真不是件简单的事,提交上来的内容有总的、有当天的、还有拿着别人的东西当成自己的提交的,还有总的和当天的掺着提交的,总之五花八门什么样的都有,要一个个的分出来,数对了。
测试案例统计完了之后,就开始统计测试案例测试情况了,测了多少、通过了多少、有多少个bug,一天天的统计,问测试经理为什么不搭建TD或者别的系统时,答曰:太费事!于是就一直这么数着。除了测试之外,还有一件事就是需求变更,越是到了测试阶段,越是有多多的变更。PMO的作用就是各方的接口,客户把需求提到PMO,PMO找项目组相关负责人确认是否变更,不能变更的反馈给客户,变更的盯着项目组的一步步变更别出错。
数测试相关的数,其实说到底也没多少工作量,一个人足够了,而需求变更的管理,一个人也足够了,那PMO剩下的人干什么呢?有了!SIT测试不是人员紧张时间紧张压力大吗?都去帮忙啊!