第一篇：項目經(jīng)理心得體會與經(jīng)驗

十四冶項目管理培訓心得

創(chuàng)鑫公司

工程部

李自光

一． 項目要進行整體管理，善始善終

整個項目開始要做好項目整體計劃，在項目的整個過程中，始終要按照項目計劃執(zhí)行，如若遇到項目發(fā)生變更，要進行影響分析，得到批準后制定變更計劃，并按變更計劃執(zhí)行。變更的影響情況，如：費用，時間進度等要通知相關的項目利益干系人，說明變更的原因和產(chǎn)生的影響。項目首尾工作也是項目管理中，一項重要的工作。需要將項目過程中產(chǎn)生的文件資料進行整理，歸檔；對項目的費用和進度進行審計和審核，對項目的質量進行檢驗和驗收；對項目的整個過程的利弊得失進行總結和交流。

變更計劃在軟件項目中經(jīng)常遇到?？刂坪密浖椖康淖兏紫刃枰龊庙椖康拈_始目標基準的確定，基準的用戶需求明確，才能衡量出哪些是需要變更的。否則變更的東西和開始要求的東西混在一起，變更計劃就無從制定，變更的界限也無從劃清。

自己做過的一個項目，開始為了占領市場和盡快拿下合同，在用戶需求還沒有詳細提供的條件下，就與用戶簽定了合同，后來不僅費用受到限制，就連時間不夠，在項目過程中，用戶方還總是變更軟件的功能和要求。因為沒有一個基點，我們認為是變更需求和新增功能，而用戶方認為是合同范圍，不能因此增加費用和時間。這個項目在開始好象簽定了合同我們爭取了主動，其實需求不明確，使我們在后來的項目進程中一直處于被動。所以項目從一開始就要做好計劃，搞清目標。只有項目的目標明確，合理安排時間、費用、人力和其他資源，控制好項目的變更，這些是保證項目能夠順利完成的基本條件。

二． 項目范圍管理理論解決了項目開始需求不清的問題

需求管理是項目范圍管理中的問題，這是因為它實際上是開發(fā)過程中的所有管理原則的先決條件。只有在開發(fā)的目標被清楚明白地表述和理解的情況下，軟件開發(fā)才能以一種有計劃的有序的方式進行。實際上，沒有文檔化的需求，在開發(fā)工作完成前后都很有可能發(fā)生產(chǎn)品與要求的偏離。計劃、追蹤、配置管理以及軟件質量保證這些在其他關鍵過程中涉及的原則，都是從一個穩(wěn)定的基礎開始的，那就是文檔化的需求基線。

什么需求？需求是指“分配給軟件的系統(tǒng)需求”，或者更簡潔地說，“分配需求”。這些需求有可能是技術方面的（比如：功能和性能需求），也有可能是非技術方面的（比如：發(fā)布日期，開支限度）。區(qū)分開需求管理和軟件需求分析是很重要的。一旦分配需求被文檔化，并且被所有受影響部門（客戶，系統(tǒng)工程，軟件工程）通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據(jù)證明分配需求本身就可以十分清楚完整的作為軟件開發(fā)的全部基礎。事實上，通常它們不是。優(yōu)化和精確描述需求，填補漏洞，將含義表達得更清楚是軟件需求分析要做的，分析的結果被稱為“軟件需求“。這樣，作為需求管理的輸出的分配需求實際上就成了軟件需求分析的輸入。需求管理遠遠先于軟件開發(fā)的技術行動，而軟件需求分析則是關鍵開發(fā)技術行為的第一步。從這里的描述看來，需求管理的活動簡直太簡單，太基礎了，顯然沒有哪個軟件開發(fā)組織會不有效的進行著這種活動。問題經(jīng)常出在企業(yè)對透明度的懼怕?？蛻粲X得保持需求含糊不清，松散或者無正式文件能夠給他們

更多的機會去說：“那并不是我所要的，那并不是我認為的需求的含義”。文檔化清晰的需求可能迫使用戶在系統(tǒng)滿足了文檔化的需求但沒有滿足實際需要的情況下，為開始變更負責。相似地，開發(fā)人員覺得含糊不清，松散或者無正式文件的需求能給他們更大的余地，允許他們與預算和進度盡可能地接近，然后說：“這就是我們所認為的需求的含義，如果你需要其他的什么東西，你必須另外付出代價。”文檔化清晰的需求會迫使開發(fā)者承擔滿足這些需求的義務，并使他們暴露于開支、進度評估不準確的風險之下。

這樣一來，盡管客戶與開發(fā)人員的利益動機相對，但他們卻走到了一起。每一方都認為他們在保護自己的利益，鞏固自己討價還價的地位，但是事實上每一方都在走向將來的失望和爭吵，為項目埋下了一刻定時炸彈。

三．項目時間管理理論指導我們在項目管理中怎樣抓主要矛盾。

以前進行項目管理時，是根據(jù)經(jīng)驗和每個人的工作特點，進行項目的分工的，軟件項目基本是按照需求分析，概要設計，詳細設計，代碼編程，調(diào)試和測試，用戶驗收等幾個主要過程來進行的。但將項目分工更加細化，每個小過程的時間估算是多少，整個項目可以最短用多少時間來完成，怎樣合理安排人員，怎樣抓項目中的關鍵環(huán)節(jié)等等，這些都沒有進行過量化的分析和管理。項目管理的實施最為直觀的就是縮短項目時間。利用項目管理理論、方法，有許多縮短時間的例子。美國路易斯維化工廠檢修時把檢修流程精細分解，按導向圖建立起控制關系。他們驚奇地發(fā)現(xiàn)，檢修過程選擇不同路徑總時間是有差別的。通過反復壓縮最長路徑上的任務，將工期反復優(yōu)化，最后只用７８個小時就完成了通常需１２５小時完成的檢修，節(jié)省時間３８％。這就是至今項目管理工作者還在應用的著名的時間管理技術ＣＰＭ，即“關鍵路徑法”。所以我們在軟件的項目管理中，也要將時間控制理論運用進來，結合軟件工程的實際，將任務分解的更加詳細，并用網(wǎng)絡圖將整個工作過程建立起來，估算好每個階段的歷時，找出關鍵路徑，并通過快速跟進方法，將關鍵路徑的工期縮短，以提高工效。

