專案管理需要的知識，是乙個體系的知識，包括專案管理本身的知識體系，以及專案管理要應用到的領域所需要的知識體系，然後就是管理的技能，當時最重要的，是軟技能，也就是人際關係技能。
管理的核心：人。
管理的四大要素：
1. 選擇正確的人
2. 為他們分配正確的工作
3. 保持他們的積極性
4. 幫助團隊凝聚起來並保持團隊的凝聚力。
1、 選擇正確的人
首先要學會看人。雖然我不是人力資源專家，但是我清楚乙個軟體專案的成功所需要的成員素質，主要就是溝通能力和責任心。
由於工作需要，我面試過一些人，有畢業生以及有工作經驗的，有各個大學的，大專生和本科生。我就開始學習如何考察乙個人是否符合團隊需要。
一般來說，面試的時候，問題有職業生涯規劃是什麼，未來期望在公司獲得什麼樣的成長，對軟體工程的認識，對自己的職業技能的描述，這都是常規問題。比較重要的是，我對每個人都會問，是否有團隊開發專案的經驗，不過大多數都沒有。而且在大學期間，有完整作品的學生也比較少，大多數是作業。
乙個人的氣質型別都不太一樣，有說話比較快的，也有說話慢條斯理，有自信心滿滿的，也有膽小的。管理要根據每個人的不同性格特徵來進行管理才能獲得成功，所以管理人員必須研究人的心理學。
初步面試完畢，進入試用，就要考察他的主動性。《把信送給加西亞》裡面說到，別人沒有叫我們就主動去想事情做，那樣獲得的回報是令人敬佩和羨慕的，別人叫一次我們就去做，那樣獲得的回報是可觀的，別人叫兩次我們才去做，那樣獲得的回報是社會平均水平，別人叫三次才去做，獲得的回報是微薄的，別人叫了多次才去做，那樣不僅僅沒有回報，反而會被人責罵。但是最終結果都要去做事情，我們何不主動些呢？
有些人就等著分配任務，然後完成任務，領工資，根本沒有去為公司著想，為自己著想，這種人只能永遠被人利用。有些人會想辦法改進，並且經常有好的創意，這種人最終會獲得成功，因為他主動了。我們選擇的人要選擇比較主動，能夠及時領悟公司的任務並且及時去做甚至改善的人。所以選擇人是一門學問。
2、 為他們分配正確的工作
分配工作是很容易的，但是要做到正確分配工作就有學問了。
我進行分配任務的時候，剛開始是任由他們自己決定要做什麼，然後我再綜合的進行乙個整理，後來發現這樣子任務並不能分配的較為合理。接著就是我自己給員工分配任務，後來發現，這樣子分配的任務員工有些接受不了，例如時間，技術難度等等，員工往往會有情緒。
所以總結了以往的經驗，分配任我採取了巨集觀控制加上微觀調整。首先我要明確的知道每個員工的各項知識技能水平。我製作了知識技能水平考核表，以此來把握每個人的技術水平，接著，根據專案縱向劃分成各個模組，模組的大小以及數量是有講究的。每個人都負責從表現成到資料訪問層的編寫，這樣做好處第一是可以讓大家把握自己專案的框架，培養員工的專案管理基本知識，第二是避免按層次劃分中出現的互相扯皮現象，比較適合於創業型企業的中小專案。然後根據員工以往的專案經驗，讓每個員工談談對各個模組的認識，以此來推薦他做什麼模組。員工對感興趣的模組會說的比較多，比較有見解。接著再根據他們的以往的程式設計經驗，速度，定出兩周內要完成的任務，不能定太多週，因為專案剛剛開始時無法預知進度的。
分配正確的任務的要點，就是最好要先集體說明一下專案的各種需求，讓每個員工知道這個專案的規劃。接著要單獨的和每個員工談話，讓他做喜歡的工作。如果出現衝突，我就在中間起協調作用，讓大家分別談談對專案的了解和建議，以便知道某個人想做這個模組的動機是因為認為比較簡單想讓自己的工作輕鬆一些，還是認為比較難有挑戰性，想挑戰自己的技術高度。接著再根據他以往的專案經歷，來說服他做他擅長的模組，以便提高專案的成功率。因為專案管理中很重要的乙個原則是，乙個成員做的工作，應該是重複過去成功的專案經驗，而不是挑戰他的技術高度，否則對專案是有害的，會導致專案失控。也就是說他個人的技術水平可能得到提公升了，但是這是以專案作為他的試驗品為代價的，這個人的提高只能在下乙個專案中體現出來，正所謂前人栽樹後人乘涼。
分配任務的時候要非常謹慎和小心，因為往往公司員工比較不敢對領導提出異議，所以就會造成任務完成質量不高或者不能按時完成，使專案管理無法按計畫進行，這是我最深刻的體會。在團隊成型初期，我們必須按照一定的難度和數量來分配，並給予足夠的技術支援和幫助，在做的過程中要不斷跟蹤，等到團隊成熟以後，對專案進度的管理將會越來越順利，越來越準確。
3、 保持他們的積極性
首先，人的積極性是個很有趣的東西，把握拿捏不好分寸，就會影響到乙個人做事情的積極性。
在這裡我引用一段很經典的x,y理論：
x,y理論可以用來分析乙個經理的管理行為，如果這個經理的思想是x理論的思想，那麼他就會採取比較強硬的措施，例如軍隊式的管理方法。這種經理就會用各種嚴格的規章制度來強迫人們進行工作，觸犯了規章制度就會受到經濟上的懲罰。我認為這種管理方式只適合一些標準化操作程度比較高的企業，對於軟體行業來說，人才得到了極大的重視，近期人才流動性較大，員工的個性也比較強烈，無法應用這種強硬的措施。
人較低需求層次是生存，高層次是自我實現，在軟體行業中，生存已經不是問題，每個人都抱著自我實現的目標而奮鬥，所以我認為在軟體行業中採用y理論比較適合，即一定要讓員工參與到決策中。舉個例子，有乙個員工曾經向我抱怨，沒有讓團隊的人參與一些事情的決策，他覺得不像團隊，做事情效率比較低下。所以要讓大家有積極性，就要讓人感覺，這個專案是大家努力的結果，是大家團結的結果，而不是某乙個技術牛人的結果。
我曾經在專案管理中採用了兩種方法，一種是比較自由的方式，就是劃分好模組，規定好一些專案規範以及介面規範，至於需求等等實現等等由大家一起自由發揮，結果效果一般。第二種就是完全由我控制，我規定好需求，規定好介面，甚至細化到每天要做什麼，結果更加失敗，員工感覺沒有自由了。程式設計師和藝術家一樣，既要有條條綱綱的限制，又要有一定的自由空間，所謂帶著枷鎖跳舞就是這個意思。所以作為專案經理必須把握好管理的鬆緊度，根據員工個性的不同來拿捏分寸，這需要經過一定時期的積累和磨練才能夠爐火純青，畢竟，管理也是藝術，需要悟性，不是從書本上就能夠學得到的，要讓如此複雜的人保持積極性，管理人員要付出更多的努力。
4、 幫助團隊凝聚起來並保持團隊的凝聚力
光光人的積極性還不夠，每個人的用力方向還必須一樣才能發揮團隊的能量，團隊是有乙個生命週期的，分別是形成，躁動，穩定，表現。我在大學期間建立的團隊就經歷了這些階段。那麼在專案管理者面臨的問題就是，如何使團隊順利經歷這幾個階段，盡快達到表現階段。
當團隊形成的時候，一切都是新鮮的。我們團隊嘗試性的做一些任務，尋找哪些人比較合群，並且了解大家的性格以及特長。因為團隊形成的時候，大家的工作熱情比較高漲，但是容易出現焦慮，因為在團隊中，他們的定位都不明確，所以作為團隊的管理者在這個階段應該做的是建立團隊文化，例如團隊名稱，口號等等，甚至連什麼時候開會，什麼時候往也要事先有個規劃，然後讓團隊的人之間互相充分的了解，然後做一些合作的工作來讓大家了解在這個團隊裡面應該如何進行溝通協作。
接著當團隊的目標和結構慢慢的清晰了以後，隊員們開始躁動，開始關心自己的職責和權利，例如自己在團隊裡面負責什麼模組等等，專案經理就要在這個階段解決和協調隊員之間的種種衝突，制定好規章制度和一些做事情的流程，並且傾聽隊員的不滿。
然後團隊漸漸穩定，生產力不斷提高，專案和隊員的能力穩步增長，目標清晰，成員之間已經形成乙個整體，那麼到這個階段專案經理就比較輕鬆了，只要進行一些團隊之間的關係處理，以及讓大家進行一些重大決策就可以了。最後乙個階段就是表現階段，那麼這個階段我認為是豐收階段，團隊成員配合已經到達非常默契的程度，基本上不需要頻繁的交流，一切都有現成的流程，效率空前的提高。我經歷的團隊中最後達到這個階段，開發效率令人感到非常滿意，僅僅用了兩個多月就完成了乙個與我們以前快1年的專案差不多複雜的東西。
所以專案經理的職責就是在團隊的各個階段為團隊保駕護航，保證大家的凝聚力，讓團隊的成員時刻充滿責任感和自豪感。
總結管理人員處於團隊的中心，對管理人員本身的素質要求都比較高，而且管理人員與其他人員之間的關係也尤為複雜，屬於圓心和圓周的關係，一旦處於圓周的人想靠近或者疏遠管理人員，那麼管理就不能圓滿，管理人員對待所有人應該都是平等的，包括績效考核，表揚與批評，個人關係等等。如果出現不平等就會有流言蜚語出現。
管理有很多任務具和方法，這些都是通過學習的，唯有對人的管理，是屬於軟技能，需要一定的經驗和悟性，需要管理人員對日常的小事情進行思考，總結，對自己處理事情的方法要進行合理性的評估，對每個人的個性要充分了解，對不同的人要用不同的管理技巧，不能搞一刀切。總之管理是為目標服務的，只有專案成功了，管理人員就是成功的，專案經理必須為這個專案負責！
參加專案管理培訓的一些體會
連續4天一直在參加申信的專案管理培訓。開始僅僅當做一次工作之餘的歇息散心，4天堅持下來，發現還是有一些收穫。最大的收穫是改變了我的專案管理沒有系統方法，僅僅有自我摸索的偏見。的確，專案管理沒有放之四海皆準的真理，也沒有一招鮮走天下的偏方秘籍。有的，僅僅是美國幾百年的管理經驗總結。回憶起幾年前，第一次...
當專案組長的一些體會
原來乙個bbs上自己寫的一些東西,在這裡發表一下,應該不算盜版吧.希望對其他開發人員有幫助.對組員負責 要做乙個專案負責人，首先要做乙個好人。最自己負責，對領導負責，對組員負責，而如果想形成乙個好的團隊對組員負責是乙個關鍵的問題。93年我第一次帶團隊的時候，我們在江蘇開發乙個專案，有一次，我的領導找...
一些專案管理心得
最近負責的市政數字報建專案快結束了，記下一些心得 對於中小型專案，最好不要使用常規的軟體工程方法進行開發。建議前期採用迭代開發，後期採用測試驅動開發。專案一開始，就要搭好以下文件的框架，隨專案進行中，不斷修改 補充和完善。1 需求規格說明書 甲方負責。詳細記錄整個專案的需求。特別是專案過程中，一些需...