專案管理例項—— 點評

專案管理例項—— 點評

在MSN專案管理群裡，一位很資深的IT工作人員推薦她的部落格，我粗看了一下確實不錯，準備每篇閱讀一下，當然也希望透過點評一下來提高一下自己。該文章是作者對專案管理例項進行的相關思考。

專案管理例項（1） － 不一樣的PMO
http://blog.c s a i.cn/user2/50754/archives/2009/39793.html

專案管理例項（2） － 選拔專案經理
http://blog.c s a i.cn/user2/50754/archives/2009/40050.html

專案管理例項（3）－換將
http://blog.c s a i.cn/user2/50754/archives/2009/40116.html

專案管理例項（4） － 加人一定管用嗎?　
http://blog.c s a i.cn/user2/50754/archives/2009/40345.html

專案管理例項（5）－2009年終盤點　
http://blog.c s a i.cn/user2/50754/archives/2010/42082.html

首先是PMO的產生
所在公司是一家軟體公司，主要為電子行業、航空航天等軍工企業提供資訊化產品和服務。
1、老闆受他本人在製造業工作經歷的影響，把一個軟體公司的組織結構設定得如同工廠，幾乎每項工作都是一個部門只承擔一部分，不允許參與其他工作。
2、比如售前階段，工作說明書是諮詢部負責完成，合同簽訂後，轉到實施部，實施部的專案經理和業務顧問到客戶那裡進行業務調研工作，編寫出業務調研報告和業務需求說明書，透過評審後才能繼續傳遞文件至下游，下游是設計部，負責需求分析和概要設計，再下面是開發部，負責詳細設計和編碼.。。。。。。
老闆想得挺好，可是最大的問題很快就來了，軟體過程中的文件很難標準化，評審難有標準。而各個環節都希望上游的產出物一定要滿足下游的輸入要求才行，否則下游的部門就不接！，因此，設計部埋怨專案經理和業務顧問寫的業務需求不夠詳細，不夠準確，沒法做需求分析，評審一次次透過不了，同樣道理，開發部門死活不認可設計部的架構師寫的需求規格和概設，認為不能指導詳細設計和編碼工作，而架構師又認為他們只負責需求分析和概要設計，開發部要求的那些事都應當開發人員自己完成。。。。。。
專案經理除了自己要寫業務需求外，整天都在協調、協調，下游環節的部門不接受上游部門的產出物，專案經理也難以判斷該不該傳到到下一棒，需要協調的事情特別多。何況他們的文件也常常被別人狂批，似乎自己也沒協調的資格。
——點評
這個是分工過於職能化的惡果，需求和文件在內部過程中已經失真了，且由於職能化的原因，內部無法達成一致，除了問題只能相互推諉扯皮，缺乏一個整體協調機關
如果採用專案組型會怎麼樣呢？人員無法得到充分利用，專案內部的各個環節質量取決於專案經理的素質，也會造成一定的問題
想必這也是各個公司PMO產生的主要原因之一吧。

一個專案組由各個部門的人組成，無論是產品經理，還是專案經理每推動一步都很費勁，各個部門扯皮的現象層出不窮。就是在這種情況下，老闆設想成立一個公司級的綜合管理部門，將公司主要的骨幹，如專案經理和產品經理集中到1個部門，進行總協調和總負責。這個部門被賦予了相當大的權利，因為老闆希望找一個“強勢”的人能好好替他“管一管”。本人就是在這樣的背景下走馬上任的。我的部門被設定為PMO，與一般公司的 PMO不同，我直接領導專案經理，而且無論何人，不管是哪一個部門，什麼職位，只要擔任專案經理，就都歸我領導。專案經理管理和考核著不屬於同一個部門的的組員，即使組員是其他部門經理，甚至是技術副總監，也仍然歸專案經理領導和考核。因此，本人是一個名副其實的PMO (Officer的O,不是office的O) ，管理和掌控公司所有的專案和產品，
——點評
這是一個比較強勢的PMO，直接劃為一個部門，專案經理比較強勢，而PMO更加強勢。

