專案經理是具體專案工作的管理者，他們在工作中不斷提升自己的領導才華，同時該職業又是一個權利與責任並存的職業， 他們主要對專案進行背景調查，收集整理專案相關資料，進行需求策劃，撰寫專案調查報告和資訊綜述，對專案組成部分或模組進行完整系統設計，聯絡專案相關單位和相關技術專家，制定專案可行性研究報告，協同配合制定和申報立項報告材料，組織專案團隊完成專案任務，保證專案的完成時間和完成質量。下面是本站小編為大家整理的IT專案經理應該做什麼，歡迎閱讀!
IT專案經理應該做什麼
經常看到這樣的專案經理，一副整天忙得團團轉的樣子，電話不停地作響，一個小時之內要發出幾十個指令，好像他所領導的團隊離開了他就一天也活不下去。然後他還會說："我很忙"或"我很累"，"我需要增加人手"。這樣的專案經理經常事無鉅細都要親自過問，即使旗下有人，你說他能不累嗎?
甚至還有這樣的事列發生，研發部門經理親自參與專案軟體的編碼工作，如果只有一、兩個專案，也許這樣還可以，試想，如果有十幾個專案你能都參與具體的技術工作，另外是否考慮過部門經理參與具體專案後所帶來的其他問題，部門日常事物務無處理，部門人員無人關注，部門的其他專案得不到專案經理的協助，更是無人為部門的未來作打算。類似的專案經理的行為很多：譬如善於銷售的經理就對自己的銷售人員總是不放心，覺得下面的人出馬總是不那麼牢靠;文筆較好的專案經理總是要親自起草檔案，因為祕書起草的東西總是叫他看不上眼，如此等等。
由此造成的結果是經理整天搞得手忙腳亂，管理效率很低。做經理者沒有時間考慮部門發展的問題，做下屬者覺得自己得不到信任，做事小心翼翼，不敢越雷池半步，沒有積極性。
由此想到劉備，文不如諸葛亮，武不如關張趙馬黃，但是他會用人，會籠絡人。做專案經理人的恐怕都需要學習一下劉備的做法，即便你是在某些方面非常地出色。你可以把你的經驗傳授給你的下屬，不要怕他們犯錯誤。"用人不疑，疑人不用"，雖然很難做到而且有時也不一定非要做到，但是你既然給了一個人那個位置，那份薪水，就應該讓他們充分地發揮，你不能替他們做事，你不能"搶"你付給他們的權力。記得有次記者採訪CA公司總裁汪嘉廉先生時，汪先生說他到目前還沒有個人email地址，記者很驚詫的問他為什麼時，他說“沒有必要，我有很好的業務總監們，他們會處理好公司的日常事務，我要有充足的時間考慮公司的發展戰略，我不希望被一些瑣事打擾”。汪嘉廉是一位好的管理者，所以CA才有今天的地位。
做得好的專案經理可能看起來每天的工作並不是那麼緊張。所以有些下屬就可能提出這樣的問題："我們忙，你在幹什麼?"
專案經理，對於一個團隊履行它的使命和發展負責的人。因此創造出一個大於其各組成部分的總和的真正的整體，創造出一個富有活力的整體，應該是其第一使命。即人們經常談論的管理，通過管理則可以把在自然界1+1〉2的不可能轉變為可能。為履行這一使命，專案經理應該做什麼呢?
一、一個專案經理首先要制定目標，即確定團隊的目標，只有知道往哪走，才能到達那裡。確定目標是什麼，而且目標要能夠有效的支撐團隊的責任，有助於團隊的發展。而且要將目標傳達給團隊的每一位人員，讓他們認識到他們在實現目標過程中的責任和重要性。
二、一個專案經理要進行組織工作，即如何安排工作，需要分析所需的各項活動、決定和關係，他需要對工作分類，確定作業任務的主次和輕重緩急，併為作業分配適當的執行的人員。
三、一個專案經理要進行激勵和資訊交流工作。他把擔任各項職能的人組合成為一個團隊，它需要通過對下屬的激勵，以及同上、下、同級間的相互資訊交流，協調完成工作。
四、一個專案經理需要進行衡量考核,衡量團隊的績效和個人的績效。首先需要確立衡量的標準，這個標準不但要專注於團隊的績效，而且還要求專注於個人的工作並幫助他做好工作。一個專案經理把衡量的意義和結果通報給他的下級、上級和同級。
五、一個專案經理要培養人，也包括他自己。專案經理比其他人更瞭解其下屬的長處和短處、更清楚下屬的培訓需求，也常常擁有幫助其下屬改進工作績效所必需的技能，只有下屬的技能提高了，整個團隊的效率才可能提升，只有團隊的成員有發展，他們才會在執行工作時投入熱情和責任。 經理需要制定培訓計劃並部署。
在我們這個行業，好多專案經理是在業務或者說技術方面有過硬的能力後才被賦予經理這一責任的，他們可能沒有受過管理學的教育，希望此文能夠給與他們思考與認識自己責任。
專案經理該做什麼，不該做什麼
1.以目標導向來做事情
首先要明白該做什麼，其次才是如何做。目標是專案管理的重要特徵，專案經理做事原則都是圍繞專案目標展開，對於有利於專案目標達成而又不違背專案經理職業道德和行為準則的事情都是該做的事情。
目標有短期目標和常用目標，把當前專案按目標完成可能是短期目標，通過一年時間帶出一個高效的團隊可能是一個長期目標。對於非臨時專案的專案經理，更加應 該著眼於專案長期目標，而不是太在意於當前專案的短期利益。只有意識到這點，才能夠認識到培訓，教練，團隊，自發，團隊語言和規則等在整個專案中的重要 性。
2.對自己定義的目標進行分解
對於軟體專案，專案經理根據商業或使用者需求會定義軟體產品釋出後的故障率小於0.5個/KLOC程式碼。要達到這個目標就需要結合專案的時間過程分析影響該 目標的要素，各個階段交付物的質量，缺陷的洩露，測試的水平，需求的變更和穩定性，前期的需求設計和開發規範，團隊規則，開發人員的責任心多方面因素都可 能影響到該目標的實現。
一個總體目標的達成絕對不是簡單的改善一項影響要素就可以達成的，而且各個要素間還存在這正反作用，必須要綜合性的系統思考。確定出期望的各個要素的區間 水平，然後將這些期望值列入到計劃中進行跟蹤和控制。這一系列的過程要表明的都是你做的每一件事情都是有目的的，都是為了實現當初定義的目標而服務，絕不 是無中生有。
3.具體實際操作的關注點
首先對於風險和危機的重視度遠大於對問題的重視度。不是說問題解決不重要，而是專案經理應該更多的管理風險和消除隱患，不讓風險轉換為真正的問題。專案經 理必須有足夠的問題前瞻性和敏銳的洞察力，發現各種徵兆和危機，危機發生前應對往往僅僅是專案經理找成員談談心，或者說組織一次關於規程的培訓，但危機如 果發生造成的損失會遠遠大於風險應對的成本。
專案經理應該更多的取做教練，而不是去做領導。管理者要懂得授權，但專案經理更關注的是授權不會影響到進度和質量，因此專案經理絕對不是越俎代庖啥事情都 自己做，也不是盲目授權後啥都不管，而是充當好教練的角色。讓專案成員有能力的全完成事情，而且是有責任心的去完成事情。如果自己做只花1個小時，而教會 團隊成員做需要一天，從團隊常用的角度必須花費這一天時間教會成員如何正確的做事情。
PMBOK九大知識體系內容都是專案需要考慮做的內容。裡面有個關鍵詞是專案管理組，專案管理組是由專案核心成員共同組成的。必須要分清楚哪些是專案經理 做，哪些是專案管理組做。另外一個關注點是做事情的粒度，專案任務的跟蹤是專案經理要做的，但專案經理應該根據專案目標確定自己跟蹤任務的粒度，粒度太細 的可以由專案成員或小組負責人跟蹤。專案經理該做什麼不能簡單專案經理人與專案成員的實戰指南
在一個團隊中，作為一名團隊領導，將：
1) 避免團隊目標向政治問題妥協
2) 向團隊目標顯示個人承諾
3) 不用太多優先順序的事物沖淡團隊的工作
4) 公正、公平的對待團隊成員
5) 願意面對和解決與團隊成員不良表現有關的問題
6) 對來自員工的新思維和新資訊採取開放的態度
作為團隊成員，要將：
1) 展示對個人角色和責任的真正理解
2) 展示目標和以事實為基礎的判斷
3) 和其他團隊成員有效地合作
4) 使團隊目標優先個人目標
5) 展示投身於任何專案成功所需的努力的願望
6) 願意分享資訊、感受和產生適當的反饋
7) 當其他成員需要時給予適當的幫助
8) 展示對自己的高標準要求
9) 支援團隊決策
10) 以為團隊的成功而奮鬥的方式體現帶頭作用
11) 對別人的反饋做出積極的反應的理解為二元問題，更多的是跟專案目標和管理粒度相關的做事情的粒度問題。
IT專案經理的經驗總結
本人做專案經理工作多年，感到做這個工作最要緊的就是要明白什麼是因地制宜、因勢利導，只有最合適的，沒有什麼叫對的，什麼叫錯的，專案經理最忌諱的就是完美主義傾向，尤其是做技術人員出身的，喜歡尋找標準答案，耽誤了工作進度，也迷茫了自己。以下是本人一些做專案的個人體會，寫出來供大家指點，在討論過程中共同提高水平。
專案開始階段是一個最重要的階段。專案經理在接手一個新專案的時候，首先要儘可能地多從各個方面瞭解專案的情況，如：
1.這個專案是什麼專案，具體大概做什麼事情，是誰提出來的，目的是解決什麼問題。在國內很多客戶都很不成熟的情況下，千萬不要根據專案的名稱望文生義地去想象專案的目標。一個名為“辦公自動化”的專案很有可能在你進場以後一個月才發現客戶其實需要的是一個計算機生產管理輔助資訊系統系統。前期瞭解情況的工作越詳細，後面的驚訝就越少，專案的風險就越小。
2.這個專案裡牽涉哪些方面的人，如投資方、具體業務干係方、專案建成後的運營方、技術監督方等等，很多專案裡除了業主單位的結構很複雜以外，還有一些其他單位也會牽涉進來，如專案監理公司、業主的行業主管機構等。專案經理需要了解每個方面的人對這個專案的看法和期望是什麼。事先了解各個方面的看法和期望，可以讓你在做專案碰到問題的時候，就每件事情分析哪些人會在什麼方面支援你，哪些人會出於什麼目的反對你，從而提前準備聯合朋友去對抗敵人，讓事情向你所希望的方向發展。沒有永遠的朋友，也沒有永遠的敵人，只有一致的利益，這句話作為專案經理是一定要記住的;
3.基本瞭解了客戶的情況後，下面的事情就是了解自己公司各方面對這個專案的看法。首先是高層領導是否重視，這個決定了你在需要資源的時候，公司是否會根據你的要求提供最有力的支援。領導口頭肯定是說支援的，你需要做的是瞭解公司對這個專案的實際期望，是想把專案越做越大還是想賺錢?是想做樣板工程還是乾脆想敷衍了事，公司領導對專案的態度決定了你做這個專案的戰略，而這個戰略方針將對你做專案計劃產生直接的影響;
4.在做整體專案計劃前，還要大致計算一下你手上的資源。首先是時間，現在市場競爭激烈，往往很多專案要求在幾乎不可能的時間範圍裡完成。對於這一點，你在做專案的風險控制計劃的時候要充分考慮。其次是人員，根據專案預算和已往經驗，大致計算一下未來的專案小組有多少種角色，每個角色目前公司是否有人，是否能完全歸這個專案使用，是否需要另外招聘一些人員，招聘的準備工作要儘早啟動。最後就是一些裝置的準備，專案所需大件關鍵裝置要儘早預定，以後不管發生裝置等人還是人等裝置的情況，浪費的都是你的時間;
5.現在是做專案說明書的時候了。一份好的專案說明書不僅將要做的事情描述得很清楚(主要是講做什麼，而不是說怎麼做)，而且把如何檢查也說明得很透徹。也就是說它不僅說明白了要做哪些事情，也讓客戶的業務人員(一般不懂技術)知道專案做成什麼樣就算完成了。簡單地說，專案說明書描述專案做哪些事情和每件事情做到什麼程度以及如何檢查每一個結果。
6. 是到做總體計劃的時間了嗎?不，你現在已經知道了客戶的目標和你手上的資源，那麼做計劃以前，你還需要和你的經理和客戶充分溝通資源的問題。因為很多資源是還不明確的，你需要寫一份報告，詳細分析這個專案的風險以及對資源的需求情況。如果一些問題不能得到解決的話，將發生什麼樣的後果。如果資源不夠，就要高層改變策略，增加對這個專案的投入。甚至在條件許可的情況下，有些公司會放棄這個專案。總之，沒有人能完成一個不可能完成的任務，如果專案經理不能儘早發現風險，那麼就只能去當烈士了。
7.明白了要做哪些事情和你手上的籌碼以及你做這個專案的總體策略，現在是成立專案小組的時候了。很多專案經理都沒有自己選擇組員的權利，那麼，就儘量發揮你的影響力去尋找那些你想要的人吧。成員的組成根據專案不同，相差較大，很難有什麼具體要求，但是，一定要有精通客戶業務的人，很多小專案裡，這個人就是專案經理本人，大專案裡會配備行業專家(Industry expert)，這樣和客戶溝通起來才不會雞同鴨講，雙方才可以相互理解。我經常看到的情況是我們的技術人員和客戶交談時滿口的專業術語，結果搞得客戶一頭霧水，反過來，他還指責客戶不懂技術。其實，明白自己想做什麼的客戶已經是很好的客戶了，不知道自己要做什麼，更不懂怎麼做還要指手畫腳的客戶到處存在，但是要明白，是客戶選擇了你，而不是你選擇了客戶，有了客戶你才有工資拿，心平氣和一點吧。
8.現在你要面對三群人：你的領導、你的組員和你的客戶，和這些人溝通，讓他們知道你打算怎麼做，什麼時候要他們做什麼準備這些事情將是你的主要工作。既然溝通這麼重要，那些事先定義一下溝通的原則也是一件很要緊的事情。很多溝通原則都是潛規則，如果你在一個部門時間做長了，對這些規則的運用覺得是一件理所應當的事情，但是，你現在面對的是多個部門甚至多個單位，不把溝通規則說清楚，你以後就會吃虧。下面的東西看起來無聊，其實還是很管用的：第一個是規定資訊的流動方式和介質，是推還是拉。推的意思就是專案經理將主動釋出資訊，不管通過電話、郵件還是書面方式，保證將資訊傳達到每個人。這種情況適合小專案，人少;拉的意思就是專案經理就是一個類似web伺服器，你自己需要什麼資訊就去問他。當然，沒有專案經理把自己搞得那麼累，他會用釋出資訊到公共介質的方式公佈資訊，簡單的是白板，複雜一點的是專案的公共資訊互動區，潛規則就是我發了你沒去看就不要說我沒告訴你。說這些看似很無聊，其實裡面牽涉資訊傳達不完全的責任問題。當然，這些都是指一般的方式，而且不要絕對化，一般情況下，主動溝通和被動訪問是同時存在的，尤其是對領導，專案經理更加應該主動去和領導溝通。第二個問題就是文件問題，很多人怕寫文件，但是專案經理一定要牢記“好記性不如爛筆頭”的道理。有理有時候為什麼會說不清呢?就是因為沒有證據。所以專案經理開始就要和客戶說清楚有些文件是必須簽字的，比如專案經理的專案日誌，每個星期至少讓客戶簽字，另外所有達成共識的東西，比如會議紀要，甚至領導的講話記錄，都要寫成文件，雙方簽字，這樣以後扯皮的時候，就能做到有據可查。記住：說了的就和沒說一樣，只有寫下來大家簽字後才算真正發生了的。還有一些問題，比如你提交的報告，給領導(包括本方領導和客戶領導)做一個選擇題，結果領導壓住不批，讓你無所適從，結果拖延了進度。這時候，你可以等，但是注意要留記錄，標明是誰的責任;另外，如果你在開始階段就和領導商定：如果批示提交三天後沒有得到領導答覆就算對方同意，這樣你就會主動很多。再比如不同事件的審批流程問題：什麼等級的事情記錄在專案日誌裡、什麼等級的事情要雙方專案經理專門簽署備忘錄、什麼等級的事情要雙方領匯出面簽署合同附件等等。事先想得越周到，以後的工作就越主動。
9. 好了，做了很多前期工作，定義了一些遊戲規則，現在是坐下來做計劃的時候了。這一節，任意找一本專案管理的書都會說得比我好，所以我就少寫一點，說一些自己的體會就是了。首先是找幾個關鍵組員，比如客戶業務專家、系統分析員等等，做一下專案模組劃分工作。專案分成幾塊去做，每一塊完成什麼，模組之間的資訊如何交換等等。需求定義的是做什麼的問題，而這裡說的是怎麼做的問題。這裡要強調一點：完成一個目標有很多種方式，你要選一種你最熟悉的，而不是看上去最完美的，這個思路會讓你的專案減少很多風險。有時候客戶會被某種新技術打動，堅持要你採用那種新技術，你就應該告訴他：你選我做這個專案，就應該容許我採用自己最喜歡的方式做事情，新技術之所以有誘惑力，就是因為吃虧的人還不多，我不希望你成為第一批受害者。採用一個計劃會讓你的工作更加明確，比如用微軟的Project軟體，你填寫完表格以後，就可以知道這個專案有多少件事情要做，每件事情需要什麼資源，他們之間的前後關係如何，消耗的時間有多長，完成後有什麼標誌等。所有的結果最後用一個叫做甘特圖的形式表現出來。你做完這個表以後會驚奇地發現，甘特圖上專案的結束時間會遠遠落後於你的計劃結束時間(籤合同的人永遠不會先徵求你的意見的)。當然，學過專案管理的人會大談什麼WBS、優化路徑之類的東西，但是我的經驗是你再優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題，在我恭喜你挑了一個輕鬆活之前，請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候，你就要考慮犧牲一些任務的時間(也意味著質量)了。按照什麼標準犧牲?這個專案的戰略!我們在第三節提到過的戰略。我的經驗是如果你什麼都趕進度，其結果可能就是十件事情你一件也沒做好，想想多麼失敗啊。所以，把資源投到你熟悉和有把握的事情上，最後的結果是十件事情，你有三件做成了精品，三件完成，還有四件因為某些原因延誤，成績單是否靚麗了很多呢?戰略決定優先順序，而正確排列事情的優先順序是一個專案經理能力的主要體現。
好，現在專案已經完成了前期工作，瞭解了專案的目標、搞清楚了手上的資源，制定了專案的策略，然後編制了專案的整體計劃，專案進入實施階段。進入這個階段反而是專案經理比較空閒的時候，不像前期的時候專案經理要象記者一樣到處和不同的人接觸，搞清楚他們在說什麼，努力猜測他們在想什麼和他們的真正目的，那才是最累人的事情。當然，小專案的專案經理往往自己也是一個資源，要做很多事情，這時候反而比誰都苦。專案經理這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領導溝通時特別要注意，除非你需要對方給你支援，那麼你才需要講得具體一點，否則，告訴他一切正常就可以了，而且態度要積極一些，千萬不要說一些領導不懂的細節，比如：“王局長，最近專案進度還算正常，就是JVM經常發生一些記憶體洩漏的情況…”王局長：“(*&$@@”。和自己的領導彙報也要注意這個問題，除非他是一個技術高手，你需要他的技術經驗，否則一般就彙報進度是否正常以及有問題時你的對策和打算就可以了，有些需要他支援的地方，比如資源呼叫需要說詳細一點。
和組員開會，除了一些專案進度跟蹤會議以外，還有很多討論會，需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員，他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強(如果總結得不對，歡迎大家拍磚)，所以，你作為會議的主持人，只要負責提出問題和記錄下他們的觀點，千萬不要做評判者的角色。一個問題，有很多方面，從不同的角度看，現象是完全不同的，想想盲人摸象的故事吧。這些技術人員，他們往往精通一個方面，就自己的角度發表見解，除非一些很特別的情況，你都應該認為，他們提出的方案，從他們的角度來看是最合理的。你的長處是掌握事情的優先順序，評估各個方面的輕重緩急，從而根據他們的意見得出一個合適的(而不是正確的)方案。所以，在會議上，你要充分尊重每一個人和他的意見，誇獎那些意見提得比較好的人，千萬不要把會議帶入無休止的爭論(你要讓大家知道事情不是非黑即白的，而是多元的，唉，我們的教育惹的禍…)。會後，你自己寫文件，做決定。會議上大家的面子都被照顧了，自然實施起來的阻力就小，如果還有意見的，你就私下找他聊，如果還不能說服他，你就要讓他明白，因為你負責這個專案、你擔當風險，所以，這個優先順序應該你來判斷。組織中的高層，並不見得水平會比一般的成員高，但是，他要承擔組織的風險，加之資訊的不對稱性，所以，對事情的優先順序的判斷肯定比下屬強。
在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【介面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組佈置任務的時候就要考慮如何檢查結果，比如我見過一個計劃，裡面有一個任務【開發人員熟悉EJB程式設計】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是專案經理一直要注意的事情，我聽說有些老專案經理拿到專案是倒排計劃的，即首先看如何驗收和驗收標準，然後決定工作計劃。很多專案開始了很久，還不知道如何驗收，那麼這個專案出問題的可能性就很大了。做專案就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那麼多勞動後得到結果。另外我插一句：我是極其不主張到客戶現場開發的。尤其是一大群技術人員直接和客戶交流，很容易引起衝突和矛盾(技術人員的本性決定的)。我的做法是專案經理和專案實施人員到現場，軟體開發人員還是在公司做專案。專案實施人員就是初級專案經理，他們瞭解自己的產品，懂得一些客戶的業務，關鍵是在於他們具有良好的溝通能力，俗稱“皮厚”。他們是客戶和研發人員的橋樑，其職業方向也是很機動靈活，以後可以有很多方向可以轉，比開發人員的路要寬得多。
接著，我們再談談最讓人頭痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標，即需求變更;另一種是沒改變目標，但是客戶不滿意目前的實現方式，大到流程的實現，小到介面的佈局，都是屬於這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客戶隨著專案的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改並且你的戰略是容許這種情況的，那麼注意下面幾點：
1.確保以前的文件，就是記載著以前的結論的東西，客戶是否簽過字，如果沒有，趕緊把你的工作停下來，趕快再和客戶自己確認一下你的方案，然後讓他簽字，避免以後說話沒有憑據;
2.和客戶坐下來，自己探討他修改的根本目的是什麼，是不是有同樣能達到相同目的，但是對你來說有代價更小的選擇?
3.(專案初期的工作)明確更改流程，一般是客戶指定一人簽字(否則客戶每個領導都有權力來插一槓子，你就廢了)，以正式專案檔案的方式提交給你，然後，你做評估分析，分析對成本、進度的影響，在你的領導同意後，出相應意見書，主要是要說明更改設計的原因和指出由此帶來的不確定後果(這個東西先寫出來，後面如果真的發生了，至少不是你的錯)。然後再讓客戶在上面簽字。見過醫院給病人做手術以前讓家人籤的免責條款嗎?對，就學習那個，讓大家都意識到任何的更改都有成本和代價。