四． 質量管理是項目成敗的關鍵

我們在進行軟件項目過程中，對軟件的功能測試一直認為還是比較認真和嚴格的，每次測試都要有測試計劃和用例的編寫，然后才能進行測試；測試要有記錄，并將記錄整理成測試報告。但通過此次培訓后，感覺到我們的測試工作與質量管理的要求還差的遠，有距離。質量控制要深入到每個與項目相關的人，要深入到項目的每個過程中，從一開始，就要樹立質量第一的理念，每個過程都要進行質量的控制，而不是到最好測試時，才想到質量，才去衡量是否符合標準。標準化設計，標準化管理是項目質量的保證。參加質量體系認證有助于企業(yè)提高項目的管理水平，有利于提高工程項目質量。CMM模型已得到廣泛的認可和接受，CMMI沿用其模型的組織方式，有5個等級和18個要素。通過5個等級的認證和加強管理，企業(yè)對項目的管理將經(jīng)過5個境界的提高：從混亂，到里程碑的檢查，到定義清楚的管理體系和標準，到進行統(tǒng)計過程控制量化管理，到最后的優(yōu)化過程、評價工作流程、進行工作過程的改進。本人以前參加過為日本軟件進行部分功能的設計和編程工作。日本的軟件企業(yè)對一個項目的質量控制就做的比較細致，用我們的觀念衡量簡直是不可容忍。做一個模塊的詳細設計，要用他們提供的標準的圖形語言進行描述，用標準的設計摸版進行說明；并在設計完成后組織相關人員對這個設計進行評價，有問題需要修改設計，然后在評價直到通過才能開時以此為設計文件，進行代碼。代碼寫完后，不是見到結果就完事了，要將代碼打印出來，相關人員對代碼的整個實現(xiàn)過程進行評價，提出修改建議，代碼修改后，需要再審，也是通過以后才能提交入代碼庫，進行代碼的組裝。當時認為日本的方法太浪費時間和人力了，對技術人員個人的能力估計的太低，怎么能提高工

作效率吶?？墒擒浖|量問題的頻繁出現(xiàn)，是我們不斷的認識到，開始浪費一些時間和人力，控制好每個細節(jié)的質量，就是省去了許多時候為解決質量問題而進行的新的時間和人力的支出。省去了大量的軟件后期的質量維護費用?？偟膩砜词呛怂愕?。為提高項目的質量，降低成本，必須從項目的開始就要做好質量的控制工作。

五． 溝通管理中的一些策略的使用可以使項目更好的完成

做項目就需要與客戶接觸，就會出現(xiàn)一些正式和非正式的談判。雙方都會為自己方的利益而進行討價還價。與客戶之間搞好溝通，是項目進展是否順利的一個條件。溝通中有許多的策略在平時的實際工作中可以使用，目的不是坑害別人，而是為了更好地完成項目，達到雙方事先確定的目標，而采用的一些藝術手段而已。溝通的技巧包括：下達最終期限，使用吃驚方法，采用有限權利法，不露面的人，公平合理，戰(zhàn)略延遲，雙方一起論理，撤退，不合理，既成事實等。本人就是成功的采用了戰(zhàn)略延遲法，將客戶方的一筆項目質保金及時地催要了回來。體會還有很多，總之通過這次學習自己對項目的管理又有了新的認識，我會將這些理論知識運用到實際工作中去的。以提高項目的管理水平，提高項目的質量，降低項目的成本，降低項目的風險，最終提高企業(yè)的效益。

第二篇：項目經(jīng)理管理心得體會與經(jīng)驗

項目經(jīng)理管理心得體會與經(jīng)驗

項目經(jīng)理管理心得一．項目要進行整體管理，善始善終

整個項目開始要做好項目整體計劃，在項目的整個過程中，始終要按照項目計劃執(zhí)行，如若遇到項目發(fā)生變更，要進行影響分析，得到批準后制定變更計劃，并按變更計劃執(zhí)行。變更的影響情況，如：費用，時間進度 要通知相關的項目利益干系人，說明變更的原因和產(chǎn)生的影響。

項目首尾工作也是項目管理中，一項重要的工作。需要將項目過程中產(chǎn)生的文件資料進行整理，歸檔；對項目的費用和進度進行審計和審核，對項目的質量進行檢驗和驗收；對項目的整個過程的利弊得失進行總結和交流。

變更計劃在軟件項目中經(jīng)常遇到?？刂坪密浖椖康淖兏紫刃枰龊庙椖康拈_始目標基準的確定，基準的用戶需求明確，才能衡量出哪些是需要變更的。否則變更的東西和開始要求的東西混在一起，變更計劃就無從制定，變更的界限也無從劃清。

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

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

項目經(jīng)理管理心得二．項目范圍管理理論解決了項目開始需求不清的問題

需求管理是項目范圍管理中的問題，這是因為它實際上是開發(fā)過程中的所有管理原則的先決條件。只有在開發(fā)的目標被清楚明白地表述和理解的情況下，軟件開發(fā)才能以一種有計劃的有序的方式進行。馬為一——人性領導力學派創(chuàng)始人！中華培訓講師網(wǎng)高級講師，現(xiàn)任天下伐謀公司高級合伙人、簽約講師！實際上，沒有文檔化的需求，在開發(fā)工作完成前后都很有可能發(fā)生產(chǎn)品與要求的偏離。計劃、追蹤、配置管理以及軟件質量保證這些在其他關鍵過程中涉及的原則，都是從一個穩(wěn)定的基礎開始的，那就是文檔化的需求基線。

