初為專案經理(轉)
翻譯改寫：吳昊
這一天終於來到了：你從一個一線開發人員被提拔為專案經理。也許你一直在期盼，也許你心裡還忐忑不安，也許這是你的職業發展選擇，也許你只是不情願的答應老闆“試一下”。不管哪種情況，可能你並沒有專案和人員管理及領導的教育背景或者培訓經歷。
領導和管理（這兩者是不同的）遠非簡單的與Dilbert 的老闆背道而馳（譯者注：Dilbert 是一個漫畫人物，以“擁有”一個“白痴老闆”而著稱）。當你計劃如何做好專案管理時，考慮採取以下列出的行動。也許你想做的事情很多，但下面的這些建議會幫助你集中到那些能提高效率（你自己的效率和團隊的效率）的事情上。
設立優先順序
你要著手的第一件大事很可能就是有意識的設立你作為專案經理的優先順序。儘管你可能因為各種原因還需要很大程度上參與軟體的開發，但除此之外，你還有一些新的職責。很多新任的專案經理都擺脫不了技術的誘惑，以致忽略了專案成員向自己尋求的幫助。
富有效率的專案經理知道，他們最高優先的就是為專案成員提供服務。這些服務包括：指導和教育，處理衝突，提供資源，設立專案目標和優先順序等等，適當時也要提供技術指導。我發現，把自己視為為成員工作，而非監工是很有價值的。不管你正在做或者將要做多重要的事，來你這兒尋求幫助的專案成員應該有“非遮蔽中斷”（譯者注：非遮蔽中斷是一個硬體術語，此處意即最優先的）優先順序。
你第二優先的是讓你所在組織的客戶滿意。作為一個專案經理，如果你不再涉足產品的一線開發，也許你很少有直接的機會可以讓客戶滿意。但你必須為你的專案成員創造一個環境，使得他們在這個環境下工作，可以最有效的滿足客戶的需求。這是專案經理的一個重要職能。
你第三優先的是你自己的事情。可能是一個與專案有關的技術問題（當然也是你感興趣的），也可能是你的老闆要你做的某件事。但當這些事與上面兩個較高優先順序衝突時，你要做好延後處理的準備。
你最低優先的是那些純粹取悅你的老闆的事情。在一個正常的組織（非Dilbet 式的組織）中，如果你做好了前面所說的更重要的三件事情，你的老闆已經是非常驚喜了。儘管並非每個人都那麼幸運可以在一個“正常”的組織工作，但還是努力做好這三件最重要的事。把注意力放在儘可能的幫助下屬富有效率-- 並且快樂-- 上，而不是取悅於那些“上面”的人。
分析你的技能差距
初為專案經理，通常你會意識到你在領導和管理技能方面的差距，除非你已經為這個新職位做了充分準備。你有很強的技術背景，可能這也是提拔你領導技術團隊的一個原因，但你還需要一些其他的技能。你需要客觀的評價自己的長處和短處，並且著手縮小自己的差距。
做軟體的人常常被認為缺乏出色的交際能力。你需要加強你的人際處理能，諸如調解矛盾、說服他人、“推銷”自己。你需要應付一些不想應付的場面，比如解僱你的下屬、在進度上“討價還價”、為爭取下屬的績效“吵架”。
伴我開始經理職涯的是傾聽（Listening）技能的課程，我覺得很有價值。一線開發時，往往我們都有過人的精力來表達自己的技術觀點。但作為管理人員，更需要一種包容和聆聽的工作風格和交流方式。然後，從“聽”的位置走到“說”的位置，你需要提高你的演講（Presentation）技能。如果你對在公眾場合演講感到不適，你需要接受一些專門的演講培訓。這對你今後的工作很有好處。
作為一個專案經理，協調他人的工作、計劃和跟蹤專案、必要時進行專案回溯並採取糾正措施等等都是你的職責。可能的話，接受有關專案管理的培訓，學習如何設立優先順序、如何主持高效的會議、如何明白無誤的溝通等等技能；多看一些專案管理和風險管理的書籍和雜誌，比如Project Management Institute 的月刊《PM Network》（譯者注：你也可以從《PMT 評論》獲得大量有價值的軟體專案知識）。你還可以從SWCMM（軟體能力成熟度模型）中找到很多有關軟體專案管理的有用建議。
定義“ 質量”
儘管絕大多數人都認真對待質量，也想生產出優質的產品；但是，有關軟體質量的定義仍存在很大爭議，比如高質量是“足夠好”還是更為經典的質量觀點--“無缺陷”。為了領導你的團隊走向成功彼岸，你需要花些時間和你的下屬以及客戶一起來明確，對於他們，質量意味著什麼。
你的下屬和客戶是不同的兩幫人，他們很可能對質量沒有一致的看法，也就容易抱有不同的目的。如果客戶很強調交貨期，那他很可能沒有耐心聽程式設計師解釋為什麼需要額外的時間去檢查每一行程式碼。如果客戶看重的是軟體的可靠性，那他在增加功能和減少Bug之間多半會選擇後者。如果客戶習慣了老版本的鍵盤操作，那他很少會對新的圖形操作介面感興趣。
在我曾經負責的一個專案中，為了更好的瞭解客戶的質量要求，我舉辦了一次開放式討論會（Open Forum），除了專案成員和客戶參加外，我還客戶的上司們一起來參加討論。這次討論很有價值，因為我們發現很多原有的想法是和客戶真正的質量需求背道而馳的。瞭解這些想法的差異，使得我們可以把力量集中在讓客戶滿意的事情上，而不是放在讓“開發滿意”的事情上。
軟體質量通常被理解為合乎規格說明，滿足客戶需求，以及在文件和程式碼中儘量少的缺陷（Defect）等等，這些都是比較“經典”的定義。“六西格碼質量”（Six-sigma Quality，譯者注：是一種質量標準及相應的質量管理方法）為缺陷密度（Defect Density）和/ 或失效率（Frequency of Failure）設定了一個很高的標準，但是，它沒有涉及質量的其他方面，比如交貨期、可用性、特性集和效能價格比等等。無論我們是作為生產者還是消費者，我們都希望產品的質量在所有這些方面都是儘量高的，但事實上，我們總要在其中做出權衡和選擇。
我們在需求階段就考慮，對於客戶哪些質量特性是重要的，並把它們列舉出來（比如，互動性、正確性、易學性等）。然後，我們找來一些關鍵的客戶代表，請他們對這些質量特性打分。這樣，我們就可以掌握哪些質量特性是最主要的，哪些是次要的，從而就可以有的放矢，為這些質量特性而最佳化設計。
我聽說的更有意思的一種軟體質量定義是“客戶回來的，但產品沒有”（the customer comes back, but the product does not）。和你的下屬以及客戶一起定義合適的質量目標，一旦定義了，則要不遺餘力的為達成這些目標而努力。也要以身作則，以高標準要求自己。記住這句話：“非完美不爭取，非卓越不滿足”（Strive for perfection; settle for excellence）。
表彰進步
表揚和獎勵專案成員的成績是很重要的激勵方式。你要把建立獎勵計劃Recognition Program）視為頭等大事，除非你已經有了適當的獎勵計劃。獎勵既可以是象徵性的獎狀、證書，也可以是實實在在的獎品和現金。發獎時記得說，“感謝您的幫助”，或者“祝賀您完成了...”。還要記得獎勵的範圍不要侷限在你的專案組內部，客戶代表和一些向你提供特別幫助的專案組外部人員也是要考慮的。
獎勵計劃不僅需要你投入一小筆錢，也需要你多動動腦，想想以何種方式獎勵。和你的下屬多交流，瞭解他們在乎什麼樣的獎勵。要把獎勵活動變成團隊文化的一部分。另外，嘗試“隱形”的獎勵，讓你的下屬明白你是真的知曉他們所做的貢獻，並且對此心存感激。
前車之鑑， 後事之師
你負責的專案很可能是半途接手的，而且你的前任做的並不怎麼好；或者，雖然是新專案，但從前有類似的專案完成，當然有成功的，也有失敗的。不管是哪種情形，你作為專案的負責人，應該花些時間分析以往的成功經驗和失敗教訓。你要了解這些專案曾經出現過什麼問題，以此避免自己重蹈覆轍。失敗是成功之母，但你沒有太多的機會失敗，所以你要多從別人的失敗中學習。
不要戴著有色眼鏡去看以往的專案，或許某個你不喜歡的傢伙出色的完成了他的專案，你當然可以把這歸結為運氣或者僥倖，但如果你客觀的分析，或許更有助於你的成功。
你也需要客觀的去評價自己完成的一些專案（如果有的話），瞭解自己的團隊究竟強在哪裡，弱在何處。事實上，每個完成的專案都要進行專案回顧（Post-project Review），有時這種總結式的專案回顧也叫做“開棺驗屍”（Postmortem）。注意專案回顧不是為了追究誰的責任，發現問題、剖析問題是為了以後做得更好。你可以採取頭腦風暴的做法，鼓勵專案組成員各抒己見。另外，這種專案回顧也可以擴充套件到專案進行中，在每個大的階段結束時都進行回顧。
除此之外，你需要了解被軟體業界普遍認可的最佳實踐（Best practice）。SteveMcConnell 的《Rapid Development》（Microsoft Press，1996）中介紹了27 個最佳實踐和36 個軟體開發的“經典”問題。此書曾獲Jolt Award，是一個很好的學習起點。當你想把一些好的方法、工具和流程引入到你的專案中時，其他人可能會排斥、反對，甚至抵制，而這恰恰是你的職責所在，你要讓專案成員明白為什麼要這樣做，並且確保他們不折不扣的執行。在你的團隊內部，也會產生一些最佳實踐，所以你要採取一些措施，促使在專案成員之間交流和採納這些實踐。
設立改進目標
當你回顧了以往的專案，並且確定了“質量”的含義，你需要設立一些短期的和長期的改進目標。只要可能，這些目標應該是可以量化的，這樣你可以透過一些簡單的指標來衡量自己是否在朝著這些目標前進。
舉個例子，你發現以往的專案由於需求多變而經常延後，於是，你可以設立一個半年的目標，力求將需求的穩定性提高50%。這樣的一個目標要求你每週每月做實際的工作：統計需求的改變數，查明需求的來源和改變的原因，採取措施來控制改變。這很可能將改變你與那些需求更改者的交往方式。
你的這些目標和指標構成了軟體流程改進的一部分。儘管流程改進常被人指責為“官僚作風”的體現，但事實上，每個團隊都能找到一些可以改進的地方。如果你停留在一貫以來的做事方法上，你最好不要指望能獲得比以前更好的結果。
改進流程的原因通常有兩個：糾正錯誤和預防錯誤。你要把精力集中到威脅或者可能威脅專案成功的因素上；帶領你的團隊一起分析你們目前做法的長處和短處，以及所面臨的威脅。
我自己的團隊就組織過一次兩階段的頭腦風暴練習，以此來確認提高我們的產量和質量的障礙。在第一階段，參與者將自己想到的障礙寫在即時貼上，每張即時貼寫一個想法；然後，協調者就把這些即時貼收集起來，並進行分類；於是我們得到了若干大的分類，我們就把這些分類寫在一張大的白紙上。
在第二階段，同樣還是這些參與者，針對前面寫的障礙，把想到的克服方法寫到即時貼上，並且貼上到相應的分類上。經過進一步的討論和分析，我們得以把這些障礙細化，並且獲得了一系列可操作的應對方法。
設立可度量的、可爭取的目標將集中你為改進流程而付出的努力。你要和你的隊員們一起定期檢視改進的結果。記住流程改進的目的是為了專案和公司的成功，而不是為了滿足書本上的條條框框。把流程改進當成專案來操作，有自己的進度、投入和產出。否則，流程改進總是得不到應有的重視，最終被瑣碎的日常工作而淹沒。
不要急於求成
本文所建議的一些做法將幫助你這個專案管理的新手和你的團隊取得更大的成功，隨著你每天面臨的工作壓力，你或許會淪為又一個“苟延殘喘”者，但是，你要始終明白你肩負的一個任務（可能也是你獲得成功的機會），那就是形成你的團隊文化和一套做事的方法，這是一個長期的任務。你不可能一下子把想做的事都做到，你可以根據自己的處境有所選擇，從容上路。[@more@]
這一天終於來到了：你從一個一線開發人員被提拔為專案經理。也許你一直在期盼，也許你心裡還忐忑不安，也許這是你的職業發展選擇，也許你只是不情願的答應老闆“試一下”。不管哪種情況，可能你並沒有專案和人員管理及領導的教育背景或者培訓經歷。
領導和管理（這兩者是不同的）遠非簡單的與Dilbert 的老闆背道而馳（譯者注：Dilbert 是一個漫畫人物，以“擁有”一個“白痴老闆”而著稱）。當你計劃如何做好專案管理時，考慮採取以下列出的行動。也許你想做的事情很多，但下面的這些建議會幫助你集中到那些能提高效率（你自己的效率和團隊的效率）的事情上。
設立優先順序
你要著手的第一件大事很可能就是有意識的設立你作為專案經理的優先順序。儘管你可能因為各種原因還需要很大程度上參與軟體的開發，但除此之外，你還有一些新的職責。很多新任的專案經理都擺脫不了技術的誘惑，以致忽略了專案成員向自己尋求的幫助。
富有效率的專案經理知道，他們最高優先的就是為專案成員提供服務。這些服務包括：指導和教育，處理衝突，提供資源，設立專案目標和優先順序等等，適當時也要提供技術指導。我發現，把自己視為為成員工作，而非監工是很有價值的。不管你正在做或者將要做多重要的事，來你這兒尋求幫助的專案成員應該有“非遮蔽中斷”（譯者注：非遮蔽中斷是一個硬體術語，此處意即最優先的）優先順序。
你第二優先的是讓你所在組織的客戶滿意。作為一個專案經理，如果你不再涉足產品的一線開發，也許你很少有直接的機會可以讓客戶滿意。但你必須為你的專案成員創造一個環境，使得他們在這個環境下工作，可以最有效的滿足客戶的需求。這是專案經理的一個重要職能。
你第三優先的是你自己的事情。可能是一個與專案有關的技術問題（當然也是你感興趣的），也可能是你的老闆要你做的某件事。但當這些事與上面兩個較高優先順序衝突時，你要做好延後處理的準備。
你最低優先的是那些純粹取悅你的老闆的事情。在一個正常的組織（非Dilbet 式的組織）中，如果你做好了前面所說的更重要的三件事情，你的老闆已經是非常驚喜了。儘管並非每個人都那麼幸運可以在一個“正常”的組織工作，但還是努力做好這三件最重要的事。把注意力放在儘可能的幫助下屬富有效率-- 並且快樂-- 上，而不是取悅於那些“上面”的人。
分析你的技能差距
初為專案經理，通常你會意識到你在領導和管理技能方面的差距，除非你已經為這個新職位做了充分準備。你有很強的技術背景，可能這也是提拔你領導技術團隊的一個原因，但你還需要一些其他的技能。你需要客觀的評價自己的長處和短處，並且著手縮小自己的差距。
做軟體的人常常被認為缺乏出色的交際能力。你需要加強你的人際處理能，諸如調解矛盾、說服他人、“推銷”自己。你需要應付一些不想應付的場面，比如解僱你的下屬、在進度上“討價還價”、為爭取下屬的績效“吵架”。
伴我開始經理職涯的是傾聽（Listening）技能的課程，我覺得很有價值。一線開發時，往往我們都有過人的精力來表達自己的技術觀點。但作為管理人員，更需要一種包容和聆聽的工作風格和交流方式。然後，從“聽”的位置走到“說”的位置，你需要提高你的演講（Presentation）技能。如果你對在公眾場合演講感到不適，你需要接受一些專門的演講培訓。這對你今後的工作很有好處。
作為一個專案經理，協調他人的工作、計劃和跟蹤專案、必要時進行專案回溯並採取糾正措施等等都是你的職責。可能的話，接受有關專案管理的培訓，學習如何設立優先順序、如何主持高效的會議、如何明白無誤的溝通等等技能；多看一些專案管理和風險管理的書籍和雜誌，比如Project Management Institute 的月刊《PM Network》（譯者注：你也可以從《PMT 評論》獲得大量有價值的軟體專案知識）。你還可以從SWCMM（軟體能力成熟度模型）中找到很多有關軟體專案管理的有用建議。
定義“ 質量”
儘管絕大多數人都認真對待質量，也想生產出優質的產品；但是，有關軟體質量的定義仍存在很大爭議，比如高質量是“足夠好”還是更為經典的質量觀點--“無缺陷”。為了領導你的團隊走向成功彼岸，你需要花些時間和你的下屬以及客戶一起來明確，對於他們，質量意味著什麼。
你的下屬和客戶是不同的兩幫人，他們很可能對質量沒有一致的看法，也就容易抱有不同的目的。如果客戶很強調交貨期，那他很可能沒有耐心聽程式設計師解釋為什麼需要額外的時間去檢查每一行程式碼。如果客戶看重的是軟體的可靠性，那他在增加功能和減少Bug之間多半會選擇後者。如果客戶習慣了老版本的鍵盤操作，那他很少會對新的圖形操作介面感興趣。
在我曾經負責的一個專案中，為了更好的瞭解客戶的質量要求，我舉辦了一次開放式討論會（Open Forum），除了專案成員和客戶參加外，我還客戶的上司們一起來參加討論。這次討論很有價值，因為我們發現很多原有的想法是和客戶真正的質量需求背道而馳的。瞭解這些想法的差異，使得我們可以把力量集中在讓客戶滿意的事情上，而不是放在讓“開發滿意”的事情上。
軟體質量通常被理解為合乎規格說明，滿足客戶需求，以及在文件和程式碼中儘量少的缺陷（Defect）等等，這些都是比較“經典”的定義。“六西格碼質量”（Six-sigma Quality，譯者注：是一種質量標準及相應的質量管理方法）為缺陷密度（Defect Density）和/ 或失效率（Frequency of Failure）設定了一個很高的標準，但是，它沒有涉及質量的其他方面，比如交貨期、可用性、特性集和效能價格比等等。無論我們是作為生產者還是消費者，我們都希望產品的質量在所有這些方面都是儘量高的，但事實上，我們總要在其中做出權衡和選擇。
我們在需求階段就考慮，對於客戶哪些質量特性是重要的，並把它們列舉出來（比如，互動性、正確性、易學性等）。然後，我們找來一些關鍵的客戶代表，請他們對這些質量特性打分。這樣，我們就可以掌握哪些質量特性是最主要的，哪些是次要的，從而就可以有的放矢，為這些質量特性而最佳化設計。
我聽說的更有意思的一種軟體質量定義是“客戶回來的，但產品沒有”（the customer comes back, but the product does not）。和你的下屬以及客戶一起定義合適的質量目標，一旦定義了，則要不遺餘力的為達成這些目標而努力。也要以身作則，以高標準要求自己。記住這句話：“非完美不爭取，非卓越不滿足”（Strive for perfection; settle for excellence）。
表彰進步
表揚和獎勵專案成員的成績是很重要的激勵方式。你要把建立獎勵計劃Recognition Program）視為頭等大事，除非你已經有了適當的獎勵計劃。獎勵既可以是象徵性的獎狀、證書，也可以是實實在在的獎品和現金。發獎時記得說，“感謝您的幫助”，或者“祝賀您完成了...”。還要記得獎勵的範圍不要侷限在你的專案組內部，客戶代表和一些向你提供特別幫助的專案組外部人員也是要考慮的。
獎勵計劃不僅需要你投入一小筆錢，也需要你多動動腦，想想以何種方式獎勵。和你的下屬多交流，瞭解他們在乎什麼樣的獎勵。要把獎勵活動變成團隊文化的一部分。另外，嘗試“隱形”的獎勵，讓你的下屬明白你是真的知曉他們所做的貢獻，並且對此心存感激。
前車之鑑， 後事之師
你負責的專案很可能是半途接手的，而且你的前任做的並不怎麼好；或者，雖然是新專案，但從前有類似的專案完成，當然有成功的，也有失敗的。不管是哪種情形，你作為專案的負責人，應該花些時間分析以往的成功經驗和失敗教訓。你要了解這些專案曾經出現過什麼問題，以此避免自己重蹈覆轍。失敗是成功之母，但你沒有太多的機會失敗，所以你要多從別人的失敗中學習。
不要戴著有色眼鏡去看以往的專案，或許某個你不喜歡的傢伙出色的完成了他的專案，你當然可以把這歸結為運氣或者僥倖，但如果你客觀的分析，或許更有助於你的成功。
你也需要客觀的去評價自己完成的一些專案（如果有的話），瞭解自己的團隊究竟強在哪裡，弱在何處。事實上，每個完成的專案都要進行專案回顧（Post-project Review），有時這種總結式的專案回顧也叫做“開棺驗屍”（Postmortem）。注意專案回顧不是為了追究誰的責任，發現問題、剖析問題是為了以後做得更好。你可以採取頭腦風暴的做法，鼓勵專案組成員各抒己見。另外，這種專案回顧也可以擴充套件到專案進行中，在每個大的階段結束時都進行回顧。
除此之外，你需要了解被軟體業界普遍認可的最佳實踐（Best practice）。SteveMcConnell 的《Rapid Development》（Microsoft Press，1996）中介紹了27 個最佳實踐和36 個軟體開發的“經典”問題。此書曾獲Jolt Award，是一個很好的學習起點。當你想把一些好的方法、工具和流程引入到你的專案中時，其他人可能會排斥、反對，甚至抵制，而這恰恰是你的職責所在，你要讓專案成員明白為什麼要這樣做，並且確保他們不折不扣的執行。在你的團隊內部，也會產生一些最佳實踐，所以你要採取一些措施，促使在專案成員之間交流和採納這些實踐。
設立改進目標
當你回顧了以往的專案，並且確定了“質量”的含義，你需要設立一些短期的和長期的改進目標。只要可能，這些目標應該是可以量化的，這樣你可以透過一些簡單的指標來衡量自己是否在朝著這些目標前進。
舉個例子，你發現以往的專案由於需求多變而經常延後，於是，你可以設立一個半年的目標，力求將需求的穩定性提高50%。這樣的一個目標要求你每週每月做實際的工作：統計需求的改變數，查明需求的來源和改變的原因，採取措施來控制改變。這很可能將改變你與那些需求更改者的交往方式。
你的這些目標和指標構成了軟體流程改進的一部分。儘管流程改進常被人指責為“官僚作風”的體現，但事實上，每個團隊都能找到一些可以改進的地方。如果你停留在一貫以來的做事方法上，你最好不要指望能獲得比以前更好的結果。
改進流程的原因通常有兩個：糾正錯誤和預防錯誤。你要把精力集中到威脅或者可能威脅專案成功的因素上；帶領你的團隊一起分析你們目前做法的長處和短處，以及所面臨的威脅。
我自己的團隊就組織過一次兩階段的頭腦風暴練習，以此來確認提高我們的產量和質量的障礙。在第一階段，參與者將自己想到的障礙寫在即時貼上，每張即時貼寫一個想法；然後，協調者就把這些即時貼收集起來，並進行分類；於是我們得到了若干大的分類，我們就把這些分類寫在一張大的白紙上。
在第二階段，同樣還是這些參與者，針對前面寫的障礙，把想到的克服方法寫到即時貼上，並且貼上到相應的分類上。經過進一步的討論和分析，我們得以把這些障礙細化，並且獲得了一系列可操作的應對方法。
設立可度量的、可爭取的目標將集中你為改進流程而付出的努力。你要和你的隊員們一起定期檢視改進的結果。記住流程改進的目的是為了專案和公司的成功，而不是為了滿足書本上的條條框框。把流程改進當成專案來操作，有自己的進度、投入和產出。否則，流程改進總是得不到應有的重視，最終被瑣碎的日常工作而淹沒。
不要急於求成
本文所建議的一些做法將幫助你這個專案管理的新手和你的團隊取得更大的成功，隨著你每天面臨的工作壓力，你或許會淪為又一個“苟延殘喘”者，但是，你要始終明白你肩負的一個任務（可能也是你獲得成功的機會），那就是形成你的團隊文化和一套做事的方法，這是一個長期的任務。你不可能一下子把想做的事都做到，你可以根據自己的處境有所選擇，從容上路。[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-960093/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 初為專案經理 (轉)
- 初為專案經理1（轉）
- 初為專案經理2（轉）
- 初為專案經理3（轉）
- 初為專案經理的工作步驟（轉）
- 專案經理之初為專案經理
- 專案管理過程攻略——送給初為專案經理的朋友專案管理
- 作為專案經理, 你是否明智（轉）
- 初任專案經理（轉）
- 專案管理與專案經理（轉）專案管理
- IT專案經理手冊（轉）
- 專案經理作用非凡（轉）
- 我做IT專案的專案經理的經歷（轉）
- 專案經理和專案參與者（轉）
- 專案經理的能力要求(轉)
- 專案經理面試指南（上）（轉）面試
- 專案經理面試指南（下）（轉）面試
- 專案經理面試指南（上） （轉）面試
- 專案經理面試指南（下） （轉）面試
- 專案經理怎麼選？(轉)
- 專案經理的職責(轉)
- 如何做好專案經理 （轉）
- 如何做好專案經理(轉)
- 專案經理與領導（轉）
- 專案經理的選拔（轉）
- 專案經理注意事項（轉）
- 成功專案經理手冊（轉）
- IT專案經理的責任(轉)
- 提升專案經理的形象(轉)
- 滿分的專案經理（轉）
- 專案經理也需要“不講理”（轉）
- 專案收尾——專案經理的血淚史(轉)
- 專案經理部是專案管理的保障（轉）專案管理
- 作為專案經理, 你是否明智？
- 專案經理之專案經理的基本特徵特徵
- 專案經理之成功專案經理手冊
- 專案經理之專案經理注意事項
- 專案經理之如何做好專案經理