本站小編為你精心整理了3篇《軟件項目經理工作總結》的範文，但願對你的工作學習帶來幫助，希望你能喜歡！當然你還可以在本站搜索到更多與《軟件項目經理工作總結》相關的範文。
本人做項目經理工作多年，感到做這個工作最要緊的就是要明白什麼是因地制宜、因勢利導，只有最合適的，沒有什麼叫對的，什麼叫錯的，項目經理最忌諱的就是完美主義傾向，尤其是做技術人員出身的，喜歡尋找標準答案，耽誤了工作進度，也迷茫了自己。以下是本人一些做項目的個人體會，寫出來供大家指點，在討論過程中共同提高水平。
項目開始階段是一個最重要的階段。項目經理在接手一個新項目的時候，首先要儘可能地多從各個方面瞭解項目的情況，如： 1.這個項目是什麼項目，具體大概做什麼事情，是誰提出來的，目的是解決什麼問題。在國內很多客户都很不成熟的情況下，千萬不要根據項目的名稱望文生義地去想象項目的目標。一個名為“辦公自動化”的項目很有可能在你進場以後一個月才發現客户其實需要的是一個計算機生產管理輔助信息系統系統。前期瞭解情況的工作越詳細，後面的驚訝就越少，項目的風險就越小。
2.這個項目裏牽涉哪些方面的人，如投資方、具體業務干係方、項目建成後的運營方、技術監督方等等，很多項目裏除了業主單位的結構很複雜以外，還有一些其他單位也會牽涉進來，如項目監理公司、業主的行業主管機構等。項目經理需要了解每個方面的人對這個項目的看法和期望是什麼。事先了解各個方面的看法和期望，可以讓你在做項目碰到問題的時候，就每件事情分析哪些人會在什麼方面支持你，哪些人會出於什麼目的反對你，從而提前準備聯合朋友去對抗敵人，讓事情向你所希望的方向發展。沒有永遠的朋友，也沒有永遠的敵人，只有一致的利益，這句話作為項目經理是一定要記住的；
3.基本瞭解了客户的情況後，下面的事情就是了解自己公司各方面對這個項目的看法。首先是高層領導是否重視，這個決定了你在需要資源的時候，公司是否會根據你的要求提供最有力的支持。領導口頭肯定是説支持的，你需要做的是瞭解公司對這個項目的實際期望，是想把項目越做越大還是想賺錢？是想做樣板工程還是乾脆想敷衍了事，公司領導對項目的態度決定了你做這個項目的戰略，而這個戰略方針將對你做項目計劃產生直接的影響；
4.在做整體項目計劃前，還要大致計算一下你手上的資源。首先是時間，現在市場競爭激烈，往往很多項目要求在幾乎不可能的時間範圍裏完成。對於這一點，你在做項目的風險控制計劃的時候要充分考慮。其次是人員，根據項目預算和已往經驗，大致計算一下未來的項目小組有多少種角色，每個角色目前公司是否有人，是否能完全歸這個項目使用，是否需要另外招聘一些人員，招聘的準備工作要儘早啟動。最後就是一些設備的準備，項目所需大件關鍵設備要儘早預定，以後不管發生設備等人還是人等設備的情況，浪費的都是你的時間；
5.現在是做項目説明書的時候了。一份好的項目説明書不僅將要做的事情描述得很清楚（主要是講做什麼，而不是説怎麼做），而且把如何檢查也説明得很透徹。也就是説它不僅説明白了要做哪些事情，也讓客户的業務人員（一般不懂技術）知道項目做成什麼樣就算完成了。簡單地説，項目説明書描述項目做哪些事情和每件事情做到什麼程度以及如何檢查每一個結果。
6. 是到做總體計劃的時間了嗎？不，你現在已經知道了客户的目標和你手上的資源，那麼做計劃以前，你還需要和你的經理和客户充分溝通資源的問題。因為很多資源是還不明確的，你需要寫一份報告，詳細分析這個項目的風險以及對資源的需求情況。如果一些問題不能得到解決的話，將發生什麼樣的後果。如果資源不夠，就要高層改變策略，增加對這個項目的投入。甚至在條件許可的情況下，有些公司會放棄這個項目。總之，沒有人能完成一個不可能完成的任務，
如果項目經理不能儘早發現風險，那麼就只能去當烈士了。
7.明白了要做哪些事情和你手上的籌碼以及你做這個項目的總體策略，現在是成立項目小組的時候了。很多項目經理都沒有自己選擇組員的權利，那麼，就儘量發揮你的影響力去尋找那些你想要的人吧。成員的組成根據項目不同，相差較大，很難有什麼具體要求，但是，一定要有精通客户業務的人，很多小項目裏，這個人就是項目經理本人，大項目裏會配備行業專家（Industry expert），這樣和客户溝通起來才不會雞同鴨講，雙方才可以相互理解。我經常看到的情況是我們的技術人員和客户交談時滿口的專業術語，結果搞得客户一頭霧水，反過來，他還指責客户不懂技術。其實，明白自己想做什麼的客户已經是很好的客户了，不知道自己要做什麼，更不懂怎麼做還要指手畫腳的客户到處存在，但是要明白，是客户選擇了你，而不是你選擇了客户，有了客户你才有工資拿，心平氣和一點吧。
8.現在你要面對三羣人：你的領導、你的組員和你的客户，和這些人溝通，讓他們知道你打算怎麼做，什麼時候要他們做什麼準備這些事情將是你的主要工作。既然溝通這麼重要，那些事先定義一下溝通的原則也是一件很要緊的事情。很多溝通原則都是潛規則，如果你在一個部門時間做長了，對這些規則的運用覺得是一件理所應當的事情，但是，你現在面對的是多個部門甚至多個單位，不把溝通規則説清楚，你以後就會吃虧。下面的東西看起來無聊，其實還是很管用的：第一個是規定信息的流動方式和介質，是推還是拉。推的意思就是項目經理將主動發佈信息，不管通過電話、郵件還是書面方式，保證將信息傳達到每個人。這種情況適合小項目，人少；拉的意思就是項目經理就是一個類似web服務器，你自己需要什麼信息就去問他。當然，沒有項目經理把自己搞得那麼累，他會用發佈信息到公共介質的方式公佈信息，簡單的是白板，複雜一點的是項目的公共信息交互區，潛規則就是我發了你沒去看就不要説我沒告訴你。説這些看似很無聊，其實裏面牽涉信息傳達不完全的責任問題。當然，這些都是指一般的方式，而且不要絕對化，一般情況下，主動溝通和被動訪問是同時存在的，尤其是對領導，項目經理更加應該主動去和領導溝通。第二個問題就是文檔問題，很多人怕寫文檔，但是項目經理一定要牢記“好記性不如爛筆頭”的道理。有理有時候為什麼會説不清呢？就是因為沒有證據。所以項目經理開始就要和客户説清楚有些文檔是必須簽字的，比如項目經理的項目日誌，每個星期至少讓客户簽字，另外所有達成共識的東西，比如會議紀要，甚至領導的講話記錄，都要寫成文檔，雙方簽字，這樣以後扯皮的時候，就能做到有據可查。記住：説了的就和沒説一樣，只有寫下來大家簽字後才算真正發生了的。還有一些問題，比如你提交的報告，給領導（包括本方領導和客户領導）做一個選擇題，結果領導壓住不批，讓你無所適從，結果拖延了進度。這時候，你可以等，但是注意要留記錄，標明是誰的責任；另外，如果你在開始階段就和領導商定：如果批示提交三天後沒有得到領導答覆就算對方同意，這樣你就會主動很多。再比如不同事件的審批流程問題：什麼等級的事情記錄在項目日誌裏、什麼等級的事情要雙方項目經理專門簽署備忘錄、什麼等級的事情要雙方領導出面簽署合同附件等等。事先想得越周到，以後的工作就越主動。
9. 好了，做了很多前期工作，定義了一些遊戲規則，現在是坐下來做計劃的時候了。這一節，任意找一本項目管理的書都會説得比我好，所以我就少寫一點，説一些自己的體會就是了。首先是找幾個關鍵組員，比如客户業務專家、系統分析員等等，做一下項目模塊劃分工作。項目分成幾塊去做，每一塊完成什麼，
模塊之間的信息如何交換等等。需求定義的是做什麼的問題，而這裏説的是怎麼做的問題。這裏要強調一點：完成一個目標有很多種方式，你要選一種你最熟悉的，而不是看上去最完美的，這個思路會讓你的項目減少很多風險。有時候客户會被某種新技術打動，堅持要你採用那種新技術，你就應該告訴他：你選我做這個項目，就應該容許我採用自己最喜歡的方式做事情，新技術之所以有誘惑力，就是因為吃虧的人還不多，我不希望你成為第一批受害者。採用一個計劃會讓你的工作更加明確，比如用微軟的Project軟件，你填寫完表格以後，就可以知道這個項目有多少件事情要做，每件事情需要什麼資源，他們之間的前後關係如何，消耗的時間有多長，完成後有什麼標誌等。所有的結果最後用一個叫做甘特圖的形式表現出來。你做完這個表以後會驚奇地發現，甘特圖上項目的結束時間會遠遠落後於你的計劃結束時間（籤合同的人永遠不會先徵求你的意見的）。當然，學過項目管理的人會大談什麼WBS、優化路徑之類的東西，但是我的經驗是你再優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題，在我恭喜你挑了一個輕鬆活之前，請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候，你就要考慮犧牲一些任務的時間（也意味着質量）了。按照什麼標準犧牲？這個項目的戰略！我們在第三節提到過的戰略。我的經驗是如果你什麼都趕進度，其結果可能就是十件事情你一件也沒做好，想想多麼失敗啊。所以，把資源投到你熟悉和有把握的事情上，最後的結果是十件事情，你有三件做成了精品，三件完成，還有四件因為某些原因延誤，成績單是否靚麗了很多呢？戰略決定優先級，而正確排列事情的優先級是一個項目經理能力的主要體現。
好，現在項目已經完成了前期工作，瞭解了項目的目標、搞清楚了手上的資源，制定了項目的策略，然後編制了項目的整體計劃，項目進入實施階段。進入這個階段反而是項目經理比較空閒的時候，不像前期的時候項目經理要象記者一樣到處和不同的人接觸，搞清楚他們在説什麼，努力猜測他們在想什麼和他們的真正目的，那才是最累人的事情。當然，小項目的項目經理往往自己也是一個資源，要做很多事情，這時候反而比誰都苦。項目經理這段時間的主要工作是保持和客户領導以及自己領導的溝通。和客户領導溝通時特別要注意，除非你需要對方給你支持，那麼你才需要講得具體一點，否則，告訴他一切正常就可以了，而且態度要積極一些，千萬不要説一些領導不懂的細節，比如：“王局長，最近項目進度還算正常，就是JVM經常發生一些內存泄漏的情況”王局長：“(*&$@@”。和自己的領導彙報也要注意這個問題，除非他是一個技術高手，你需要他的技術經驗，否則一般就彙報進度是否正常以及有問題時你的對策和打算就可以了，有些需要他支持的地方，比如資源調用需要説詳細一點。
和組員開會，除了一些項目進度跟蹤會議以外，還有很多討論會，需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員，他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強（如果總結得不對，歡迎大家拍磚），所以，你作為會議的主持人，只要負責提出問題和記錄下他們的觀點，千萬不要做評判者的角色。一個問題，有很多方面，從不同的角度看，現象是完全不同的，想想盲人摸象的故事吧。這些技術人員，他們往往精通一個方面，就自己的角度發表見解，除非一些很特別的情況，你都應該認為，他們提出的方案，從他們的角度來看是最合理的。你的長處是掌握事情的優先級，評估各個方面的輕重緩急，從而根據他們的意見得出一個合適的（而不是正確的）方案。所以，在會議上，你要充分尊重每一個人和他的意見，誇獎那些意見提得比較好的人，千萬不要把
會議帶入無休止的爭論（你要讓大家知道事情不是非黑即白的，而是多元的，唉，我們的教育惹的禍）。會後，你自己寫文檔，做決定。會議上大家的面子都被照顧了，自然實施起來的阻力就小，如果還有意見的，你就私下找他聊，如果還不能説服他，你就要讓他明白，因為你負責這個項目、你擔當風險，所以，這個優先級應該你來判斷。組織中的高層，並不見得水平會比一般的成員高，但是，他要承擔組織的風險，加之信息的不對稱性，所以，對事情的優先級的判斷肯定比下屬強。
在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組佈置任務的時候就要考慮如何檢查結果，比如我見過一個計劃，裏面有一個任務【開發人員熟悉EJB編程】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客户交付是項目經理一直要注意的事情，我聽説有些老項目經理拿到項目是倒排計劃的，即首先看如何驗收和驗收標準，然後決定工作計劃。很多項目開始了很久，還不知道如何驗收，那麼這個項目出問題的可能性就很大了。做項目就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那麼多勞動後得到結果。另外我插一句：我是極其不主張到客户現場開發的。尤其是一大羣技術人員直接和客户交流，很容易引起衝突和矛盾（技術人員的本性決定的）。我的.做法是項目經理和項目實施人員到現場，軟件開發人員還是在公司做項目。項目實施人員就是初級項目經理，他們瞭解自己的產品，懂得一些客户的業務，關鍵是在於他們具有良好的溝通能力，俗稱“皮厚”。他們是客户和研發人員的橋樑，其職業方向也是很機動靈活，以後可以有很多方向可以轉，比開發人員的路要寬得多。
接着，我們再談談最讓人頭痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標，即需求變更；另一種是沒改變目標，但是客户不滿意目前的實現方式，大到流程的實現，小到界面的佈局，都是屬於這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客户隨着項目的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改並且你的戰略是容許這種情況的，那麼注意下面幾點：
1. 確保以前的文檔，就是記載着以前的結論的東西，客户是否簽過字，如果沒有，趕緊把你的工作停下來，趕快再和客户自己確認一下你的方案，然後讓他簽字，避免以後説話沒有憑據； 2.和客户坐下來，自己探討他修改的根本目的是什麼，是不是有同樣能達到相同目的，但是對你來説有代價更小的選擇？ 3.（項目初期的工作）明確更改流程，一般是客户指定一人簽字（否則客户每個領導都有權力來插一槓子，你就廢了），以正式項目文件的方式提交給你，然後，你做評估分析，分析對成本、進度的影響，在你的領導同意後，出相應意見書，主要是要説明更改設計的原因和指出由此帶來的不確定後果（這個東西先寫出來，後面如果真的發生了，至少不是你的錯）。然後再讓客户在上面簽字。見過醫院給病人做手術以前讓家人籤的免責條款嗎？對，就學習那個，讓大家都意識到任何的更改都有成本和代價 所以，對於這種需求天天變的客户，你就一定要事先做好規矩：
一、統一聯繫人，客户指定一個人和項目組進行溝通，不能張領導、王領導都來説幾句，如果他們意見不一致，那你只有得罪領導的選擇了，所以，項目的最初就要定好規矩，我項目組只認一個的意見，有什麼要求你們內部先統一
再和我談，我不想捲入你們內部業務部門之間的矛盾之中；
二、所有需求變更全部要有書面文字，這點切記！這樣做好處多多：
*有書面證據，以後他還想改，你有了他以前要求的證據，告訴他：你以前可是這麼説的；
*便於需求變更管理，需求如何慢慢演變的歷史可以看清楚，從而更深切地體會客户的目的；
*對於客户來説，嘴巴一動最方便，反正是你們做，不花他的資源，所以要求是否合理，是否和項目的目的一致，他是不負責任的。但是如果要他寫書面要求，還要簽字蓋章，他就要謹慎多了，而且一寫東西，思想就會更加深入，很多無理要求也就這樣胎死腹中了；
系統開發告一段落後，就進入客户培訓、系統驗收階段，這個階段，我一般會注意以下幾個問題：
給客户做培訓前，多注意一些表面功夫。很多程序員認為，既然很多系統採用原型法，有一個由粗到精的過程，那麼系統的邏輯核心是否正確才是關鍵，至於界面如何，界面上的用詞是否準確，那是無關緊要的問題；而且培訓的時候也是空手上台、信手拈來，想到哪裏説到哪裏，下面聽講的人不知所云，雲山霧罩，培訓效果自然可以想象。我的體會是，給客户做培訓的版本，如果你在做多次測試以後仍然不能確定邏輯是否合乎要求，那麼，你至少要在界面上多花一點功夫。注意每個界面的佈局、用詞、鏈接的正確性等等，總之不要讓客户看到一些他不該看到的東西，否則，僅僅因為一些無關緊要的報錯就讓客户第一印象覺得系統不穩定，那你就真的比竇娥還冤了。如果工作再做得詳細一點，可以做一些類似Flash的東西，把一些你要強調的重點用通俗易懂、輕鬆愉快的方式表達出來。文檔方面，準備至少兩個文檔：用户手冊和培訓手冊。這兩個文檔的內容很多都是一致的，但是角度完全不同。用户手冊往往是站在系統設計者的角度，按照自己的思路，分模塊講解系統的操作和功能；而培訓手冊，一定要站在客户業務人員的角度，根據每個角色面對不同業務的辦理，如何通過使用本系統的一系列功能來實現目標。所以，第一次培訓以前，系統界面是否完整正確、培訓文檔是否完備、培訓時所舉的例子是否有代表性都是很關鍵的因素，第一炮打不響，以後就麻煩很多。
上面講的是培訓的時候，醜媳婦要化粧好再去見公婆的問題。其實，項目實施中還有一個考驗項目經理功力的就是如何調動客户積極性的問題。一般來説，客户是懶的，這就是他花錢找你做事情的原因。一個項目的成敗，和客户的配合程度很有關係。根據我的分析，一般項目中的客户都可以分為三類：支持的、消極觀望的、牴觸的。他們人數的分佈一般是一個紡錘形：支持的和牴觸的人少，觀望的人多（如果你接了一個人人都牴觸你的項目，那你還是不要做了）。首先，分析一下那些人為什麼支持你和牴觸你。很簡單，於公於私兩個方面分析，上了新系統，誰的工作量有所變化？誰的潛在利益是否受到威脅？誰的崗位是不是因為新系統而消失？傳統的利益格局因為新系統的使用而發生怎麼樣的變化，這些東西，都是項目經理必須去了解的，這樣，你才能團結那些支持你的人，消減那些牴觸你的人。項目經理是一個很奇怪的角色，屬於典型的責任大、權力小的角色，他能做的只有借力打力，不管在自己公司還是在客户那裏，一定要依靠別人才能完成自己的目的。只有瞭解哪些人會因為什麼而幫助你，哪些人會因為什麼
時間飛逝，光陰如梭，晃眼20xx年就過去了。在不知不覺中，新年也過完了。只放了7天假，太短太短，還沒有休息夠。年度總結都還沒有開始寫，新年就過完了。好了下面言歸正傳，總結一下20xx年，這一年我都做了些什麼。
一、做了什麼
20xx年11月加入新公司，同時也嘗試着做全新的崗位：軟件項目經理(純管理型)。我以前主要從事技術管理工作，現在轉而從事項目經理工作。20xx年底進入公司後，公司給了我一個小項目A(用Java開發的MIS系統)，讓我先適應，這個項目是一個內部項目，業務比較簡單，也沒用什麼新技術，領導對我的指示就是讓我放手用敏捷開發Agile的方法去管理項目，就當是敏捷的試驗田來做。有了這話我也就放開了，大刀闊斧的就幹起來了。
之後接着就是我的“噩夢”了，公司新開發了一條產品線，是雲計算方面的。領導找我談話，讓我結束手上所有的案子，以後全心投入雲計算產品線中來。該產品線下面有許多的項目，目前正在運行的有四個項目，其中三個由我來負責，另外一個由我的一個同事負責。説是我的“噩夢”，其實也是對我的一個挑戰，因為雲計算的項目很偏技術，業務層面相對較少。所以對於我這個技術的門外漢來説是一個很大的挑戰。其次，雲計算的技術也比較前沿，待解決/未解決的問題也特別的多，在開發的過程當中會碰到很多的阻礙。再次，以前只帶一個項目，現在同時帶三個項目對於我來説也是一個挑戰。但是我也很高興能有這樣的一個機會，接受挑戰，沒有挑戰就不會有進步。
二、收穫
1.完成了我人生中一次大的轉型，從偏技術崗位成功轉型到偏管理崗位上來了。
2.參加了PMP的考試，並一次通過，取得了PMP證書。(複習真的很辛苦)
3.學習了公司規範的項目管理流程，結合PMP的學習，對同事們也混熟了，結交了不少朋友，非常感謝他們給我的幫忙和支持。
三、不足
1.項目雖然都跌跌闖闖的完成了，結案了。但是總覺得有很多的不足，可以改進的地方。項目結束的太匆忙，沒有太多時間去想，去總結經驗和堅持下來，斷斷續續，總是説沒有時間。
2.業餘時間沒有抓緊，太貪玩了。
3.來新公司1年多了，還沒有加薪，有點失望。
更多
一、全年工作情況
(一)明確任務、開拓創新，有計劃、有組織地抓好施工生產xx年對我們廣州工程處來説是極不平凡的一年，也是我歷年來在生產組織上最為困難的一年。由於受雨季時間長、施工作業面緊張、地方關係協調困難等諸多不利因素的影響，始終制約生產的全面展開。面對困難，我一面分析生產形勢，積極採取措施，協調好各方面的關係，充分挖掘和調動各方面潛力，千方百計保證了施工生產的順利進行，較為圓滿地完成了各項施工生產任務。
1、強化生產準備的充分性。針對工程項目點多面廣，戰線較長、施工難度大的實際情況，重點抓了施工前的組織準備、材料準備以及設備、施工機具準備，體現施工準備的充分性，爭取了主動。及時的組織技術、材料、預算等部門對施工方案進行敲定，明確了工期、質量、安全目標，為完成生產任務奠定了基礎。
2、強化生產組織的嚴密性。針對工程施工任務量較大，始終堅持生產例會制度，定措施，抓落實，提要求，解決實際問題，及時確定各機組每個階段的生產組織重點環節。多次組織召開現場協調會和專業辦公會，幫助機組科學合理地安排施工順序，研究和確定了施工方案和施工計劃，確保了各機組今年生產任務的完成。
3、強化生產計劃的嚴肅性。我主要抓了生產計劃的執行和考核，對生產會議確定的各項目階段性工期，加大了督查力度，並採取超常規措施，及時糾正偏差，確定整體目標和階段目標，明確主攻方向，突出重點，各個擊破，取得了明顯效果。
4、強化施工管理文明的有序性。在施工管理中主要狠抓了現場文明施工管理，要求按高起點、高標準、高水平運行，做到規範、整潔，對現場文明施工、樣板起步一抓到底。實踐證明：抓而不緊等於沒抓，抓而不實等於白抓。通過對現場管理的常抓不懈，各機組的施工現場均達到了文明施工標準，樹立了公司好的品牌與形象，受到了業主的普遍好評。
5、靠前指揮，及時解決問題。在施工季節，為了及時掌握各項目生產的第一手材料，並與項目部同事一起深入工地，靠前指揮、靠前指導、靠前協調、靠前服務，進一步加強監督和檢查的力度。提高了工作效率，有效地促進了各機組的施工進度。
(二)加強安全管理工作，做到生產無事故。
堅持“以人為本”的理念和“安全第一，預防為主”的基本方針，加強對施工現場的監督檢查力度，做到常抓不懈，警鐘常鳴;對施工人員、操作手、駕駛員加強了安全教育，強化了全員的安全意識;切實落實安全生產責任制，保證了昆大管線項目部安全管理工作的平穩運行。二、加強自身廉政建設，牢固樹立服務意識。
做為一名領導幹部，我深刻認識到廉潔奉公、勤政為民的重要性，常懷律己之心，增強自律意識，做到自重、自警、自勵，清正自守，不該拿的東西不拿，不該去的地方不去，不該做的事情不做，保持一名共產黨員清正廉潔的本色。
三、總結經驗，加強學習，努力做合格的生產管理者
為了適應新形勢、新任務、新工作的要求，主動加強業務知識和理論的學習，不斷豐富提高自身的知識儲備和層次。並以黨員先進性教育活動為契機，進一步理解了新時期保持共產黨員先進性的基本要求，在政治、思想、作風等方面有了較大收穫。同時，我還能夠從其他領導同志身長汲取優點和長處，彌補自身不足，努力做企業合格的管理者。
四、存在的不足
一年來，雖然圍繞自身工作職責和年初確定的工作目標做了一定的努力，取得了一定的成效，但與領導的要求和羣眾的期望相比還存在一些問題和差距，主要是：
1、有時因工作忙，政治理論學習還不夠自覺，業務水平還需進一步提高;
2、由於在心理上總是想把工作幹得出色，把項目部的生產組織得更好。特別是今年生產任務繁重，感覺壓力大、擔子重，造成工作中比較急躁，工作方法有待進一步改進，領導水平和領導藝術還需加強。
以上是我在xx年的主要工作。由於水平有限，在工作中難免會存在不足之處，懇請領導、同志們給予批評指正。在新的一年裏，我將正視困難，團結同志，改進不足，使昆大管線項目部的生產管理工作再上一個新的台階。
更多軟件項目經理年終總結範文推薦閲讀：
1.軟件項目經理工作總結
2.軟件測試工程師個人工作總結
3.高級工程師工作總結
4.研發部年終工作總結
5.技術工程師2015上半年工作總結範文
6.公司管理部年終工作總結
蒙田範文網