什么需求？需求是指“分配給軟件的系統(tǒng)需求”，或者更簡潔地說，“分配需求”。這些需求有可能是技術方面的（比如：功能和性能需求），也有可能是非技術方面的（比如：發(fā)布日期，開支限度）。

區(qū)分開需求管理和軟件需求分析是很重要的。一旦分配需求被文檔化，并且被所有受影響部門（客戶，系統(tǒng)工程，軟件工程）通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據(jù)證明分配需求本身就可以十分清楚完整的作為軟件開發(fā)的全部基礎。事實上，通常它們不是。

優(yōu)化和精確描述需求，填補漏洞，將含義表達得更清楚是軟件需求分析要做的，分析的結果被稱為“軟件需求“。這樣，作為需求管理的輸出的分配需求實際上就成了軟件需求分析的輸入。需求管理遠遠先于軟件開發(fā)的技術行動，而軟件需求分析則是關鍵開發(fā)技術行為的第一步。

從這里的描述看來，需求管理的活動簡直太簡單，太基礎了，顯然沒有哪個軟件開發(fā)組織會不有效的進行著這種活動。問題經(jīng)常出在企業(yè)對透明度的懼怕。客戶覺得保持需求含糊不清，松散或者無正式文件能夠給他們更多的機會去說：“那并不是我所要的，那并不是我認為的需求的含義”。文檔化清晰的需求可能迫使用戶在系統(tǒng)滿足了文檔化的需求但沒有滿足實際需要的情況下，為開始變更負責。相似地，開發(fā)人員覺得含糊不清，松散或者無正式文件的需求能給他們更大的余地，允許他們與預算和進度盡可能地接近，然后說：“這就是我們所認為的需求的含義，如果你需要其他的什么東西，你必須另外付出代價。”文檔化清晰的需求會迫使開發(fā)者承擔滿足這些需求的義務，并使他們暴露于開支、進度評估不準確的風險之下。

這樣一來，盡管客戶與開發(fā)人員的利益動機相對，但他們卻走到了一起。每一方都認為他們在保護自己的利益，鞏固自己討價還價的地位，但是事實上每一方都在走向將來的失望和爭吵，為項目埋下了一刻定時炸彈。

第三篇：項目經(jīng)理管理心得體會與經(jīng)驗

項目經(jīng)理管理心得體會與經(jīng)驗

杭州奧體博覽中心主體育場項目經(jīng)理 趙純陽

一． 項目要進行整體管理，善始善終

整個項目開始要做好項目整體計劃，在項目的整個過程中，始終要按照項目計劃執(zhí)行，如若遇到項目發(fā)生變更，要進行影響分析，得到批準后制定變更計劃，并按變更計劃執(zhí)行。變更的影響情況，如：費用，時間進度等要通知相關的項目利益干系人，說明變更的原因和產(chǎn)生的影響。

項目首尾工作也是項目管理中，一項重要的工作。需要將項目過程中產(chǎn)生的文件資料進行整理，歸檔；對項目的費用和進度進行審計和審核，對項目的質量進行檢驗和驗收；對項目的整個過程的利弊得失進行總結和交流。

變更計劃在軟件項目中經(jīng)常遇到?？刂坪密浖椖康淖兏?，首先需要做好項目的開始目標基準的確定，基準的用戶需求明確，才能衡量出哪些是需要變更的。否則變更的東西和開始要求的東西混在一起，變更計劃就無從制定，變更的界限也無從劃清。

自己做過的一個項目，開始為了占領市場和盡快拿下合同，在用戶需求還沒有詳細提供的條件下，就與用戶簽定了合同，后來不僅費用受到限制，就連時間不夠，在項目過程中，用戶方還總是變更軟件的功能和要求。因為沒有一個基點，我們認為是變更需求和新增功能，而用戶方認為是合同范圍，不能因此增加費用和時間。這個項目在開始好象簽定了合同我們爭取了主動，其實需求不明確，使我們在后來的項目進程中一直處于被動。所以項目從一開始就要做好計劃，搞清目標。只有項目的目標明確，合理安排時間、費用、人力和其他資源，控制好項目的變更，這些是保證項目能夠順利完成的基本條件。

二． 項目范圍管理理論解決了項目開始需求不清的問題 需求管理是項目范圍管理中的問題，這是因為它實際上是開發(fā)過程中的所有管理原則的先決條件。只有在開發(fā)的目標被清楚明白地表述和理解的情況下，軟件開發(fā)才能以一種有計劃的有序的方式進行。實際上，沒有文檔化的需求，在開發(fā)工作完成前后都很有可能發(fā)生產(chǎn)品與要求的偏離。計劃、追蹤、配置管理以及軟件質量保證這些在其他關鍵過程中涉及的原則，都是從一個穩(wěn)定的基礎開始的，那就是文檔化的需求基線。什么需求？需求是指“分配給軟件的系統(tǒng)需求”，或者更簡潔地說，“分配需求”。這些需求有可能是技術方面的（比如：功能和性能需求），也有可能是非技術方面的（比如：發(fā)布日期，開支限度）。

區(qū)分開需求管理和軟件需求分析是很重要的。一旦分配需求被文檔化，并且被所有受影響部門（客戶，系統(tǒng)工程，軟件工程）通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據(jù)證明分配需求本身就可以十分清楚完整的作為軟件開發(fā)的全部基礎。事實上，通常它們不是。

優(yōu)化和精確描述需求，填補漏洞，將含義表達得更清楚是軟件需求分析要做的，分析的結果被稱為“軟件需求“。這樣，作為需求管理的輸出的分配需求實際上就成了軟件需求分析的輸入。需求管理遠遠先于軟件開發(fā)的技術行動，而軟件需求分析則是關鍵開發(fā)技術行為的第一步。

