1、高品質文檔2022年it項目管理心得 項目開發方面 項目應以需求為核心。一個項目是否能夠勝利，對需求的精確把握在勝利因素中要占上60%的比例。不管系統的架構設計、團隊管理有多么的勝利，假如需求消失偏差，仍舊是南轅北轍。由于eas項目的特別性，項目開發過程中能夠與客戶建立有效快速的溝通渠道，是項目勝利的關鍵。 需求必需獲得客戶的確認。通過需求調研與分析后獲得的用戶需求說明書，以及軟件需求規格說明書都必需得到客戶的簽字確認。確認的內容包括項目的目標、范圍以及項目需求功能點（用例）。eas項目在前期對需求不夠重視，導致在需求理解上消失了一些偏差，從而影響了項目的進度。幸而得到了準時的訂正，在項目管理

2、部的幫助下，全部需求都得了客戶或客戶代表的簽字確認。從而使得項目在客戶驗收時，有了充分的保證。 項目應確立特地的需求分析師。公司沒有特地的需求分析師，不能不說是人員配備上的一大弊端。（軟件開放工作細分的第一步就是要有特地的系統分析員或需求分析師）從eas項目的開發過程中，我們就充分地熟悉到這一問題的嚴峻性。需求的不斷更改，客戶遲遲未簽字確認，緣由正是在于我們沒有特地的具有豐富閱歷的需求分析師。一般開發人員在調研需求以及撰寫需求規格說明書時，總是會消失偏差或理解錯誤的地方。軟件需求分析是一項重要且負責的技術，沒有經過特地訓練的需求分析師，通常會給項目帶來隱患。 項目應指定各個模塊的需求接口人。只

3、有這樣，才能有效地保證項目組與客戶的準時溝通，快速響應客戶的懇求與反饋。eas項目在開發早期準時地確立了需求接口人，在肯定程度上規避了需求變更給項目帶來的風險。但是，確立的需求接口人未經過系統培訓，在需求調研以及與客戶溝通的過程中，工作表現只能說是差強人意。 留意維護需求調研記錄以及需求跟蹤表。這一工作做得不夠好。由于需求調研人不夠專業，而項目經理以及需求分析負責人對這一過程還欠缺足夠的重視，同時沒有好的工具或流程來監控這一過程，使得需求調研記錄沒有發揮更大的作用。此外，需求跟蹤也特別重要，究竟，任何項目的需求都不是固定不變的，需求隨時會發生變更，而開發人員實現的需求也可能會與客戶的要求偏差。

4、 留意維護需求矩陣。項目經理對這一內容缺乏足夠的重視與理解，項目開發過程體系中也缺乏好的需求矩陣文檔模板。但是在項目中后期，項目準時撰寫了eas項目需求功能列表，并結合交付版本與客戶進行了溝通和協商，從而規避了需求偏差的風險。(需求追蹤，任何原始需求來有頭就有尾。原始需求-用戶需求-產品需求-軟件需求-設計-測試等一系列的追蹤。需求追蹤的目的一方面是檢查需求是否都已經實現有無遺漏，更多的是為了做變更影響分析使用) 掌握需求變更。重視ccb的作用，同時應建立需求變更的響應機制。eas項目組對于需求變更的響應還不夠準時，這一點項目經理與項目管理小組要擔負肯定的責任。（范圍管理中范圍掌握的內容，變更

5、管理是配置管理的一個重要內容。需求必需要受到掌握，否則簡單引起方案的頻繁調整而發生混亂) 設計 重視架構設計。eas項目的勝利，肯定程度是源于我們有個優秀的框架開發小組，我們在項目立項之初就基本確定了整個系統的架構。其中雖然發生了一些變化，但核心架構仍舊沒有發生大的變化。由于，我們建立了穩定、簡潔的系統框架，可以極大地提高開發效率，規避了對框架的重復編碼。(軟件開發的第二個重要分工就是最好有特地的架構設計人員，架構設計和總體設計要由1-2個人來完成，以保證高度的概念完整性和設計統一) 擅長對設計作出取舍。項目開發的三要素是成本、質量與進度。在保證質量的前提下，為了項目進度不消失大的偏差，eas

6、項目組并沒有過分強調技術，特殊是在考慮進度的狀況下，犧牲了系統的部分可擴展性。雖然這為系統的后期維護帶來肯定隱患，但卻能夠有效地保證項目的進度。從eas最初的架構設計來看，我們引入了 castle與aop，試圖簡化orm以及橫切關注點例如日志、特別、權限、事務等功能的實現。同時，盼望采納wcf，利用soa思想建立松散耦合的面對服務應用程序。但隨著客戶需求的變化，我們堅決地放棄了采納wcf的構想，同時又克服了技術困難，堅持了對castle與aop的使用，并為此成立了框架開發小組。事實證明，在技術的選擇上我們作出了正確的打算。 重視ui原型設計。系統的原型設計與需求分析相輔相成。假如有好的原型版本

7、交付給客戶，則客戶更能夠理解系統的實現，促進溝通的有效性與精確性。在eas項目中，我們從一開頭就確立了原型設計小組，并在分析需求階段，就開頭了原型設計。這一做法無疑在客戶溝通、需求確認、ui設計等方面都發揮了很大的作用。但是，我們在這一點上，由于缺乏特地的ui設計人員，因此，這一工作還存在很大的缺陷，甚至于ui的設計為迭代版本的交付帶來了很大的障礙。在項目后期，關于ui的bug是最多。因此，我們認為在開發類似的web應用程序時，應盡早確立ui設計規范，以約束全部的ui設計。同時，必需培育特地的ui設計師，在開頭原型設計時，就盡快完成ui交互的設計。并且，必需成立特地的ui 設計小組，在需求階段

