【文章內容簡介】 多的時候；其次是 1 對 1 的溝通，與下面的項目經理和團隊成員 進行面對面溝通，可以及時了解項目進展、團隊成員的思想波動，有針對的為其提出建議、解決方案，讓團隊成員感覺到項目經理的人文關懷，并傳達公司的溫暖；最后是避免不了的項目活動，聚餐、爬山、電影都是很好的活動方式，這取決與項目經理的權限和公司的財務制度。 8 組織能力 ： 這里的核心團隊是指子項目的項目經理和關鍵技術人員，具體視不同的項目規(guī)模而定，人員的管理和溝通是有成本的，我個人認為 35 個人比較合適，太多的人員太多的細節(jié)靠一個人有限的精力是無法進行跟蹤和控制的；當然這里的核心團隊成員是指那些 技術和架構水平高超、有一定的項目管理能力、善于團隊協助的人；核心團隊成立越早越好，有利于項目的穩(wěn)定和提前進入角色。如前文中所述，不善于團隊協助的人只能帶來負面效應。 協作能力主要表現在項目內部各團隊之間的協作、與公司內部其他團隊的協作，與項目相關的友商的協作能力上。 軟件工程 ： 軟件工程按照傳統的理解即需求分析、系統設計、系統開發(fā)、系統測試，這對項目經理而言是最起碼的要求；就大部分國內項目而言，項目經理還是要樣樣都懂一點的，我不太贊同工作 3 年就自命不凡擔當項目經理的人，技 術、業(yè)務、人際關系的把握的積累都是需要時間的；當然外企也有職業(yè)的項目經理，他們可以不專技術，而專注過程。 軟件過程能力（ Software Process Capability）：描述了在遵循一個軟件過程后能夠得到的預期結果的界限范圍。該指標是對能力的一種衡量，用它可以預測一個組織（企業(yè)）在承接下一個軟件項目時，所能期望得到的最可能的結果。IT 企業(yè)有自己的軟件能力成熟度，當然個人也有自己的軟件能力成熟度，即體現在個人對過程的定義、監(jiān)控、跟蹤和度量上。本人有幸在 3 家 CMM5 的公司工作過，不過仍稱不上對 CMM 有多 深的研究，一來過于繁瑣，再則軟件能力成熟度 9 與所在的 IT 環(huán)境有密切的關系，過程的實施和度量需要一系列的保障；事實上嚴格遵循 CMM 流程的企業(yè)并不多，基本上都是為了內部評估而評估的；不過基于過程的思想值得項目去參考和學習。 關于本項目的話，如果一定要說有什么軟件能力成熟度的話，我認為是 2級吧，項目管理的基本流程和系統文檔已經有了，做類似的項目是具備一定的復制性的。 4. 架構能力 系統架構，這個與項目經理的角色和定位有一定關系，項目經理需要從整體上把握系統的各個環(huán)節(jié)，硬件、操作系統、數據庫、軟件、軟件框架、甚至測 試，都需要有所涉獵，能做到一精多專已經是不錯的狀況了 。 系統集成，這項能力與具體的項目有關，對于小項目來說只需要完成相應的業(yè)務功能，對性能的考慮、系統擴展型、系統部署、外圍系統的接口要求并不高，所以對系統集成考慮的較少；如果實施大中型項目的話，項目經理最好具備起碼的思想和評估能力。 關于系統架構、系統集成能力的提高，需要本身知識儲備的日積月累、閱讀大量的相關資料、以及項目實施過程中的學習，除此之外，別無辦法。 5. 技術學習 項目經理需要的一個最基本的能力便是對他們的基本技術技能進行深度和廣度的拓展。目前的 技術知識更新換代過于頻繁，但技術本身的內涵確實恒久不變的。如 Oracle 從 9i 到 11g，其 Concept 變更的并不多，其基于關系的數據庫特性在短期內還是無法改變的；如 java 和 . 之爭，其核心仍是面向對象的；如各技術框架之選型，無非是實現展現層、業(yè)務邏輯層、控制層、數據持久層的分離；適當的擴展自己的技術能力也是與時俱進的一種體現。 10 6. 業(yè)務學習 相比技術而言，業(yè)務是更難學習的，尤其是財務、 ERP、金融證券業(yè)務等，與 IT 背景相距深遠，但是又不能不學，作為項目經理需要與甲方業(yè)務方進行溝通，缺乏相關知識背景 ，會造成溝通上的鴻溝，甚至無法理解對方的意圖。當然并不是說項目經理一定要成為業(yè)務專家，事實上也是不太可能的。 7. 文檔能力 項目經理一定要會寫，這是由項目經理的工作性質所決定的，從解決方案、系統架構、需求文檔、驗收文檔的編寫，到設計文檔、測試文檔的規(guī)格要求，無不打上項目管理人員的烙?。蛔珜懳臋n是組織自己思路進行深層思考的過程，如果文檔無法表達明白的話，相信自己的思考也一定不成熟；撰寫文檔也是溝通的需要，會議紀要、需求文檔如果寫的不清不楚的話，雙方如果進行確認？想清楚才能寫明白這是很簡單的一個道理。 項目 經理的能力依據項目的規(guī)模和公司的成熟度有不同的要求，不能一概而論；舉例而言，在本系統中假設時間為 100 的話，各項過程所占的比例分別如下： 圖 21各個過程所占比例圖 11 3 管理平臺系統項目組織結構 如果你處在一個專業(yè)的 IT 公司，你未必會意識到項目組織結構對 IT 項目管理的影響，因為在大多數的專業(yè) IT 公司中，基本上都是項目型組織或者強矩陣型組織結構，在這樣的組織結構中，項目經理對項目全面負責，對客戶高度負責，項目團隊工作精力集中，協作強，溝通效率高，你會感覺到項目經理的權威和職能至少還是有保障的。 假如不幸你處于職能型組織或者弱矩陣型組織中，有時候你會感覺無所適從，人力資源的獲取、管理、考核都無法正常開展，你會發(fā)現自己置身于一個弱勢地位，團隊建設有時會變得癱瘓，嚴重一點會影響團隊合作甚至拖垮項目的總體進度 。 圖 32團隊結構圖 如果你要尋求合適的資源，首先需要向了解各個部門內部合適的人選，然后征求個人的選擇和看法；其次與其直接匯報經理進行溝通，看該資源是否能全身投入；再次協調不成需要向上級領導進行匯報；需要經過層層溝通。 其次關于考核和沖突管理，關于考核，在弱矩陣型組織和職能組織中團隊成員的考核是由匯報經理決定的， 這也決定了項目經理作為管理者的弱勢地位，無法實施項目經理正常的權限， “ 要敢管 ” 就完全成了一句空話，更有甚者會出現團隊成員未經允許擅自離隊的情況；團隊有合作也有矛盾，不同的團體之間也會 12 有矛盾產生，通常管理者會站在自己成員的角度進行所謂的護短行為，如前面所述，嚴重的影響了項目經理的積極性和整個團隊的和諧和建設。 解決辦法：如果無法改變 IT 部門的組織現狀，則至少保證現場項目經理的權威，現場的團隊管理應由項目經理全權負責，其次考核應該由項目經理和匯報經理雙方共同決定，再次建立一個仲裁組織，對項目中遇到的沖突進行決策 。 4 管理平臺項目風險 項目風險管理是指對項目風險從識別到分析乃至采取應對措施等一系列過程，它包括將積極因素所產生的影響最大化和使消極因素產生的影響最小化兩方面內容。 風險識別 確認哪些風險有可能會影響項目進展，并記錄每個風險所具有的特點。 風險量化 評估風險和風險之間的相互作用，以便評定項目可能的產出結果的范圍。 風險對策研究 確定對機會進行選擇的步驟及對危險作出應對的步驟。 風險對策實施控制 對項目進程中風險所產生的變化作出反應。 本文無意討論項目風險管理的一般流程和相應的控制，只是根據項目中 所遭遇到的問題把自己的一點心得體會表達出來，很多在其他人眼中也許算不上風險，有一部分甚至超出了項目管理的外延，但對于部分 IT 企