專案管理總結02(10.30)

在前面將自己知識經驗積累的時候曾經談到過，自己從開發，架構，到需求，再到IT專案經理，大專案經理，基本一路從技術線發展上來。從04年開始過CMMI2級對軟體過程改進和專案管理知識有了較為體系化的理解和認識，到06年正式考過PMP認證，再到從做內部IT專案到做外部的集團型大型IT專案，整個實踐和知識積累過程也為自己後期的專案管理打下了堅實的基礎。

也是自己經常會強調的IT專案管理更多是技術+管理，只懂技術不懂管理無法把控全域性，無章法，同時溝通和協同混亂；而只懂管理不懂技術，則是寸步難行，更加重要的時候關鍵風險問題無法識別和解決。把合適的人安排在合適的位子上，並相互之間高度協同起來，看似簡單，實則困難。所有的識人，用人，激勵人全部圍繞這個目標而展開。

專案失敗你可以回顧下，要麼是沒找到合適的人，要麼是人沒在合適的位置上，要麼就是人和人之間的溝通，上下游之間的協同出現了大問題。看似技術類問題，實則人的問題。

為學日益，為道日損

如何理解這句話呢？我原來經常會舉個例子，比如你去爬山，你爬到半山坡後你有兩個選擇，一個是走上腰的一條平路到對面山坡，還有就是你要爬到山頂然後再下到對面山坡。可以看到兩個選擇最終你都到達了對面山坡，但是效果卻千差萬別。

上到山頂，再下到半山腰就是一個為學日益，為道日損的過程，該做的實踐全部做，該體系化學習的至少體系和框架全部學習。這是一個為學日益的過程，當你真正實踐完成，並經過體系化的學習完成後(比如考PMP認證），這個時候你開始做為道日損的過程，即既不會忽視關鍵的方法論和思考方法，也不會生搬硬套各種計劃和模板，而是知道如何因地制宜，因時制宜，真正抓住一個專案的Key Point，用最恰當的方法，技術和工具來進行管理。

舉個例子來說，最近這個大專案，包括前期的很多大專案，我已經很久沒有說要真正去按部就班的計算關鍵路徑，再安排資源，原因在哪裡？一個是專案是受資源約束關鍵路徑法不管用，其次就是專案的重點往往並不在關鍵路徑計算上。但是這些都不代表你做不好專案管理。

所有的方法和工具，都是協助你做好專案管理的，不是最終決定你專案成敗的。你要渡河到彼岸需要坐船，但是到了彼岸一定不要死拽著船不放，而忘記了真正的目標和方向。

倚天屠龍記裡面，張三丰教張無忌太極拳也是同樣的道理，最後招式要全部忘記掉，那是否就完全不要教就完事了？答案顯然不是，教和學的過程是為學日益的過程，融會貫通後逐漸遺忘，不要拘泥於招式這個形而真正在神上得以領會是為道日損的過程。

所以實踐一段時間後，該體系化學習的方法論和知識框架還是要學，但是最終則是無形勝有形。

干係人管理和平衡

對於IT專案管理的核心前面一篇文章已經多次強調了是對團隊和人的管理，再擴充套件一下還包括的就是對干係人的管理。這個干係人包括了甲方的客戶專案經理，高層領導，甲方終端使用者。特別是對於ESB專案還包括了業務系統合作廠商，這些本身都加強了干係人管理的難度。

干係人管理難點就是如何在各個干係人的述求和利益之間尋求到一個真正的平衡點。

沒有找到這個平衡點，專案很難真正推進，舉個例子來說，對於ESB這種大整合的專案，你只把甲方使用者的述求滿足好肯定是不行的，諸多的業務系統的述求無法滿足，專案實施的時候業務系統不配合你，或者明裡配合，暗地地不配合，這些都將導致專案最終失敗或延期。

在干係人管理裡面，規則很重要，簡單來說就是先說斷，後不亂，先把規則制定清楚。這個規則就是專案實施的方法和流程，具體的分工職責和邊界。這個邊界的制定相當重要，在邊界劃分清楚後正式的宣講和評審，多方認同，後續按此推進工作就會更加順暢，阻力也會小很多。

邊界劃分清楚了，那是否不該你做的事情你堅決不去做，或者說業務系統需要協助的地方你完全不管？很多時候事情都沒這麼簡單，該協助的地方你還得協助，但是這是義務幫忙，非職責所在，要提前說清楚。那麼為啥要協助？很簡單，你不協助將影響到你自己的專案的按期完成和交付。你協助別人等於也是在幫自己完成目標。

對於ESB整合和實施這種專案，看似一個簡單的技術整合平臺，但是一涉及到服務實施就複雜，因為服務實施就涉及到大量的協同，這個時候不是你能力夠就ok，而是需要所有和你配合的業務系統都能按時按質交付，但是你對業務系統往往並沒有強管控力。這也導致你專案的成敗受到外部干係人太多的制約，也存在太多的不確定因素，你能力再強有時候也無法解決。

很多能力強的人更願意單幹或單打獨鬥，這裡面最大的原因就是自己能夠很容易承諾質量和交付週期，但是一到團隊，一到諸多幹系人，隨時都可能碰到豬隊友給你挖坑，你時間都在填坑，而不是在解決問題上。所以對於這種大整合專案，我們最怕的也就是他人經常給你挖坑，你又無能為力。