專案管理第一階段的心得體會

一、接手專案階段

專案經理在接手專案時，應該進行專案干係人分析，得出哪些人員對專案起積極推動作用，哪些人員對專案持有消極抵抗態度。隨後，客戶及公司領導會要求制訂一份專案整體計劃，此計劃往往是需要根據客戶方要求的結束日期進行倒推，此份計劃比較粗，只需要按時間點列出進度計劃安排、相應可交付物、投入人力資源。（其實我個人理解這時候的整體計劃更像是里程碑計劃）

除此之外，我覺得還應該準備一份專案範圍說明書，明確專案範圍描述、專案驗收標準等，這在後期範圍變更以及專案驗收時是一個依據。

二、需求階段

此階段需要反覆跟客戶方業務員及相關關係人進行溝通，明確需要開發的需求。此時需要制訂需求說明書，並與客戶方進行確認。

在與客戶方確認需求的同時有可能有些需求暫時無法確認，為了進度不受影響，此時需要專案經理先確認能夠確認的需求，並同時安排專案組成員進行功能設計，這二個過程往往是同時進行的。

確認需求的過程中專案經理需要提交需求說明書、未確認需求的清單說明。

專案經理安排專案組員進行設計過程中需要設計人員提交設計說明書（一般都是介面原型設計），完成設計說明書後有必要提交給客戶方相關人員進行確認。

三、任務分配階段

根據已確認的需求，專案經理需要進行任務分配，任務分配前需要結合需求及設計進行工作分解，將需要完成的工作分解到每個按鈕功能，儘量做到能分解成能在3天內完成的工作。我個人很不贊成專案經理“獨裁”完成任務分配(現實中會出現實施過程中有很多工作任務不在計劃中，而且會出現死命加班的情況)，此過程需要考慮專案組員的業務及技術能力，所以分解過程需要讓專案組員參與，分解完成後提交任務清單文件。

任務分解完成後，根據任務清單及任務優先順序關係分配任務到人，提交任務進度計劃表。

四、定期溝通及監控階段

此階段需要根據專案組員的工作情況進行跟蹤監控，包括工作過程及結果完成情況，需要監控任務完成情況、任務完成與需求匹配情況、程式碼編寫的規範性，找出實際與計劃的偏差，分析偏差，並採取相應措施，提交專案實施過程日檢表、需求矩陣跟蹤表、專案進度跟蹤表、階段性專案進度報告表

監控過程需要做的工作比較多，專案經理往往需要將部分工作交給專案組員完成，比如程式碼編寫的規範性審查可交給技術稍好些的組員協助完成。

監控專案實際完成情況專案經理往往需要通過組員的周工作日誌、專案例會、專案週報來了解，根據實際完成情況與計劃進行對比，找出偏差原因，並採取相關措施，提交進度偏差控制表、糾正預防措施記錄表文檔。

監控任務完成與需求匹配情況專案經理往往需要通過組員完成需求監控清單，將需求落實到程式碼。

定期將可交付物給客戶方進行演示。

此過程還需要制訂出與團隊內部及客戶方進行溝通的計劃，加強溝通，重視溝通。針對會議等形成的決議要定期進行跟蹤，形成會議決議跟蹤表。

五、範圍變更控制階段

在專案實際開發過程中，客戶往往會有需求的調整或變更，這時候需要妥善處理好客戶提出的調整意見或變更要求。

專案經理可根據調整的工作量及業務對系統的整體影響情況與客戶進行溝通，如果調整工作是必須開展的那麼必提交調整或變更申請、評審意見報告，那怕是形式也得提交，因為如果專案因此延期則有理由說不是因為我們的原因；如果調整可放到後期進行則可先把問題記錄下來後期再調整。

此外，變更對專案造成了影響，需要更新專案進度計劃表。

六、團隊建設階段

專案開始專案經理需要制度一些制度，比如上下班制度，會議制度、周工作日誌制度。

專案開發工作繁忙而緊張，團隊成員壓力增大，情緒因此受影響導致工作效率下降在所難免，專案經理要經常觀察團隊成員的情緒，要與團隊成員經常溝通談心，遇到問題要與其一起解決。此外，定期組織團隊活動，如聚餐等。

我個人更喜歡人性化的管理方式，能多照顧團隊成員的儘量多照顧，而不是一味只想著自己。

要想把一個專案做好真的不容易，或多或少會與客戶方產生矛盾。我個人覺得我們作為乙方，應該站在甲方客戶的位置多思考問題，找到雙方都能較為認可的解決方案，做到“尊重、聆聽、理解、共贏”。