算起来，这是第一次以项目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测试不是人员紧张时间紧张压力大吗？都去帮忙啊！
于是我2个月的项目PMO体验就这么结束了。原文地址：http://blog.csdn.net/violet200211/article/details/25373093