從這里的描述看來，需求管理的活動簡直太簡單，太基礎了，顯然沒有哪個軟件開發(fā)組織會不有效的進行著這種活動。問題經(jīng)常出在企業(yè)對透明度的懼怕?？蛻粲X得保持需求含糊不清，松散或者無正式文件能夠給他們更多的機會去說：“那并不是我所要的，那并不是我認為的需求的含義”。文檔化清晰的需求可能迫使用戶在系統(tǒng)滿足了文檔化的需求但沒有滿足實際需要的情況下，為開始變更負責。相似地，開發(fā)人員覺得含糊不清，松散或者無正式文件的需求能給他們更大的余地，允許他們與預算和進度盡可能地接近，然后說：“這就是我們所認為的需求的含義，如果你需要其他的什么東西，你必須另外付出代價?！蔽臋n化清晰的需求會迫使開發(fā)者承擔滿足這些需求的義務，并使他們暴露于開支、進度評估不準確的風險之下。

這樣一來，盡管客戶與開發(fā)人員的利益動機相對，但他們卻走到了一起。每一方都認為他們在保護自己的利益，鞏固自己討價還價的地位，但是事實上每一方都在走向將來的失望和爭吵，為項目埋下了一刻定時炸彈。

三． 質量管理是項目成敗的關鍵

我們在進行軟件項目過程中，對軟件的功能測試一直認為還是比較認真和嚴格的，每次測試都要有測試計劃和用例的編寫，然后才能進行測試；測試要有記錄，并將記錄整理成測試報告。但通過此次培訓后，感覺到我們的測試工作與質量管理的要求還差的遠，有距離。質量控制要深入到每個與項目相關的人，要深入到項目的每個過程中，從一開始，就要樹立質量第一的理念，每個過程都要進行質量的控制，而不是到最好測試時，才想到質量，才去衡量是否符合標準。

標準化設計，標準化管理是項目質量的保證。參加質量體系認證有助于企業(yè)提高項目的管理水平，有利于提高工程項目質量。CMM模型已得到廣泛的認可和接受，CMMI沿用其模型的組織方式，有5個等級和18個要素。通過5個等級的認證和加強管理，企業(yè)對項目的管理將經(jīng)過5個境界的提高：從混亂，到里程碑的檢查，到定義清楚的管理體系和標準，到進行統(tǒng)計過程控制量化管理，到最后的優(yōu)化過程、評價工作流程、進行工作過程的改進。

四． 溝通管理中的一些策略的使用可以使項目更好的完成

做項目就需要與客戶接觸，就會出現(xiàn)一些正式和非正式的談判。雙方都會為自己方的利益而進行討價還價。與客戶之間搞好溝通，是項目進展是否順利的一個條件。溝通中有許多的策略在平時的實際工作中可以使用，目的不是坑害別人，而是為了更好地完成項目，達到雙方事先確定的目標，而采用的一些藝術手段而已。溝通的技巧包括：下達最終期限，使用吃驚方法，采用有限權利法，不露面的人，公平合理，戰(zhàn)略延遲，雙方一起論理，撤退，不合理，既成事實等。本人就是成功的采用了戰(zhàn)略延遲法，將客戶方的一筆項目質保金及時地催要了回來。體會還有很多，總之通過這次學習自己對項目的管理又有了新的認識，我會將這些理論知識運用到實際工作中去的。以提高項目的管理水平，提高項目的質量，降低項目的成本，降低項目的風險，最終提高企業(yè)的效益。

第四篇：項目經(jīng)理經(jīng)驗

項目經(jīng)理是什么？

Q: 項目經(jīng)理是什么？

項目經(jīng)理是公司委派，負責實現(xiàn)項目目標的個人，是公司授權的項目負責人，是項目的直 接組織者和管理者。

Q：項目經(jīng)理的職責是什么？

? ? ? 對項目全過程進行組織和管理，按預期交付項目的成果 管理客戶關系，以取得客戶對交付的成果和過程最滿意的評價 管理項目團隊，使之高效而愉快的工作，并獲得最滿意的工作體驗 Q：IT項目經(jīng)理的主要任務是什么？

1.支持售前過程。IT項目一般比較復雜，交付風險大，需要在合同中約定工作范2.3.4.5.圍，進度 計劃要估算成本和人力資源，制定切實可行的實施方案。

負責項目交付。圍繞目標，按照規(guī)范執(zhí)行項目計劃。按期匯報進度，保證項目在計劃內(nèi) 交付。

完成項目收尾。完成交付成果之后，要講成果轉移給客戶，確?？蛻艨梢苑€(wěn)定地使用系 統(tǒng)。

管理干系人的關系。溝通各方人員信息，保持密切聯(lián)系，解決矛盾沖突。

管理項目團隊。尋找合適的資源，優(yōu)化資源配置，建立合理的組織結構，確定清晰的職 責分工，打造高效的項目團隊。需要什么素質？

領導力。領導力是指通過他人來完成工作的能力。領導力并不意味著『官』，而應 該是『領頭的』。不僅要求別人做的自己能做到，而且要知道『下一步』，目標在哪里。

責任心。出于對承諾的負責，會傾盡全力達成目標。積極主動。善于利用自身的優(yōu)勢改變局勢。

壓力承受。需要在壓力中仍能保持鎮(zhèn)定，冷靜思考。需要的知識和技能 專業(yè)知識

? ? ? 1.2.3.4.項目管理專業(yè)知識 IT技術 行業(yè)知識

實踐技能

? 商務技能。要代表公司管理項目，履行合同。? 項目啟動。真正進入項目的第一個階段往往是最慌亂的，必須清楚知道每天要做什么，這 樣才能有條不紊。

計劃的制定需要工具和平臺，執(zhí)行需要推進，質量需要把控。明確質量管理內(nèi)容，以及在 什么情況下有權利喊『?！?。?

軟技能

? ? ? 溝通和協(xié)調(diào)。溝通包括識別溝通對象，建立溝通渠道，明確溝通信息。團隊和激勵。必須讓成員能夠團結，為了共同的目標而努力。政治和文化。

