專案管理的心得體會

  專案管理是管理科學的重要分支,成熟於20世紀末,是綜合利用各種知識、技能、工具、方法,對專案進行有效地計劃、組織、協調、和控制,以實現專案目標的過程。接下來就跟著小編的腳步一起去看一下關於吧。

  篇1

  專案經理是為專案的成功策劃和執行負總責的人。為此專案經理必須在一系列的專案計劃、組織和控制活動中做好領導工作,從而實現專案目標。從職業角度,專案經理是指企業建立以專案經理責任制為核心,對專案實行質量、安全、進度、成本管理的責任保證體系和全面提高專案管理水平設立的重要管理崗位。專案經理是專案團隊的領導者,專案經理首要職責是在預算範圍內按時優質地領導專案小組完成全部專案工作內容,並使客戶滿意。本文分享筆者的專案管理心得。

  1、專案要進行整體管理,善始善終

  整個專案開始要做好專案整體計劃,在專案的整個過程中,始終要按照專案計劃執行,如若遇到專案發生變更,要進行影響分析,得到批准後製定變更計劃,並按變更計劃執行。變更的影響情況,如:費用,時間進度等要通知相關的專案利益干係人,說明變更的原因和產生的影響。

  專案首尾工作也是專案管理中,一項重要的工作。需要將專案過程中產生的檔案資料進行整理,歸檔;對專案的費用和進度進行審計和稽核,對專案的質量進行檢驗和驗收;對專案的整個過程的利弊得失進行總結和交流。

  變更計劃在軟體專案中經常遇到。控制好軟體專案的變更,首先需要做好專案的開始目標基準的確定,基準的使用者需求明確,才能衡量出哪些是需要變更的。否則變更的東西和開始要求的東西混在一起,變更計劃就無從制定,變更的界限也無從劃清。

  自己做過的一個專案,開始為了佔領市場和儘快拿下合同,在使用者需求還沒有詳細提供的條件下,就與使用者簽定了合同,後來不僅費用受到限制,就連時間不夠,在專案過程中,使用者方還總是變更軟體的功能和要求。因為沒有一個基點,我們認為是變更需求和新增功能,而使用者方認為是合同範圍,不能因此增加費用和時間。這個專案在開始好象簽定了合同我們爭取了主動,其實需求不明確,使我們在後來的專案程序中一直處於被動。

  所以專案從一開始就要做好計劃,搞清目標。只有專案的目標明確,合理安排時間、費用、人力和其他資源,控制好專案的變更,這些是保證專案能夠順利完成的基本條件。

  2、質量管理是專案成敗的關鍵

  我們在進行軟體專案過程中,對軟體的功能測試一直認為還是比較認真和嚴格的,每次測試都要有測試計劃和用例的編寫,然後才能進行測試;測試要有記錄,並將記錄整理成測試報告。

  但通過此次培訓後,感覺到我們的測試工作與質量管理的要求還差的遠,有距離。質量控制要深入到每個與專案相關的人,要深入到專案的每個過程中,從一開始,就要樹立質量第一的理念,每個過程都要進行質量的控制,而不是到最好測試時,才想到質量,才去衡量是否符合標準。

  標準化設計,標準化管理是專案質量的保證。參加質量體系認證有助於企業提高專案的管理水平,有利於提高工程專案質量。CMM模型已得到廣泛的認可和接受,CMMI沿用其模型的組織方式,有5個等級和18個要素。通過5個等級的認證和加強管理,企業對專案的管理將經過5個境界的提高:從混亂,到里程碑的檢查,到定義清楚的管理體系和標準,到進行統計過程控制量化管理,到最後的優化過程、評價工作流程、進行工作過程的改進。

  篇2

  前段時間,我負責了一個專案的管理與開發。在時間短、任務緊,而團隊人員又大部分是沒有經驗的菜鳥的惡劣情況下,我帶領接近40人的團隊,終於在客戶規定 的時間範圍內如期交付產品。這其中,經歷了需求變更、人員變動因為其它任務,先後有近10人離開團隊等諸多問題,專案仍然取得了成功,不能不說有幾分 僥倖,但此外也有一些經驗與教訓可以與大家分享。

  專案開發方面

  專案應以需求為核心。一個專案是否能夠成功,對需求的準確把握在成功因素中要佔上60%的比例。不管系統的架構設計、團隊管理有多麼的成功,如果需求出現偏差,仍然是南轅北轍。由於EAS專案的特殊性,專案開發過程中能夠與客戶建立有效快速的溝通渠道,是專案成功的關鍵。

  需求必須獲得客戶的確認。通過需求調研與分析後獲得的使用者需 求說明書,以及軟體需求規格說明書都必須得到客戶的簽字確認。確認的內容包括專案的目標、範圍以及專案需求功能點用例。EAS專案在前期對需求不夠重 視,導致在需求理解上出現了一些偏差,從而影響了專案的進度。幸而得到了及時的糾正,在專案管理部的協助下,所有需求都得了客戶或客戶代表的簽字確認。從 而使得專案在客戶驗收時,有了充分的保證。

  專案應確立專門的需求分析師。公司沒有專門的需求分析師,不能不說是人員配備上的一大弊端。軟體開放工作細分的第一步就是要有專門的系統分析員或需求分析師從EAS專案的開發過程中,我們就充分地認識到這一問題的嚴重性。需求的不斷更改,客戶遲遲未簽字確認,原因正是在於我們沒有專門的具有豐富經驗的需求分析師。普通開發人員在調研需求以及撰寫需求規格說明書時,總是會出現偏差或理解錯誤的地方。軟體需求分析是一項重要且負責的技術,沒有經過專門訓練的需求分析師,通常會給專案帶來隱患。

  專案應指定各個模組的需求介面人。只有這樣,才能有效地保證專案組與客戶的及時溝通,快速響應客戶的請求與反饋。EAS專案在開發早期及時地確立了需求接 口人,在一定程度上規避了需求變更給專案帶來的風險。但是,確立的需求介面人未經過系統培訓,在需求調研以及與客戶溝通的過程中,工作表現只能說是差強人 意。

  注意維護需求調研記錄以及需求跟蹤表。這一工作做得不夠好。由於需求調研人不夠專業,而專案經理以及需求分析負責人對這一過程還欠缺足夠的重視,同時沒有 好的工具或流程來監控這一過程,使得需求調研記錄沒有發揮更大的作用。此外,需求跟蹤也非常重要,畢竟,任何專案的需求都不是固定不變的,需求隨時會發生 變更,而開發人員實現的需求也可能會與客戶的要求偏差。

  注意維護需求矩陣。專案經理對這一內容缺乏足夠的重視與理解,專案開發過程體系中也缺乏好的需求矩陣文件模板。但是在專案中後期,專案及時撰寫了EAS專案需求功能列表,並結合交付版本與客戶進行了溝通和協商,從而規避了需求偏差的風險。需求追蹤,任何原始需求來有頭就有尾。原始需求->使用者需求->產品需求->軟體需求->設計->測試等一系列的追蹤。需求追蹤的目的一方面是檢查需求是否都已經實現有無遺漏,更多的是為了做變更影響分析使用

  控制需求變更。重視CCB的作用,同時應建立需求變更的響應機制。EAS專案組對於需求變更的響應還不夠及時,這一點專案經理與專案管理小組要擔負一定的責任。範圍管理中範圍控制的內容,變更管理是配置管理的一個重要內容。需求必須要受到控制,否則容易引起計劃的頻繁調整而發生混亂