it項目管理心得
善于對設計作出取舍。項目開發的三要素是成本、質量與進度。在保證質量的前提下，為了項目進度不出現大的偏差，eas項目組并沒有過分強調技術，特別是在考慮進度的情況下，犧牲了系統的部分可擴展性。雖然這為系統的后期維護帶來一定隱患，但卻能夠有效地保證項目的進度。從eas最初的架構設計來看，我們引入了 castle與aop，試圖簡化orm以及橫切關注點例如日志、異常、權限、事務等功能的實現。同時，希望采用wcf，利用soa思想建立松散耦合的面向服務應用程序。但隨著客戶需求的變化，我們果斷地放棄了采用wcf的構想，同時又克服了技術困難，堅持了對castle與aop的使用，并為此成立了框架開發小組。事實證明，在技術的抉擇上我們作出了正確的決定。
重視ui原型設計。系統的原型設計與需求分析相輔相成。如果有好的原型版本交付給客戶，則客戶更能夠理解系統的實現，促進溝通的有效性與準確性。在eas項目中，我們從一開始就確立了原型設計小組，并在分析需求階段，就開始了原型設計。這一做法無疑在客戶溝通、需求確認、ui設計等方面都發揮了很大的作用。但是，我們在這一點上，由于缺乏專門的ui設計人員，因此，這一工作還存在很大的缺陷，甚至于ui的設計為迭代版本的交付帶來了很大的障礙。在項目后期，關于ui的bug是最多。因此，我們認為在開發類似的web應用程序時，應盡早確立ui設計規范，以約束所有的ui設計。同時，必須培養專門的ui設計師，在開始原型設計時，就盡快完成ui交互的設計。并且，必須成立專門的ui 設計小組，在需求階段與需求分析師合作，在編碼階段與開發人員合作。(原型設計是加強前期用戶需求挖掘和減少后期需求變更的重要手段，不一定需要專門的ui設計人員，原型設計可以由需求分析師來完成)
測試
測試成員應了解需求。如果不了解需求，測試人員無法編寫正確的測試用例，同時在測試過程中，也可能因為錯誤地理解需求，從而導致報告錯誤的bug，影響開發人員效率。加強開發人員與測試人員的合作。開發人員必須及時響應測試人員提交的bug。而測試人員也應跟蹤開發人員對bug的修復情況。(測試人員應該要意識到自己和需求分析人員的區別，測試人員不用想需求分析人員一樣分析和開發業務，但是他們必須和需求分析人員一樣對已經分析出來的需求和業務高度熟悉)
測試之初必須確定測試原則，對bug的嚴重程度進行分級。同時，必須確定修復bug的優先級別。
進度管理
保證項目進度不出現大的偏差的前提是制定一個好的項目計劃。必須根據項目規模，成員情況，技術難度等多方面考慮整個項目計劃。如果項目的deadline已經確定，則必須采用一些方法來保障項目計劃的完成。首先是選擇符合項目的軟件開發生命周期。通常情況下，并不建議采用瀑布開發方式。最佳的辦法，應該是 rup或者敏捷開發，然后結合原型法制訂項目計劃。這樣可以規避因為需求變更產生的風險。
其次，要每日跟蹤項目的進展情況。可以通過晨會、周會以及項目日報、項目周報了解項目進展情況。同時，需要為各個小組指定進度跟蹤人，根據各個小組長的日報，判斷實際的進度是否與計劃出現偏差。
要制定項目進度偏差的應對方法。一旦項目進度出現了偏差，必須采取相應錯誤解決問題。或者通過加班、增加人手、申請項目進度等方法及時作出響應。