專案第一階段結束，各個組員也在自己學習相應的知識，沒有人催促他們去學習，也沒有人上網聊天看電影之類的，這樣一個氛圍的形成，和專案組中專案經理有很大的關係。我本人也是敏捷的擁護者，恰好今早看部落格園時看到兩篇文章：有些感慨很想寫下來與各位分享一下。
第一篇：敏捷中的溝通與故事點
第二篇：親愛的專案經理，我恨你
第二篇是今天的推薦新聞，笑點很多也很讓人沉思
一、專案經理在專案中究竟是什麼角色
國內的氛圍是“學而優則仕”，放到軟體開發領域也是一樣，不少開發人員嚮往管理崗位，一是覺得技術領域日新月異，學習上感覺吃力；二是長江後浪推前浪，前浪死在沙灘上，技術上新人更有一股狠勁，而年紀大了的開發人員面臨婚姻、子女、父母的諸多問題難以拼命了，身體也大不如前；三是幾千年的文化形成要做人上人，必須管理人的觀念。
上述三個方面沒有對錯，我只想說如果你對技術沒有持續的熱忱，你想向專案經理或管理領域發展時，就要明白專案經理這四個字背後的含義。
1、 專案經理的心態
永遠不要將自己做為一個傳統意義上的管理者（決斷、控制、平衡），傳統領導力在IT企業裡是玩不轉的，一群高智商的員工普遍有著自己的驕傲和尊嚴，你的能力再突出，能比得上所有你的小組成員的累加值嗎？
專案經理永遠在心裡要告訴自己“我是一個服務者”，認識到在IT企業裡，員工需要的是新的領導力（決策、協商、服務）。
講個小故事，有點偏頗不常見，但也許能讓大家有一些共鳴：
以前有個加、美、印和離岸外包地（中國）的合作專案，加國派來一個需求分析師，米國派來的是個協調人員（大家可以看成專案助理吧），阿三國派來的是個架構師。帝國本部選一個“技而仕”的專案經理來主持這個專案。加國是個大漢，語速快手勢多，米國是個大叔，精幹語少但常常關鍵時候發炮攻擊，阿三比較隨和但常常有些莫名其妙的優越感，對反對意見完全聽不進去。四方開會的時候，讓我想起了我現在團隊裡一個兄弟愛玩的四國軍棋，充滿了地雷和詭計，常常一個會幾個小時下來，各方都沒有達成一致。加國大漢憤怒地寫了好幾封公開郵件指責團隊效率低下影射攻擊專案經理，米國人看不起阿三，在技術上攻擊不了阿三隻好說這個團隊完全不知道業務，阿三指責團隊合作力不足。總之是一團亂賬，可憐的專案經理完全沒見過這陣勢，自己團隊精心提出的架構，阿三總是挑鼻子瞪眼，需求更是完全沒有邊界，不知道加國大漢是想要什麼，米國人到是悠閒反正他是代表甲方的，一副看好戲的樣子。公司沒辦法，專案經理搞得想辭職，團隊成員更是被激起了憤青的情緒。最後迫於無奈，公司把一個副總委派下來直接擔任專案經理，原專案經理作為該專案的技術經理。
這個副總一下來，在團隊會議上沒有指責任何人，只是笑眯眯地說“兄弟我是門外漢，對技術一竊不通，各位都是專家，我的主要職責就是服務好大家”。會後，這個副總搞了幾次聯誼會，帶著大家搞野餐、郊遊、親子聚會，工作時不遺餘力的安排大家的後勤，每天下班前都會問大家第二天的茶點和水果安排。私下裡呢，和米國人的上司溝通了幾次，對專案中的風險進行了分析，要求米方更多地對需求進行干涉和確認。沒過一週，團隊的氛圍正常了，加國大漢發現自己的奇思妙想的需求被米國人攔了幾次後也放棄那些不著邊的想象力了，米國人也收到了上司的郵件要求他確實的擔負起需求確認的責任，阿三在副總的幾次遊山玩水和推心置腹後，也老實了，對於架構的事也沒那麼吹毛求疵了，專案組間的溝通基本上正常了，專案總算正常推動了。最後專案結束的時候，這三個老外懷著感激之心離開，連連說還要再來偉大美麗的中國。
這個專案裡，專案經理完全不懂技術，他的理念裡只有“服務”這一個詞，專案的進度當然是他關心的，但專案的質量和成本他完全放手給專案組成員去做。
關於專案經理需不需要懂技術，見仁見智，但我覺得專案經理懂技術不是壞事，特別是國內目前中小型專案居多的情況下，專案經理完全不懂技術很危險。
新的領導力，核心就是一句話“我能為您們做什麼？我還能為您們做什麼？我有什麼可以幫助您們的嗎”，在中國，領導自然而然地就會有一些威嚴，你只要時不時的嚴肅一下，大家會知道你的威嚴，但這個“信”字就不是這麼容易建立了。如果你不把自己當一個服務者，而是一個控制者，試問誰喜歡在這樣的領導手下做事，IT本就是一個講究創造力的行業，守著一個只想流水線生產程式碼的領導，工作有樂趣麼，個人有成就感麼。不好聽地說，這叫死氣沉沉。
2、 專案經理的意識中要有決策而不是決斷
專案經理永遠是一個指導者而不是皇帝。
今早園子裡的敏捷中的溝通點與故事點中有這麼一段話
首先，任務分配這件事情是我一手包辦了，我和團隊成員之間仍然是分配與被分配的關係，這和敏捷的自組織相牴觸。其次，我分配出來的任務迫於時間的壓力，欠描述，和敏捷提倡的故事點有距離，通常就一句話或一張圖片。團隊成員要處理這些任務，有時還要和我進行進一步的溝通。當然，這個過程還算有效，畢竟我已經用這種方式成功地完成了數不清，各種規模的專案了。
說實話，這種方式培養不了優秀的開發人員，只能培養沒有主動思考的程式碼機器。好的方式是，哪怕你和客戶談個普通優先順序的需求，你也需要把你的關鍵組員帶著去，一方面可以讓大家集思廣益瞭解需求，一方面可以鍛鍊你的組員的溝通，一方面可以讓客戶與小組的關係更融洽。
在親愛的專案經理，我恨你也有這麼一段話，我本人很認同：
你是一個資訊黑洞
你更善於積極跟你的上級管理者交流溝通，而不是跟你管理的團隊。結果，重要的專案資訊根本存不到你腦子裡，只有在一些特殊時期，通常是上線最後期限的前幾天，你才會關注。上級管理者和開發人員之間出現了一堵牆，你就是阻擋資訊流通的那堵牆。
要知道你領導著一群渴望成長、渴望成就的員工，他們是你的支撐是你的財富，金錢都有個槓桿效應更何況活生生的人，你不能發揮他們，這些人遲早會離開你。錢要發揮效應必須會投資，人要發揮能力必須要讓他們嘗試和主動。而如果你做的事是想像流水線的富士康一樣的工人，那你的團隊必然是一群呆頭鴨。
專案經理要做的事是和團隊一起決策而不是獨自判斷，你甚至要學會授權在細節上讓團隊擁有充分選擇的權力，在無關緊要的技術細節上你考慮的越多，你給他們的限制就越多，你只要對架構、高優先順序需求、質量和進度多加關注就行了。準確的說，專案經理是團隊的“核心交換機”，你這裡的傳遞的資訊量越大，專案和團隊的受益才會越大。
二、專案經理與客戶的關係
既然是核心交換機，專案經理與客戶那裡更多的就象是一個防火牆，防止需求越界，防止客戶的攻擊傳遞到團隊內部，軟體開發團隊的士氣很容易受打擊，開發人員也有生理週期，一個有趣的現象是，呆得越久的團隊，其生理低潮也越同步。
專案經理和客戶的負責人，應該是合作的關係，大家利益一致是要專案經理時時保證和提醒對方的，畢竟對方也是人，也想在企業內樹立政績，保不準頭腦發熱提出一些天馬行空的想法，這些想法不要急著去否定，按事實一條條分析，按技術一條條陳述。實在不行，出來吃個飯，洗個腳，坦誠相對一下（先說我很討厭聲色犬馬那套，我和客戶一般就是吃個飯喝個灑），很多問題在感情因素的影響下會獲得一個平衡。
要明白，你和甲方的負責人永遠不是博弈，而是利益的共同體，一榮俱榮，一損俱損。
而專案組內部，你這個防火牆要傳遞的是客觀的需求和評價甚至批評，甚至你要把你內部那些組員帶出來到防火牆外測試一下，經受一下客戶的考驗，回來後他們會更理解客戶（人）而不是軟體（程式碼），軟體是給人用的，不是給機器用的。
三、專案經理與公司的關係
專案經理是公司的為將者，為將者對公司要服從大局，多站在老闆的角度考慮，當然為將者，也要有將在外，君令有所不授的覺悟。專案經理不要倫為馬屁精，那樣與專案沒有半點好處。要學會經常彙報，學會爭取資源，學會向老闆提出問題並根據問題拿出A、B、C幾套解決方案供他選擇。學會時不時的參政（不要議政）。
好了，大致上我的感慨發完了。
專案經理不是傳統意義上的管理者，他是教練是指導者，他的作用在於發揮成員的能力，與客戶做好溝通，把握專案風險及時預警和解決。
專案經理對進度、成本、質量負首要責任，但你要學會授權。
專案經理適當地要掌握技術，保持coding everyday的習慣。
專案經理是團隊的靈魂，要學會給團隊成員打氣和招魂。
專案經理是孤獨的，團隊成員不可能成為你真正的朋友，公司高層也不能。
專案經理這條路不是終點，前方的路還很長。