項目PMO工作
算起來。這是第一次以項目PMO人員的身份參與項目，盡管非常可惜沒有從頭參與，也沒有參與到項目結束，僅僅有短短的兩個月。但對項目PMO也可略窺一斑。如今就當個流水賬寫一寫吧。
進項目組的時候，是中午，初春的中午陽光燦爛。照的整個人都是暖的，乍一進了辦公室，有點陰陰的涼，眼睛也有點不太適應。
拿東西、放東西、塑料袋嘩啦啦，這時一個怒極的聲音響起：“你是幹什麽的？！”話說我都沒看到有人在角落裏蒙著腦袋睡覺，結結實實的被嚇了一跳啊！
初來乍到，果然夠“乍”！
這個嚇了我一跳的人，是客戶方的PMO人員，最大的愛好是看球，每逢有球賽。第二天必會在辦公室發表這個好那個壞的相關評論，第二大愛好是展示自己的學識淵博。每天的午飯時間都是他的演講時間，差點兒無論當時談論的是什麽，他都能引到自己知道的內容上去。並滔滔不絕。兩個月的時間，關於他的工作，僅僅聽他打過三個電話，類似這樣：“領導，我是
”其它時間，10次中有8、9次看到都是在摳手機。當然，摳手機也可能是在工作哈，大家都懂的。
進入項目組之後。派到腦袋上的第一件事是參加測試計劃評審會議，事前沒拿到什麽資料，到了會議室一看，這不就是網上的模板嗎？這個還須要評審嗎？只是看到大家都煞有介事討論的挺歡，認為認認人也不錯，於是評審就在認人中過去了。
認完人之後幹什麽呢？看看這個，摳手機。再看看那個，還是摳手機，要不我也摳手機？（忘了說了，這裏沒有外網，內網僅僅能訪問配置庫，沒有郵件系統。通訊基本靠吼，聯絡基本靠腿，所以才僅僅能摳手機。
）
摳著摳著，領導的領導的領導，總之不知道是哪個領導說，要做代碼走查。怎麽做呢？客戶與開發經理溝通，PMO與開發經理溝通，各方的溝通結果是。客戶提供工具，查代碼的規範性。這個工具的運行結果，就是代碼走查報告了，那PMO做什麽呢？有能猜到的嗎？反正我是猜不到。PMO負責數數。數每次運行結果中有多少行有問題，每半個月催著各系統負責人出一次報告。統計當中的問題行數。這就是代碼走查工作了。
代碼走查工作提出來後沒多久，客戶某領導發現SIT測試的壓力太大。而要緩解壓力，最好的辦法就是把單元測試做好，於是我們又有了新工作——單元測試。
單元測試怎麽做呢？嗯，在項目組轉了一圈。沒人願意做這事。那就僅僅能當成任務派下去了，而且下達指標，測試用例數不能比客戶方低（客戶方有同一內容的單元測試）。於是
接著上面的SIT測試說，先是測試案例編寫，這段時間，項目組拼命寫，PMO人員就拼命數。每天統計當天每人寫了多少案例，每一個系統有多少個案例，這事說起來簡單，真做起來的時候就發現對這個加上客戶方至少5方合作的項目來說，真不是件簡單的事。提交上來的內容有總的、有當天的、還有拿著別人的東西當成自己的提交的，還有總的和當天的摻著提交的，總之五花八門什麽樣的都有，要一個個的分出來。數對了。
測試案例統計完了之後。就開始統計測試案例測試情況了，測了多少、通過了多少、有多少個bug。一天天的統計，問測試經理為什麽不搭建TD或者別的系統時，答曰：太費事。於是就一直這麽數著。
除了測試之外，另一件事就是需求變更。越是到了測試階段。越是有多多的變更。PMO的作用就是各方的接口。客戶把需求提到PMO。PMO找項目組相關負責人確認是否變更。不能變更的反饋給客戶，變更的盯著項目組的一步步變更別出錯。
數測試相關的數，事實上說究竟也沒多少工作量。一個人足夠了。而需求變更的管理，一個人也足夠了，那PMO剩下的人幹什麽呢？有了。SIT測試不是人員緊張時間緊張壓力大嗎？都去幫忙啊。
於是我2個月的項目PMO體驗就這麽結束了。項目PMO工作