項目啟動的第一周

項目啟動時，需要做的事情：

? ? 建立組織和制度。建立組織結構，確定職責分工，確定基本規(guī)章制度和工作流程。明確工作思路。一邊是要確認工作范圍，制定工作計劃；另一邊要確定開發(fā)方法，特別是 馬上要確定需求文檔格式和工作流程。

啟動的準備工作

1.確認項目范圍。項目中范圍包括兩大類：一類是產(chǎn)品范圍，也就是應該覆蓋的業(yè)務 需求；一類是為了實現(xiàn)項目目標所需要完成的工作。將功能層級進行約定：

1.子系統(tǒng)：指相對比較獨立、功能完整一組業(yè)務功能。2.功能集：指在子系統(tǒng)內(nèi)，按照業(yè)務特性歸集的一組操作。3.執(zhí)行單元：一次完成的一個獨立業(yè)務操作。

粗略工作量估算。

人力資源的配置。

確定開發(fā)過程。按照項目的實際情況，制定一個《項目開發(fā)過程》的文件。明確項 目的開發(fā)階段，明確各階段的交付物，制定交付物的模板。群策群力，制定項目計劃的方法

? ? ? ? 根據(jù)WBS方法指定活動清單。確定活動之間的依賴，繪制網(wǎng)絡圖。

根據(jù)網(wǎng)絡圖的依賴關系和工期需求，分配資源，確定進度計劃和資源計劃。根據(jù)資源和進度計劃，制定項目預算。

通過需求矩陣，進行具體項目管理

需求矩陣按照子系統(tǒng)、功能集和執(zhí)行單元的結構列出所有的功能需求，每列對應每項工作的 工作步驟以及每個步驟的工作量。

制定活動清單

計劃過程的步驟如下：

排序和網(wǎng)絡圖分析

有了活動清單和依賴關系，就可以進行排序了。我們可以使用節(jié)點表示任務，用箭頭表示依 賴關系。

通過對網(wǎng)絡圖進行分析，可以得到項目與時間相關的一些重要信息： ? ? ? 給定項目的預計和開始時間，能夠計算每項活動必須開始和完成的最早時間。給定項目的要求完工時間，能夠計算每項活動必須開始和完成的最晚時間。確定項目的關鍵路徑，也就是最長活動路徑。

資源和進度計劃

進度計劃是將工作計劃安排到日歷上，它不僅規(guī)定了整個項目各個階段的起止日期，還規(guī)定 了所有項目的開始和結束日期。可以使用甘特圖進行項目中的進度管理。進度計劃排定時，重點考慮兩點：

? ? 資源的使用情況是否合理，是否存在資源沖突的情況。

對于那些有較大浮動時間的活動，可以初步確定是越早開始越好，還是越晚開始越好。

執(zhí)行和檢查

對于辛苦制定地計劃，如何讓每個人按照計劃工作？如果知道每個人的工作進展？

阻礙計劃落地執(zhí)行的原因

主要計劃落地的主要原因有兩點：

? 沒有將計劃細分，個人和計劃之間缺少一個橋梁。但是將計劃拆分到每天做什么也不現(xiàn)實，所以，這里是一個工作的難點。執(zhí)行項目的人員之間水平有差異。?

任務的分解和委派

為了解決上述問題，初步有了以下方案：

1.每組安周一周作為單位指定落實到個人頭上的計劃，制定一份一周工作計劃表。2.一周工作計劃表每天檢查，如果出現(xiàn)了異常，隨時修改。3.周五大家根據(jù)一周的工作內(nèi)容，整理工作周報。這個方法是不錯。但是如果將工作分解到每天的粒度呢？

基本思路是將工作按照工作的流程，分解為『關鍵步驟』，每項任務的一項關鍵步驟，作為 一個人的工作任務，也是最小的管理單元。個人工作任務只有『完成』和『未完成』兩種狀 態(tài)。

檢查和調(diào)整

為了有效控制和掌握進度，檢查和調(diào)整是很重要的一個環(huán)節(jié)。每日記錄

每天下班前，可由相關人員自己在標記當日工作計劃的完成情況，有完成、延遲完成和延遲 中三種狀態(tài)，并進行匯總統(tǒng)計。并且可以提出自己的問題，由相關人員討論解決問題或者安 排時間專門討論。周例會

周例會檢查和調(diào)整項目計劃，需要一定的討論，討論的重點是：任務完成了嗎？沒完成的原 因是什么？怎么調(diào)整？

質量管理 管什么？

經(jīng)過多年的發(fā)展，質量管理已經(jīng)有了一套基本的理論和方法。質量管理包括質量保證和質量 控制兩大類。質量保證是指在項目過程中實施的有計劃、有系統(tǒng)的活動，確保滿足相關的標 準，典型的例子是評審和審計。質量控制是指采取適當?shù)姆椒ūO(jiān)控項目結果，確保結果符合 質量標準，典型的例子就是測試以及之后的缺陷跟蹤。

在IT行業(yè)軟件開發(fā)領域中，常見的公認的質量活動包括：配置管理、評審、測試以及缺陷跟 蹤。

? ? 評審：檢查項目中間產(chǎn)品，早期發(fā)現(xiàn)缺陷以減少后期項目返工和修改的工作量。

測試：直接檢測軟件產(chǎn)品中的缺陷，確保符合質量要求。一般通過單元測試、集成測試、系統(tǒng)測試和性能測試實現(xiàn)。

缺陷跟蹤：記錄和追蹤缺陷從發(fā)現(xiàn)到解決的整個過程，確保所有的結論都有結論。審計：對項目工作過程進行檢查，確保所有活動按照規(guī)程進行。變更控制：版本本更控制，也是重要的一環(huán)。

