為曾經的專案經理「平反」
by 韓宇斌 2012-12-08夜
部門內部有個小書架，供全體技術部的人員借閱。去年噹噹和京東大戰時，集體買了一批書，當時每位成員都可以提交購書清單，把自己想看的書列出來，《it專案管理那些事》就是我看了51cto的讀書頻道的推薦後提交的。等書一回來，就被同事借走了，等我在書架處再看到這本書並拿到手時，一年都快過去了。好快，一年的時間在思念與重逢間又快過去了……
書從外觀上依舊比較新，不像是輾轉多人之手之目的樣子，和別的技術書籍的「遭遇」有明顯的區別，吸引技術人的書籍還是講具體的技術的書。等仔細開始讀這本書的時候，更加明白了其中的原因，因為這本書講的更確切的是傳統it行業專案管理的事，書中描述的情形不是所在的網際網路公司的所有人都有體會的。
書的第一章講故事般的介紹了專案經理在乙個較大it專案的工作內容以及專案曲曲折折的經過，的確是「那些事」。看著看著，又想起了我還在軟體公司做專案的日子，讓我也來講個故事吧。
就連諾貝爾文學獎的獲得者莫言先生，獲獎的演講主題是《講故事的人》。
那年，我還沒有現在這麼老，也沒有現在經歷的事情多，也沒有來到北京，也沒有寫部落格，也沒有讀過專案管理的書。那年是我第一次換了工作，進入了鄭州的一家軟體公司，讓我沒有想到的是，剛剛過了試用期，我就要被派到外地出差，而且是兩個月才能回來一次。
入職後，我就被安排到了石油相關的那個專案，熟悉業務熟悉開發工具。抱著在大專案中學習的心態，我接受了薪水範圍，和專案經理開始了出差駐外開發的經歷。
專案的過程很不順利， 不光老闆對於專案經理的工作很不滿意，我自己也有很大的怨言。於公，我不滿意他的工作態度和方式，於私，我不滿意他處理專案組成員經濟利益的態度和方式……
具體的內容我真的敲出來過，但仔細想想還是刪掉了，有心的人是能明白的，看熱鬧的人不需要明白，我的故事其實許多書裡面都有類似的情節。
的確，當時的專案經理能力有限，這是可以確定的，但是當時把擔子交給byteh的話，我說不定還不如他呢！當然，人無完人，態度和為人處世另說！
看了《it專案管理那些事
》第一章以後，我就覺得自己是不是在心裡該為這位專案經理」平反「了。
老實說，在絕大多數中小型it企業中都沒有公司級和部門級專案管理制度，有的只是個人的專案管理風格。正因為沒有制度，所以只能靠專案經理自身經驗的積累和對專案管理技能的學習。在某種程度上，民營企業的專案經理和程式設計師的管理水平和技術技能要優於一些外企，而外企更多的是靠企業管理制度、專業分工和協作。
人治和法制的問題，在祖國的各個角落都有深刻的體現。國家靠人治，就要依託於這個人這群人有著先進的理論水平、先進的道德覺悟和先進的治理水平，才能夠真正健康和諧。企業靠人治，也是同理。人治
，人的本性，人的真正水平
，有很大的風險性存在。出現問題的時候，只是把責任歸結於個別人的不先進就能解決問題嗎？
專案靠人治也存在這種風險，專案經理真正」先進「了，專案就會進展順利。反之，困難重重。老闆總把問題歸結於專案經理水平不行，處理事情不行，為人辦事不行，既不靈活多變又沒有立場，結果企業的專案經理進進出出，企業專案管理的水平卻沒有顯著的上公升，前乙個專案跌倒的地方後乙個專案還會毫不猶豫的繼續絆腳，這世上還有優秀的專案經理都跑哪了？
在現在的企業裡面的親身經歷，我很認同書中的如下描述。
中國的民營企業往往先有業務再有管理，而不是先有管理再有業務，重業務輕管理、重業務輕技術是普遍現象。隨著公司業務的發展，對領導者思維格局、管理能力、領導藝術等方面提出了新的要求，只有不斷學習，提公升知識水平和個人修養，才能帶領企業向更高層次發展。
一些民營企業家卻陷入自滿的境界並無法自拔。我在北京的第一家企業失敗了，原因又很多，但主要創業者的心態和行為肯定很關鍵，一位跟隨了他很多年的同事如此評價「自己屌的地方認為自己很屌，自己不屌的地方也認為自己很屌」。
在專案實施的過程中，最頭疼的問題是缺乏不了解公司的專案運作和管理方式，缺乏標準的專案管理文件模板和軟體工程文件模板。所有的一切都要靠自己摸索……專案經理各自為戰，造成的結果是缺乏有效的延續性和公司資源的虛耗浪費，當然也不會有任何知識的積累。
積累個屁啊，很多專案經理走的時候都和老闆鬧的不愉快，微笑握手也是貌合神離。
如何構建專業的it專案管理制度，我的建議如下。
1．建立適合的培訓制度
培訓一方面可以使員工的專案管理知識、技術知識等綜合技能得到有效的提高，另一方面也可以增強員工對公司的認同感，更好地服務於公司。
2．建設公司資源池和綜合知識管理庫
建設公司資源庫，充分了解團隊成員的現有技術水平和技能情況，有利於組建核心團隊和制訂資源備份計畫，減少專案開發中的資源不足的風險。同時，可以結合現有人員的優勢和劣勢，建立起完備的內部培訓機制和招聘機制。在之後的專案管理過程中做到人盡其才，充分發揮其優勢。
而綜合知識管理庫的建設則是為了幫助公司更好地進行過往知識的積累和沉澱，然後在員工中使之得以共享和學習。綜合知識庫可以涵蓋公司的內部流程、業務總結、技術分享、管理經驗、市場客戶資料，等等，有助於員工更快地提高自身學習，並從前人的經驗積累中成長。
綜合這兩點說一下。企業主動的使員工進步了，員工會真正感激組織。員工只是通過自己的努力提高了，那麼結局往往會是「不加薪我就走人」，「此處不留爺自有留爺處（換工作又不是移民）」。
3．規範企業專案管理和軟體工程文件模板
對於研發人員來說，最頭疼的莫過於文件的寫作，而文件寫作的難題又在於沒有可以參考的規範和依據，結果很多時間都浪費在文件的寫作上了。專案管理有九大知識域，軟體工程有十大知識域，而僅軟體測試方法就有22種，是不是每種都要寫呢？
當然不是。規範企業專案管理和軟體工程文件模板的過程也是對企業專案管理制度進行不斷總結和反省的過程，文件規範是建立在目前企業專案管理的現狀的基礎上的，同時也要吸取先進專案管理制度的經驗。短期而言，遵從相關文件模板會給專案經理帶來一定的陣痛，從長遠看，則有助於企業專案管理制度的規範和知識的積累。
文件，誰寫誰知道！誰吃虧誰知道！有多少中小民營企業家認為寫文件是種能力呢？
4．制訂企業專案管理制度
什麼是企業的專案管理制度？個人認為一部分是在專案管理之外但又與專案管理息息相關的制度，另一部分才是專案管理本身的制度。
專案管理之外的制度應包括公司的組織結構、公司的人事制度、公司的財務制度、部門的職能和部門的協作機制，專案的成功離不開公司其他部門的保障。舉個例子，專案實施過程中出現人員短缺，該怎麼辦？專案實施過程中專案經理和客戶鬧翻了，該怎麼辦？銷售部門、售前部門、it實施部門在專案管理和實施過程中分別應該承擔什麼樣的職責？ 很顯然專案管理不是專案經理乙個人的事情，而這一切又只有在公司層面才能得到解決？
專案管理本身的制度則包括生命週期與方**的選擇，專案的立項、啟動、計畫、執行、跟蹤，需求變更，風險管理，質量管理，以及每個專案階段專案的啟動和結束的準則。只有清晰地規範了這些，專案經理才能保證專案的發展方向與最終目標相契合。
「我只管你幹活，其餘的你和老闆說去」。專案過程中人員水平提高合理的加薪訴求該如何回應，專案經理除了管理專案進度是否有責任管團隊建設？
「客戶經常對自己說過的話不負責任」。客戶需求總是變化，專案經理該如何應對？有沒有明確的方法和規定？
「***，這個專案失敗了，你要負全部責任」。無法按期完成了，專案經理該怎麼辦？公司有什麼支援可以提供？
「老闆，專案完成了，你當初說的專案獎金的事情是不是該落實一下了」？「由於專案延期，沒有賺到什麼錢，多給你們發乙個月工資……」
專案經理之初為專案經理
這一天終於來到了 你從乙個一線開發人員被提拔為專案經理。也許你一直在期盼，也許你心裡還忐忑不安，也許這是你的職業發展選擇，也許你只是不情願的答應老闆 試一下 不管哪種情況，可能你並沒有專案和人員管理及領導的教育背景或者培訓經歷。設立優先順序 你要著手的第一件大事很可能就是有意識的設立你作為專案經理的...
初為專案經理
這一天終於來到了 你從乙個一線開發人員被提拔為專案經理。也許你一直在期盼，也許你心裡還忐忑不安，也許這是你的職業發展選擇，也許你只是不情願的答應老闆 試一下 不管哪種情況，可能你並沒有專案和人員管理及領導的教育背景或者培訓經歷。領導和管理 這兩者是不同的 遠非簡單的與dilbert 的老闆背道而馳 ...
初為專案經理
這一天終於來到了 你從乙個一線開發人員被提拔為專案經理。也許你一直在期盼，也許你心裡還忐忑不安，也許這是你的職業發展選擇，也許你只是不情願的答應老闆 試一下 不管哪種情況，可能你並沒有專案和人員管理及領導的教育背景或者培訓經歷。領導和管理 這兩者是不同的 遠非簡單的與dilbert的老闆背道而馳 譯...