專案管理例項—— 點評
專案管理例項（1） － 不一樣的pmo
專案管理例項（2） － 選拔專案經理
專案管理例項（3）－換將
專案管理例項（4） － 加人一定管用嗎?
專案管理例項（5）－2023年終盤點
首先是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，在需求階段增加開發人員則是有用的
什麼樣的工作是並行的什麼樣的工作是序列的，什麼工作是最關鍵的，需要甄別清楚再下結論是否需要加人
關於2023年終盤點
1、同時做兩個專案的專案經理比只做乙個的要做的好；
個人感覺可能問題出在工作較多的專案經理認為自己受到了重視，其次忙的專案經理更加需要思考，因此更能提公升自己。
2、「自稱」不懂技術的專案經理比熟悉技術的專案經理做的好；
不懂技術的專案經理能夠把關注力集中在業務、管理和溝通上，如果太懂技術的話，不知不覺人就會沉溺其中，反而忘了主要工作。
3、研發（非現場）投入最大、現場投入也最大的專案，缺陷最多；
個人理解，現場的壓力會大些，其次具備相應的軟硬體環境，而且客戶隨時可能來抽查，所以保持高度的戒備，缺陷會少些
4、所有專案都是進入內部研發階段，進度控制不錯，而只要有客戶參與，進度就無法保證，但平時幾乎所有專案經理都叫嚷「和客戶打交道容易，內部協調最煩」；
在現場客戶會有一定的干擾作用，但卻又是合情合理的，和與公司的協調，處於自身的尷尬位置是無法去挑明。
5、提前乙個月給客戶安裝上線，最後驗收仍然拖後3個月！
這個似乎是通論了，越到上線客戶越會找一堆需求。
專案管理例項（2） 選拔專案經理
十一 長假前，公司格外忙碌，倒都是令人高興的事情多，兩個專案驗收通過了，乙個專案的實施方案經過艱難的協調客戶也簽字認可了。回想各個專案的過程，選拔乙個合適的專案經理起著至關重要的作用。甚至可以說，選對人，專案就成功了一半。剛剛驗收通過的這個專案，我恰好體會了在選拔專案經理上的失敗和成功。該專案200...
專案管理 專案整體管理
關內容點滴記錄，會持續更新 為實現專案的目標，而領導和執行專案管理計畫中所確定的工作，並實施已批准的變更的過程。本過程主要作用是 對專案工作和可交付成果綜合管理，以提高專案的成功的可能性 答 是一種記錄和跟進所有問題的專案檔案 內容包括 1 問題的型別 2 問題提出者和提出時間 3 問題描述 4 問...
sqlite 專案例項
private string url 單擊事件 private void button1 click object sender,eventargs e private datatable dtcatelog2 繫結資料來源 private datarow dtcatelog private dat...