專案管理總結01(10.29)
專案上線半個月,執行平穩,自去年7月專案啟動到現在已經1年有餘,而自己這1年多時間也大部分在北京渡過,經歷了北京的春夏秋冬四季,北京空氣治理成效和霧霾天的明顯減少,也讓自己在時隔差不多5年後對北京有了新的認識。大型ESB匯流排和整合平臺實施專案,基本都是以年為單位,超過1年那是常事,一做就上5年10年也是正常,而這種大型專案,相對來說也更加鍛鍊人。
經驗來源於親身實踐,來源於在一線的證悟 ,雖說對於ESB類實施專案已經做了10年,但是還是感覺對於這種集團型的大專案,基本每個專案做下來都能夠有所收穫,能夠彌補原來的知識漏洞並完善知識體系,也能夠進一步的通過專案實踐形成更加體系化的思考框架和管理模式。
軟體專案管理本質是對人的管理和風險管理
對於軟體專案管理,其本質仍然要回歸到兩件事情上面,一個是對人的管理,一個是對風險的管理。
當我們在談人的管理的時候,比較容易談的還是人力資源管理方面的內容,比如人員招募,團隊組建,工作的分配,學習和培訓,考核和激勵,成長路線規劃等。這些都相當重要,但是今天談人的管理不談這些方面,對於軟體專案管理中人的管理,核心是在於如何形成核心小團隊,比如3到5人,有專案經驗,共同目標,通用詞彙表,高度的配合默契。
不管是20個人的軟體團隊,還是上100人的軟體團隊,你會發現最關鍵的就是這個核心小團隊,一般控制在7個人以內。我們做軟體講核心底層架構,這個核心團隊就是整個專案底層架構,只要這個底層架構穩固不垮掉,那麼個別功能出現問題不影響大局。但是如果這個底層架構都不穩固,那麼整個軟體團隊想協同好也困難。
如何講這個小團隊呢?就是說你將工作目標或任務安排到這個核心小團隊的時候,你至少能夠做到95%以上的信任度,能夠按時按質的得到交付,而不是你事必躬親,你的重點是在這個小團隊如何高效配合,協同運轉,而不是在於檢查。
核心小團隊人員之間最重要的就是信任,對承諾的信任,對個人技能和能力的信任,這是配合的基礎。
除了對人的管理外,專案管理最重要的不是簡單的制定目標,分解WBS,排計劃,而是風險管理。
前期大量經驗積累最終帶來的是關鍵風險預判
在談專案管理的時候,我經常會強調一個觀點,就是專案管理本質是風險管理,風險管理貫徹整個專案管理生命週期過長。如果在專案管理和執行過程中沒有風險,那麼專案就應該一定能夠按照既定目標完成,因此專案延期或超支,都是前期關鍵風險沒有識別導致,到這裡最後風險變成問題,你只能是疲於奔命,花費比前期多達數倍的人力和物力資源來解決。
軟體專案管理是技術型管理,對於專案經理而言技術背景和一線技術實踐和重要,可以試想下你沒有經驗,你如何排計劃,如何分解WBS,如何識別關鍵風險?所有這些事情你都會感覺寸步難行,都要依賴於下面的需求人員或架構師幫助你來完成。
風險管理方法和流程,猶如教科書般標準,從風險識別,風險定義,風險定性分析和定量分析,風險應對和緩解,風險監控等。但是風險管理的真正核心不在這些地方,而在於你是否能夠識別出關鍵的風險。你所有的QA過程檢查都100分,風險登記冊做的很漂亮,但是最終專案還是失敗了,原因就是關鍵風險沒有識別。
一個有經驗和有技術背景的專案經理,最重要的一個能力就是識別專案關鍵風險的能力,同時對於關鍵風險即使轉變為問題,還有Plan B計劃。什麼是最關鍵的風險?簡單的拿考試來類別的話,就是關鍵風險是確定你是否能夠及格的風險,而不是那些是評估你考80分還是90分的風險。我們把大量時間花費在80分到90分上,而最終發現一個大的失誤,導致根本沒及格,如果這樣就根本沒法玩了。
專案管理的重點是分清優先順序和輕重緩急
有是很簡單的道理,但是這個確實又是專案管理的一個重點內容。對於專案經理來說,精力始終是有限的,那麼你就必須思考清楚你的精力應該放在哪些關鍵的事項,關鍵的風險,和關鍵的問題解決上面。
我們可以舉一個最簡單的例子,當前專案裡面有一個關鍵的技術問題沒有解決,直接影響到平臺的正常執行,那麼你這個時候是去花精力解決這個關鍵問題還是說按PMO的要求提交細分後的計劃,週報等內容。顯然就我自己來說第一時間做問題解決,計劃和週報找其他人完成,即使提交給PMO計劃不足夠準確也無所謂。原因很簡單,關鍵技術問題涉及到你是否及格問題,而計劃是否按時提交只涉及到你是90分還是95分。
再舉個例子,專案臨近上線階段了,整個軟體產品的功能基本封板,這個時候可能甲方讓你緊急增加兩個報表功能,而且要在上線前完成。那麼這個時候你如何應對?這個時候最好的策略一定是不做,原因就是上線前的各種檢查,風險預案准備,查漏補缺,這些功能重要度遠遠高於兩張報表功能。即使前面仍然有時間空餘,最好做法也是不要接新需求和新開發任務。經常做軟體專案的相信都有同感,在上線前專案越是忙的不可開交的,基本上線後都會出亂子,所以你更加應該意識到在專案上線前能夠真正空下來,做思考,做全面檢查和風險預判,並且準備關鍵風險的PlanB更加重要。
專案管理不是簡單的授權和放權,而是真正知道這個專案的Key Point究竟在哪裡?甲方或你的干係人理解的關鍵點和你理解的關鍵點是有區別的,你不要被外界帶著走。專案日常工作和事務如此之多,你要做到的就是對於關鍵點能夠真正一插到底,乃至自己親自上陣協同解決。而對於非關鍵的東西完全不要去太多關心或分散自己的精力,這些最好的就是工作例行化後能夠交給你的助理去做。
這也再次說明有技術背景積累的專案經理往往在確保專案按期按質交付上面往往更加有優勢,專案經理往往能夠起到最後一層緩衝和後備力量的作用。即總是能統攬全域性,發現關鍵問題,並解決關鍵問題。