配置管理：記錄中間和最終產(chǎn)品（配置項）的變更歷史。質量經(jīng)理在項目中的職責如下： ? ? ? ? ? ? ? ? ? 貫徹公司的質量管理規(guī)范，負責質量管理過程中的檢查和指導。負責制定項目開發(fā)/測試環(huán)境的標準和規(guī)范。

負責項目的配置管理，通過權限控制和備份機制確保交付物的完備和安全。負責組織同行評審，確保中間交付物的質量。

制定測試策略和測試計劃，組織測試，確保最終交付成果的質量。

項目配置管理

項目配置管理是一項看不見的財富，可以在無形中減少因為版本意外等開發(fā)中出現(xiàn)的問題導 致的返工、重做等資源浪費。Q: 什么是項目配置管理？

配置管理是在某一特定時點，確定軟件配置的一個過程，通過對已標識的軟件配置的一個過 程，通過對已表示的軟件的配置的變更進行系統(tǒng)控制，從而在整個軟件生命周期中保持軟件 的整體性和可追溯性。Q: 配置管理的具體要做什么？

通常來說，軟件配置管理主要通過計劃、標識和控制變更和發(fā)布配置狀態(tài)報告來協(xié)調(diào)軟件開 發(fā)，目的是使錯誤率達到最小并最有效地提高生產(chǎn)效率。

質量評審

評審的目的是盡早發(fā)現(xiàn)問題，一團和氣的評審會完全達不到發(fā)現(xiàn)問題的目的。Q: 評審中的角色有哪些？

首先要把評審中設計到的各個人員確認下來。評審過程中涉及的角色主要有四種：責任人、主審人、評審專家和記錄員。

主審人要先選定評審組的成員，然后再做評審的前期準備。在 評審過程中保證規(guī)范和高效，評審結束后要將結果及時發(fā)布被評審相關人員。最后，還要對 評審中發(fā)現(xiàn)的問題追蹤，直 到問題關閉。

責任人就是要被評審的對象。他們在評審之前準備好資料，在評審過程中解答提出的問題。對于發(fā)現(xiàn)的問題要積極修正后提交給主審人。

記錄員就是在評審過程中，把專家提出的問題都記錄下來，還要記錄責任人的回答信息，最 終要行程會議紀要，并且記錄評審結果。

評審專家要徹底了解被評審的資料，其任務是尋找這些資料中的缺陷，側重于發(fā)現(xiàn)問題而不 是解決問題。要保持客觀。Q: 評審的過程是什么？

評審的過程分為計劃、預備會議、準備、評審會議和追蹤幾個階段。

? 計劃階段與項目計劃同步，也就是說項目中有哪些要評審在項目計劃中就已經(jīng)提前定義好 了。

預備會議，針對要評審的資料對評審組進行培訓，并討論評審資料。準備工作，是評審專家要徹底熟悉評審資料，以保證評審的質量和高效。評審會議，是主審人和評審專家對項目資料中的錯誤和缺陷進行確認。跟蹤，主審人要確保責任人采取必要的措施修正發(fā)現(xiàn)的錯誤。一個評審反饋表如下： ? ? ? ?

讓測試深入人心

保證質量最有效的措施就是測試。Q: 為什么要有多種測試呢？

不同的測試是針對不同的開發(fā)活動來設置的。下面是軟件測試的一個『V模型』：

? 單元測試，主要是開發(fā)人員對編寫的代碼進行自測或相互進行交叉測試，用以檢查代碼是 否符合編碼規(guī)范，是否存在邏輯錯誤。

集成測試，將經(jīng)過單元測試的模塊組裝成完整的程序。工作任務包括制定集成測試策略，確定集成測試步驟，設計集成測試用例，然后逐一添加模塊進行測試。

系統(tǒng)測試，是為了驗證需求分析確定的功能是否被正確的實現(xiàn)，同時還要對安裝、部署、適應性、安全性、界面等非功能性需求進行測試。

性能測試，用來測試系統(tǒng)是否滿足規(guī)定的性能需求。性能測試通常選擇一些典型的功能，檢驗這些功能在大量用戶同時使用時是否穩(wěn)定。

用戶驗收測試，目的是驗證需求與系統(tǒng)的匹配性，以及界面的友好性，響應時間等等。?

?

?

?

缺陷跟蹤

Q: 為什么要進行缺陷跟蹤？

缺陷跟蹤可以記錄測試結果，確定代碼質量，是確保問題得到解決的一個關鍵流程。其目的 是規(guī)范評審、測試、試運行等過程中發(fā)現(xiàn)缺陷的更改活動；跟蹤缺陷處理的各個環(huán)節(jié)、避免 缺陷修改失控和遺漏；如實的反映缺陷處理過程。Q: 怎么進行缺陷跟蹤？

缺陷跟蹤的起點是各種發(fā)現(xiàn)缺陷的活動，發(fā)現(xiàn)缺陷之后就進入了缺陷的跟蹤流程，包括提交、判斷、分發(fā)、修改、復核和關閉幾個關鍵步驟。

缺陷跟蹤除了記錄和跟蹤缺陷的修復過程，很重要的還有對缺陷進行分類、統(tǒng)計和分析。缺陷的類型一般分為一下幾種：

缺陷類型 描述 可能的缺陷來源 詳細設計

架構設計、概要設計 用戶界面 用戶界面顯示或者操作存在問題 架構 接口 系統(tǒng)存在架構方面問題

系統(tǒng)內(nèi)、外部接口錯誤，不能正常連接和工作 架構設計、概要設計

需求分析、需求規(guī)格 架構設計、概要設計 業(yè)務功能 業(yè)務功能不完善、未實現(xiàn)或者出現(xiàn)錯誤 系統(tǒng)功能 與業(yè)務無關，但是系統(tǒng)必須實現(xiàn)的功能不完整、未實現(xiàn)或者出現(xiàn)錯誤 性能 系統(tǒng)的響應時間、吞吐量、并發(fā)量等不滿足需架構設計、概要設計、求 編碼 缺陷類型 描述 可能的缺陷來源 概要設計、編碼 概要設計、詳細設計 可重用性 不滿足被其他系統(tǒng)或者模塊復用的要求 可移植性 不滿足可跨平臺移植或者部署的要求

