各位都有心得,我扔兩句:
1.沒錯,PM的活比較零碎,主要作爲項目組和領導以及客戶的信息中轉站,因此,項目分配任務的時候考慮儘量少安排一些工作,因爲總會有意想不到的工作干擾你.
2.權利下放,考慮TSP(我們實行過,效果不錯),將組員分成角色,例如每天的備份,由專人負責,你只管檢查備份是否完成,這樣同樣能調動組員積極性,讓他自己對項目有責任感,自己也省心.
3.放下追求技術的心態,看問題的眼光放在項目上.
4.多看看管理的書,尤其是激勵的方法.
個人覺得項目經理比較重要的是
1、“隨時可中斷”。必須隨時做好準備去應付一些突發的事情。
因此項目經理不應該給自己分配需要集中精力和較長時間才能完成的事情。
一旦必須要這麼做的時候，儘快安排人接替。
明確哪些事情自己該做，哪些事情不該做，不該做的事情要堅決扔出去。
換句話說，項目經理的第一任務是“讓自己空下來”。
PM的活比較零碎,主要作爲項目組和領導以及客戶的信息中轉站,因此,項目分配任務的時候考慮儘量少安排一些工作,因爲總會有意想不到的工作干擾你.
項目計劃要多富裕些時間：
以應對不可預測的情況發生。
整體計劃與各階段計劃相結合，控制時間和進度。
對用戶的需求要畫定好範圍和界限，不能一味的遷就客戶影響工程進度。
2、“團隊優先”。
我一般給團隊中人分配兩件任務，一件是主要的、固定的，有時間限制的，
一般是需要八到九成時間。
一件是次要的、靈活的，無時間限制的，但是有目標要求。
通常後一件會帶有一些技術探索意味，屬於該成員個人比較感興趣的部分。
換句話說，項目經理的第二任務是“讓團隊中的所有人都有事情做”
3、“控制客戶”
控制客戶包括多方面的意思，搞好關係是一層，但如果軟件做的實在太差，
沒法用，關係再好都沒有用。
而且關係好是雙面的，客戶同樣可能以關係好爲由來要求你這裏改改那裏
改改，結果造成項目無限期拖延。尤其是市場/銷售人員經常去開空頭支票。
我覺得，應該是對客戶領導要搞好關係，告訴他一切沒問題，一般這是
市場/銷售人員搞定的
但是對軟件的實際使用者也就是客戶的底層人員訴苦。這個就要項目小組
自行解決了。
如果是小項目，往往是開發人員直接見用戶。前者由項目經理來自行，後
者直接由軟件開發人員進行，挑一個比較會說話的，多往用戶那邊跑跑，
聊聊天。當軟件投入運行時，這是很有用的。再好的軟件也架不住用戶
不斷地需求變更，因此最好的辦法是“把需求變更扼殺在襁褓之中”。
如果是大項目，用戶方應該會有專門的項目負責人（用戶代表），和用戶
代表綁定在一起是非常必要的。但是底層的人員一樣要搞定，那就可以有
專門的支持人員，更需要和用戶多接觸了。
操作的時候注意多留文檔，哪怕是再小的問題也要留檔，過一個月整理一
下，往客戶領導（或者用戶代表）那邊一放。統計一下本月共發現多少問
題，哪些是新需求，哪些是軟件BUG，哪些是用戶使用問題，解決了多少，
有哪些遺留，我方技術人員現場支持多少小時，諸如此類。總之讓對方感覺
我們勞苦功高，服務周到，響應及時。
來上幾次就可以由銷售出面談維護或者二期之類的事了。這樣就賺到了。
即使軟件還有很多問題一樣可以繼續操作。
4、對付領導/老闆
要對付領導，首先要學會站在領導角度看問題。
其實做領導也挺不容易的，聽話的手下往往能力不夠，能力強的
手下往往不太聽話。
因此做領導的最希望手下能力又強又聽話，什麼事情交下去就完
全搞定，而且效果很好。
當然領導也不是笨蛋，也知道需要提供必要的支持，他也不會逼
死你。但是他會認爲在他合適的時候來逼你。
什麼都不懂，只會壓榨下屬的領導往往也沒什麼前途，當然如果
他是老闆的親戚就例外，如果跟了這種領導就只好認倒黴了。
在國內，絕大部分是樹型管理架構，因此這裏主要針對樹型管理
架構，矩陣式的可以自行類推。
作爲項目經理，一般接觸的主要領導就是部門經理了。如果公司
比較小，也可能接觸總監/副總甚至總經理。
對於項目經理來說，部門經理有兩個身份。
一方面，在整個公司裏，部門經理是項目經理的上級，直接掌握
項目經理的獎懲，尤其是獎金和升職（我想絕大多數人都希望錢多職
高吧）。
另一方面，對於單個項目來說，部門經理又是項目經理的後盾，
提供項目所需要的人力、物力甚至財力，以確保項目的完成。必要的
時候需要請部門經理出面進行較高層次的協調。
對於軟件開發來說，最關鍵的就是人。尤其是在一個部門中有多
個項目在進行的時候，這個時候一些能力比較強的人肯定是稀缺資源。
大家都要搶的。
我想做項目經理最痛苦的莫過於自己團隊中的主力支援其他小組
去了，結果最後領導還怪你項目沒做好。
那麼如何爭奪人才呢？有以下要點
1）自我定位。
我在部門中，在領導眼裏是什麼地位？
我手頭目前負責的項目在領導心中是否重要？
這個項目做好了對部門，對領導有什麼好處？
這個項目做壞了對部門，對領導有什麼壞處？
如果這個項目不是關鍵性的項目，那麼就要有使用較差人員的
準備，硬要去和關鍵項目搶資源是絕對沒有好處的。
如果這個項目是關鍵性的項目，那麼就要充分估計風險，獅子
大開口一些，點名要人。
一般是否關鍵性的項目只要看看客戶是不是大客戶，合同金額
多不多就行了。
2）瞭解他人
至少要知道公司裏面哪些人擅長什麼，哪些人什麼時候有空，
這樣可以有的放矢。
這個需要日常和別人搞好關係，而且要了解其他項目的進展情
況，包括即將啓動的項目。
3）掌握時機
向領導要人是要看時機的。
要的太晚不行，一旦給別的小組捷足先登，則除非你的項目特
別關鍵，否則就只好揀剩下的了。
要的太早也不行，因爲如果要來了人沒事幹，那麼就會給領導
造成不好的印象，下次要人就困難了。而且會讓領導質疑你的管理
才能。
個人建議是項目初期啓動的時候大概的估算一下，然後調研一
段時間以後再稍細的估算一下，到需求比較明確的時候就要出很詳
細的計劃，把要多少人都列清楚。
要有個一兩週的提前量，一般情況下都會有一些拖延的。
然後就催着領導落實這個計劃，只要計劃沒落實，就要一直催
，當然催得時候要注意方式方法。
另外，到了項目後期，也要注意及時的釋放人力，不要佔着人
一直用。這樣領導就會對你留下個好印象。
如果有別的項目差不多時間啓動的話，一定要比對方快那麼一
點點，即使只是一天。
4）方式方法
前面三點都是戰略性的，這一點就是戰術性的。大多數情況下
項目經理去要人，都很難得到完全滿意的結果。
個人認爲有以下幾點需要注意：
a、準備充分。至少要有一份比較詳細的文檔，對現階段進行
總結，並給出大致的計劃，然後提出人員要求。
b、人員質量要求。對人員的質量應該有所要求，一個高手和
一個新手差別極大。如果已經看中部門中某個人了，則可
以按照那個人的水準來套，引誘領導往那個人的方向去考
慮。只要領導說一聲，“那xxx你覺得怎麼樣？”立刻就
說“好啊好啊”，領導再想反口也來不及了。
c、討價還價。其實向領導要資源也就是和領導談判的過程，
本質上和小菜場討價還價差不多。項目經理是賣方，領導
是買方。你要讓領導相信提供資源可以買到項目的成功。
但是領導會在多個方面上進行挑剔，甚至可能召集其他人
來一起評審你的計劃。一般情況下項目經理的要求總是
會被砍掉一些的。
因此有時要稍稍高開一些（但也不能太過分了，很容易就
會被別人拆穿的），以給領導砍價的餘地。
d、軟硬兼施。此招慎用
如果領導比較開明，你在公司的地位比較高，有的時候也
可以撂狠話，不滿足我的要求我就沒辦法作這個項目經理
了！
說這種話的時候要注意給自己留好臺階，避免留下不良後果
以上種種只是一些輔助性的措施，最關鍵最首要的前提還是本人
水平夠高。如果本人水平不夠，再好的人才到手裏也只是浪費，
那還不如給別人用呢。
5. 任務分配
進行任務分配時應當注意任務之間的耦合程度以及任務的內聚程度，以減少項目內耗。儘量做到低耦合，以降低對成員之間交流的依賴程度，讓大多數成員（需要把握全局的骨幹成員除外）無需考慮太多繁雜的、不相干的東西；儘量做到高內聚，讓成員可以儘量發揮他的能力以及已經獲得的項目相關信息。
如果工作量實在太大，或是工期要求太緊，不得不把高耦合工作分給多個成員負責，這時候就要特別注意成員間工作相關知識的同步的問題。
要給所有成員一份詳細的工作內容說明，並要注意所有成員得到的相關資料的一致性。在所有成員都做好自己工作的有代表性的一部分的時候，要把這些成員集中起來進行一次review，以消除成員之間知識／理解上的差異。如果在開發過程中出現了需求變更，則要及時通知與這部分需求相關任務的負責成員。做一個簡明的變更索引，按索引定期review，以檢查變更的落實情況。
如果由於成員調度、個人進度、需求變更、以前遺漏的任務或者某種不可抗力等原因，而不得不更改任務分配，這時候一定要考慮如何最大化地利用項目人員已經做過的工作、已經獲得的項目相關信息，儘量減少任務更改而引起的交流、培訓和再教育花費。
6. 成員教育
在成員的教育上要注意知識層次上的連續性，切不可出現斷層。每個層次都應當有足夠的候補要員，以便在非常情況下在層次間流動。
在項目的早期，要全力打造幾個能深刻理解全局的骨幹成員，以在關鍵時刻減輕leader的工作壓力。如果項目時間允許，早期加入到項目的人員可以適度拔高，讓他們參與一些稍高於他們現有能力的工作。可以與他們一起理解需求，讓他們參與分析模型的評估。由於有較長的時間來驗證他們對知識的理解，相對來說可以比較放心。但是也要儘早檢驗，以減小修改錯誤的代價。
而對於項目中後期加入的成員，不必讓其瞭解太多的全局知識，儘量讓其負責單一的工作。此時需要注意把對知識剪裁的尺度。什麼樣的知識是必需的，什麼樣的知識是需要大概瞭解一下的，什麼樣的知識是完全沒有必要的。這些都需要leader仔細地斟酌。由於是中後期加入，應該在第一時間驗證他們的任務相關知識的正確性和準確性，以保證最終產品的質量。