我預想的PMO會比較溫和一些，由資深的PM和各職能部門經理組成。
制定公司軟體工程和專案管理流程、制定公司文件管理制度。
對專案的軟體生命週期、專案風險等進行指導
對專案經理進行考核
對軟體過程進行監控和度量
對專案中遇到的問題進行評估，協作提供解決方案和再分配

關於選拔專案經理
1、沒有調研到明確的客戶需求，只是將以前已調研到的做了確認；
2、現場調研活動主要以老H為主要提問人，小Z為主要補充提問人。G君在現場基本插不上話；
3、現場工作過程中沒有階段性的詳細計劃，對於雙方的工作安排以及相互配合沒有很好的統一規劃協調；
4、每天的調研情況沒有及時討論彙總；
5、沒有對第二天工作的安排和預期；
作者認為該PM業務不熟悉、對公司專案流程不適應、專案準備不夠充分等等。
其實我的想法是
該PM業務不熟悉是正常的，剛工作的專案經理顯然無法同有此經驗的技術人員相比，專案經理也是需要透過專案不斷去熟悉的，也有個熟悉的過程
該PM對公司專案流程不適應，這也很正常，一般而言從大公司出來的PM與從小公司出來的PM相比，適應性要差一點，為何，在大公司專案流程已經很規範了，他只需要follow即可，而小公司往往缺乏流程，或者需要自己去慢慢摸索和了解；最好的辦法是培訓。
專案準備不夠充分和多方都有關係，但是自信是必須的。
作為PM也需要在不斷的學習和摸索中成長，無論大公司還是小公司出來的PM到了一個新環境都會面臨這個問題。

關於換將
這個在缺乏流程的小公司和人員流動頻繁的公司比較普遍，本人深有同感。
一個專案換了3茬需求調研的售前，換了3茬專案經理，每次去調研又都是在重複同樣的問題，別說客戶會反感，就連專案總監也會感覺很失望。
尤其是在解決方案中給出的10幾個核心名單，在實施過程中幾乎一個也沒有，換成誰，都受不了這個打擊。

關於加人一定管用嗎?
我的看法是在某些時候是管用的，在某些時候是添亂的，很多時候是上司強行安排的，處於無奈必須接受的，這樣的加人只能讓PM感受很差。
為什麼要加人，在什麼階段加人，需要進行評估的，在需求階段加了很多開發人員確實沒有太大作用，可如果為了做demo，在需求階段增加開發人員則是有用的
什麼樣的工作是並行的什麼樣的工作是序列的，什麼工作是最關鍵的，需要甄別清楚再下結論是否需要加人

關於2009年終盤點

1、同時做兩個專案的專案經理比只做一個的要做的好；
個人感覺可能問題出在工作較多的專案經理認為自己受到了重視，其次忙的專案經理更加需要思考，因此更能提升自己。
2、“自稱”不懂技術的專案經理比熟悉技術的專案經理做的好；
不懂技術的專案經理能夠把關注力集中在業務、管理和溝通上，如果太懂技術的話，不知不覺人就會沉溺其中，反而忘了主要工作。
3、研發（非現場）投入最大、現場投入也最大的專案，缺陷最多；
個人理解，現場的壓力會大些，其次具備相應的軟硬體環境，而且客戶隨時可能來抽查，所以保持高度的戒備，缺陷會少些
4、所有專案都是進入內部研發階段，進度控制不錯，而只要有客戶參與，進度就無法保證，但平時幾乎所有專案經理都叫嚷“和客戶打交道容易，內部協調最煩”；
在現場客戶會有一定的干擾作用，但卻又是合情合理的，和與公司的協調，處於自身的尷尬位置是無法去挑明。
5、提前一個月給客戶安裝上線，最後驗收仍然拖後3個月！
這個似乎是通論了，越到上線客戶越會找一堆需求。