算起来。这是第一次以项目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測试不是人员紧张时间紧张压力大吗？都去帮忙啊。