缺陷的嚴重性說明了缺陷給最終交付的系統(tǒng)或者產(chǎn)品可能造成的影響程度。其中A級影響程 度最大，E級最小。

嚴重性等級 描述

A級（系統(tǒng)級）系統(tǒng)整體崩潰，或者不能穩(wěn)定地連續(xù)工作

B級（應用級）部分應用或者子系統(tǒng)不能運行，或者不能穩(wěn)定地連續(xù)工作 C級（業(yè)務級）導致業(yè)務流程終止，或者因結果錯誤、數(shù)據(jù)不一致失??；因安全、容錯性和性能問題等非功能性問題影響使用 D級（操作級）不易于學習使用，界面操作困難；難以理解而不容易使用 E級（文檔級）安裝手冊、操作手冊、在線幫助等文檔不能提供幫助或者存在錯誤

第五篇：項目經(jīng)理經(jīng)驗

項目經(jīng)理經(jīng)驗總結

作為一個項目負責人，一定要明白這個工作最要緊的就是要明白什么是因地制宜、因勢利導；只有最合適的，沒有什么叫對的，什么叫錯的。項目負責人最忌諱的就是有完美主義傾向，尤其是從做技術人員出身的，喜歡尋找標準答案，耽誤了工作進度，也迷茫了自己。

項目前期階段是一個項目最重要的階段。項目負責人在接手一個新項目的時候，首先要盡可能地多從各個方面了解項目的情況，如：

1、這個項目是什么項目？具體大概做什么事情？是誰提出來的？目的是解決什么問題？

項目前期對工程情況了解的越詳細，工作做的越細致，后面的“驚訝”就越少，項目的風險就越??；

2、這個項目里牽涉哪些方面的人？如投資方、建設方、項目建成后的運營管理方、技術監(jiān)督方等等。

項目負責人需要了解每個方面的人對這個項目的看法和期望是什么。事先了解各個方面對這個項目的看法和期望，可以讓你在做項目碰到問題的時候，就每件事情具體分析哪些人會在什么方面支持你，哪些人會出于什么目的反對你，從而提前準備聯(lián)合朋友去對抗敵人，讓事情向你所希望的方向發(fā)展。

沒有永遠的朋友，也沒有永遠的敵人，只有一致的利益，這句話作為項目負責人是一定要記住的；

3、基本了解了客戶的情況后，下面的事情就是了解自己公司各方面對這個項目的看法。

首先是高層領導是否重視，這個決定了在你需要資金、人力等資源支持的時候，公司是否會根據(jù)你的要求提供最有力的支持。領導口頭肯定是說支持的，但你需要

做的是了解公司對這個項目的實際期望，是想把項目越做越大還是只想賺點錢？是想做樣板工程還是干脆想敷衍了事。

公司領導（尤其是高層領導）對項目的態(tài)度決定了你做這個項目的戰(zhàn)略目標，而這個戰(zhàn)略方針將對你做項目計劃產(chǎn)生直接的影響；

4、在做整體項目計劃前，還要大致計算一下你手上的資源。

首先是時間?，F(xiàn)在市場競爭非常激烈，有一些項目會要求在幾乎不可能完成的時間范圍里完成。對于這一點，你在做項目的風險控制計劃的時候要充分考慮。其次是人員。根據(jù)項目預算和已往經(jīng)驗，大致計算一下未來的項目小組有多少種角色，每個角色目前公司是否有人，是否能完全歸這個項目使用，是否需要另外招聘一些人員，招聘的準備工作要盡早啟動。

最后就是一些設備的準備。項目所需大件關鍵設備生產(chǎn)周期很長，所以要盡早訂貨，以后不管發(fā)生設備等人還是人等設備的情況，浪費的都是你的時間；

5、是到做總體計劃的時間了嗎？不，你現(xiàn)在已經(jīng)知道了客戶的目標和你手上的資源，那么做計劃以前，你還需要和你的領導和客戶充分溝通資源的問題。因為很多資源是還不明確的，你需要寫一份報告，詳細分析這個項目的風險以及對資源的需求情況。如果一些問題不能得到解決的話，將發(fā)生什么樣的后果。如果資源不夠，就要高層改變策略，增加對這個項目的投入。甚至在條件許可的情況下，有些公司會放棄這個項目?？傊瑳]有人能完成一個不可能完成的任務，如果項目負責人不能盡早發(fā)現(xiàn)風險，那么就只能去當烈士了。

6、明白了要做哪些事情和你手上的籌碼以及你做這個項目的總體策略，現(xiàn)在是成立項目小組的時候了。

很多項目負責人都沒有自己選擇組員的權利，那么，就盡量發(fā)揮你的影響力去尋找那些你想要的人吧。成員的組成根據(jù)項目不同，相差較大，很難有什么具體要求，7、現(xiàn)在你要面對三群人：你的領導、你的組員和你的客戶，和這些人溝通，讓他們知道你打算怎么做，什么時候要他們做什么準備這些事情將是你的主要工作

8、好了，做了很多前期工作，定義了一些游戲規(guī)則，現(xiàn)在是坐下來做計劃的時候了。

這一節(jié)，任意找一本項目管理的書都會說得比我好，所以我就少寫一點，說一些自己的體會就是了。首先是找?guī)讉€關鍵組員，比如給排水專業(yè)工程師、暖通專業(yè)工程師、電氣專業(yè)工程師、土建專業(yè)工程師、資料員等等，研究一下如何來完成這個項目，比如項目可以分成幾個單項工程？每個單項工程又可分為幾個重要的工程節(jié)點。這里要強調(diào)一點：完成一個目標有很多種方式，你要選一種你最熟悉的，而不是看上去最完美的，這個思路會讓你的項目減少很多風險。有時候客戶會被某種新技術打動，堅持要你采用那種新技術，你就應該告訴他：你選我做這個項目，就應該容許我采用自己最喜歡的方式做事情，新技術之所以有誘惑力，就是因為吃虧的人還不多，我不希望你成為第一批受害者。