8、與需求分析師合作，在編碼階段與開發人員合作。(原型設計是加強前期用戶需求挖掘和削減后期需求變更的重要手段，不肯定需要特地的ui設計人員，原型設計可以由需求分析師來完成) 測試 測試成員應了解需求。假如不了解需求，測試人員無法編寫正確的測試用例，同時在測試過程中，也可能因為錯誤地理解需求，從而導致報告錯誤的bug，影響開發人員效率。加強開發人員與測試人員的合作。開發人員必需準時響應測試人員提交的bug。而測試人員也應跟蹤開發人員對bug的修復狀況。(測試人員應當要意識到自己和需求分析人員的區分，測試人員不用想需求分析人員一樣分析和開發業務，但是他們必需和需求分析人員一樣對已經分析出來的需求和業務

9、高度熟識) 測試之初必需確定測試原則，對bug的嚴峻程度進行分級。同時，必需確定修復bug的優先級別。 進度管理 保證項目進度不消失大的偏差的前提是制定一個好的項目方案。必需依據項目規模，成員狀況，技術難度等多方面考慮整個項目方案。假如項目的deadline已經確定，則必需采納一些方法來保障項目方案的完成。首先是選擇符合項目的軟件開發生命周期。通常狀況下，并不建議采納瀑布開發方式。最佳的方法，應當是 rup或者靈敏開發，然后結合原型法制訂項目方案。這樣可以規避因為需求變更產生的風險。 其次，要每日跟蹤項目的進展狀況。可以通過晨會、周會以及項目日報、項目周報了解項目進展狀況。同時，需要為各個小組

10、指定進度跟蹤人，依據各個小組長的日報，推斷實際的進度是否與方案消失偏差。 要制定項目進度偏差的應對方法。一旦項目進度消失了偏差，必需實行相應錯誤會決問題。或者通過加班、增加人手、申請項目進度等方法準時作出響應。 準時向項目成員匯報項目進度狀況。只有讓各個項目成員了解到項目現狀，才能夠給每個成員增加壓力，不至于松懈。同時，也能夠使得每個成員能有一個目標，而不至于茫然失措。 制定項目方案時，必需考慮階段評審與同行評審的時間。這一點在eas項目中做得不夠好。其中緣由也是由于項目進度本身較緊的原因。留意維護項目進度跟蹤表與項目進度偏差跟蹤表。讓項目管理部以及qa準時把握項目進度，有利于對項目進度的管理

11、。 變更管理 變更包括需求變更、人員變更。假如不掌握好，兩者對項目的進展都會帶來災難性的后果。需求變更在前面已經敘述，而eas項目中發覺人員變更的狀況也特別嚴峻，因此這里重點介紹關于人員變更的管理。 假如發生人員進入的狀況，那么對項目帶來的通常都會是好的影響。但我們也必需留意如何讓新成員更快地融入團隊。整體上講，假如需要新成員加入，發生變更的最佳時機是項目前期。假如在項目中后期加入新成員，無疑則意味著項目消失了災難性的后果。而新增加的成員，由于不熟識項目，所能帶來好的影響也是有限的。假如不處理好新成員與老成員之間的合作關系，反而會帶來負面影響。 人員的退出許多時候是不行控的，同時對項目帶來的影

12、響也是不行估量的。為了將這些影響降到最低，就必需在項目開頭之初就要確立編碼規范。同時，還應當重視對文檔的維護與更新。而在人員退出時，必需做好交接工作。同時，還應對這種變更進行合理的評估，并準時報告項目管理部，并與客戶準時溝通。假如對項目進度有嚴峻影響，應爭取最大的努力取得客戶的理解，提出項目延期的申請。 風險管理 要在項目開頭之初就考慮到項目過程中可能消失的全部風險，是不現實的。但是，我們必需考慮對風險的管理，尤其是在制訂項目方案以及創建團隊的時候，考慮這一因素。風險有許多，包括需求的風險、進度的風險、質量的風險以及技術風險等。必需制定一套完整的風險管理方案，而一旦發生了風險，則必需準時響應，

13、組織相關人員解決風險。不能忽視任何一個小的風險，否則一個小的風險到最終會造成大的災難。風險的把握必需要有項目經理與系統架構師把關。 成員管理 不團結的項目組是無法保證項目的勝利地。項目經理與項目組長在管理團隊成員時，必需時刻留意成員狀況，即使處理工作消失的沖突與摩擦，隨時保證團隊合作精神得到最大程度的執行。 持續地保證項目成員的士氣特別重要。項目每取得一個階段性的進展，必需告知全體成員，如此才能收獲勝利的信念。項目開發過程需要留意勞逸結合。一味地強制性加班，只能降低項目成員的工作效率。項目過程中，如能適當地開展一些活動，無疑能夠讓團隊成員感受到項目組的集體氣氛。在階段實現的重要時刻，項目經理必需留意通過文字、語言等激勵項目組成員。而項目經理的自信也是保證成員士氣的一個關鍵。 必需留意了解團隊成員的心理狀態與工作狀態。項目成員的戰斗力除了是個人的力量發揮之外，一個好的領導也是至關重要的。因此，必需選擇合適的項目組長，通過他們把握整個項目團隊成員的工作進展。同時，還要了解每個成員的力量，以支配合適的角色