采用一個計劃會讓你的工作更加明確，比如用微軟的Project軟件，你填寫完表格以后，就可以知道這個項目有多少件事情要做，每件事情需要什么資源，他們之間的前后關系如何，消耗的時間有多長，完成后有什么標志等。所有的結果最后用一個叫做甘特圖的形式表現(xiàn)出來。你做完這個表以后會驚奇地發(fā)現(xiàn)，甘特圖上項目的結束時間會遠遠落后于你的計劃結束時間（簽合同的人永遠不會先征求你的意見的）。當然，學過項目管理的人會大談什么WBS、優(yōu)化路徑之類的東西，但是我的經(jīng)驗是你再優(yōu)化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題，在我恭喜你挑了一個輕松活之前，請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候，你就要考慮犧牲一些任務的時間（也意味著質量）了。按照什么標準犧牲？這個項目的戰(zhàn)略！我們在第三節(jié)提到過的戰(zhàn)略。我的經(jīng)驗是如果你什么都趕進度，其結果可能就是十件事情你一件也沒做好，想想多么失敗啊。所以，把資源投到你熟悉和有把握的事情上，最后的結果是十件事情，你有三件做成了精品，三件完成，還有四件因為某些原因延誤，成績單是否靚麗了很多呢？戰(zhàn)略決定優(yōu)先級，而正確排列事情的優(yōu)先級是一個項目負責人能力的主要體現(xiàn)。

好，現(xiàn)在項目已經(jīng)完成了前期工作，了解了項目的目標、搞清楚了手上的資源，制定了項目的策略，然后編制了項目的整體計劃，項目進入實施階段。進入這個階段反而是項目負責人比較空閑的時候，不像前期的時候項目負責人要象記者一樣到處和不同的人接觸，搞清楚他們在說什么，努力猜測他們在想什么和他們的真正目的，那才是最累人的事情。當然，小項目的項目負責人往往自己也是一個資源，要做很多事情，這時候反而比誰都苦。項目負責人這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領導溝通時特別要注意，除非你需要對方給你支持，那么你才需要講得具體一點，否則，告訴他一切正常就可以了，而且態(tài)度要積極一些，千萬不要說一些領導不懂的細節(jié)，比如：“王經(jīng)理，最近項目進度還算正常，就是經(jīng)常發(fā)生一些成品損壞的情況??”。和自己的領導匯報也要注意這個問題，除非他是一個技術高手，你需要他的技術經(jīng)驗，否則一般就匯報進度是否正常以及有問題時你的對策和打算就可以了，有些需要他支持的地方，比如資源調(diào)用需要說詳細一點。

和項目組員開會，除了一些項目進度跟蹤會議以外，還有很多討論會，需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員，他們的特點是注重細節(jié)、缺乏大局觀、有點消極悲觀、自尊心強（如果總結得不對，歡迎大家拍磚），所以，你作為會議的主持人，只要負責提出問題和記錄下他們的觀點，千萬不要做評判者的角色。一個問題，有很多方面，從不同的角度看，現(xiàn)象是完全不同的，想想盲人摸象的故事吧。這些技術人員，他們往往精通一個方面，就自己的角度發(fā)表見解，除非一些很特別的情況，你都應該認為，他們提出的方案，從他們的角度來看是最合理的。你的長處是掌握事情的優(yōu)先級，評估各個方面的輕重緩急，從而根據(jù)他們的意見得出一個合適的（而不是正確的）方案。所以，在會議上，你要充分尊重每一個人和他的意見，夸獎那些意見提得比較好的人，千萬不要把會議帶入無休止的爭論（你要讓大家知道事情不是非黑即白的，而是多元的，唉，我們的教育惹的禍?）。會后，你自己寫文檔，做決定。會議上大家的面子都被照顧了，自然實施起來的阻力就小，如果還有意見的，你就私下找他聊，如果還不能說服他，你就要讓他明白，因為你負責這個項目、你擔當風險，所以，這個優(yōu)先級應該你來判斷。組織中的高層，并不見得水平會比一般的成員高，但是，他要承擔組織的風險，加之信息的不對稱性，所以，對事情的優(yōu)先級的判斷肯定比下屬強。

在施工過程中，內(nèi)部管理還要注意的一點是時刻強調(diào)以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，時刻考慮如何檢查結果、如何向客戶交付是項目負責人一直要注意的事情，我聽說有些老項目負責人拿到項目是倒排計劃的，即首先看如何驗收和驗收標準，然后決定工作計劃。很多項目開始了很久，還不知道如何驗收，那么這個項目出問題的可能性就很大了。做項目就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那么多勞動后得到結果。對于需求天天變的客戶，你就一定要事先做好規(guī)矩：

a）統(tǒng)一聯(lián)系人:建設方指定一個人和項目組進行溝通，不能張領導、王領導都來說幾句，如果他們意見不一致，那你只有得罪領導的選擇了，所以，項目的最初就要定好規(guī)矩，我項目組只認一個的意見，有什么要求你們內(nèi)部先統(tǒng)一再和我談，我不想卷入你們內(nèi)部部門之間的矛盾之中；

b）所有工程量、施工工藝、材料、工期等變更全部要有書面簽字認證，這點切記！這樣做好處多多。

對于客戶來說，嘴巴一動最方便，一會要求這樣做、一會要求那樣做，反正是你們做。這時你一定要留下書面文件并簽字蓋章，只有拿到了書面文件，在工程結算時才能拿回自己應得的那部分錢，否則的話客戶口頭許諾的許多變更費用你是一分也要不回來的；