投資建設項目管理師：綜合管理之認知項目管理
發布時間：2010-01-14 共1頁
隨著對工作的熟悉，開始感知項目管理，感受到自己的工作是受約束的，在和一個小團隊一起工作。模糊認識到項目管理要界定需 求，再設定分解子目標，最后通過一系列規范、要求來約束項目成員保證任務的達成。但是，對項目管理的接觸是局部的，并不清楚項目為什么是n個人，為什么要 在t之前完成，討厭的文檔工作和評審為什么要進行，項目結束了總結和獎金有什么關系。
后來，真正進入項目才開始了項目管理體驗、參與和實施之旅。
首先，熟悉什么項目管理?
可以說項目是每個企業賴以存在的單元，同時項目的形式是多種多樣的，它直接與每個公司的項目組織結構相關。剛開始，我們每個初觸項目的人并不清楚什么是標準的項目管理模式，會認為自己所面對的模式就是理所應當的。
我參與的第一個正式項目，是公司準備上市的一款新產品，我是其中的一名普通的研發人員。考|試/大當時，公司指認了一個項目經理，然后從硬件、軟件、測試、質量管理 等相關部門調集人力資源就可謂稀里糊涂運作起來了。一開始，整個項目沒有明確的項目任務書和系統需求(所謂沒有明確是指一些具體的軟件規格并沒有確切落 地，功能需求沒有嚴格定義，這也給后續結項埋下巨大隱患)。回過頭來，我才認識到這里面缺少了上一篇提及的那張項目管理圖中的需求開發與管理環節。可以 說，這個環節在成本符合預算的情況下，做得越多越好、下的功夫越大越好，因為它是項目的根本--范圍。實踐證明，后來的項目過程但凡那些將功能模塊需求詳 細整理、認真評審、較好控制的模塊都基本沒有發生什么偏差。那些，或是因為沒有認真或者沒有足夠能力分析需求、控制變更的模塊，都成為了項目的短板。比較 可笑的是，這些模塊的開發難度都不大，但都是用戶必需的，這幾個模塊嚴重影響了進度，也嚴重損失了真個項目的獎金盤子。所謂，“壞了一鍋湯”，當時很是生 氣，其實那些是公司項目管理不夠成熟的必然，大家一起積累經驗教訓了。
隨之，項目的計劃是在大領導安排了這個任務之后，由相關部門經理依據經驗制定，項目經理更多是將討論的東西落到紙面上。同時，可以說任務規模的估計是站在 都是成手的角度估計，項目計劃并沒有在團隊內部認真的溝通、確認(確認很重要，是項目團隊成員對自己承擔工作的承諾。其實，到后來一些功能開發出現了延 遲，大多員工推卸責任說計劃不是我確認的，沒有考慮某某風險)。
由于是公司很重視的一個新產品，公司內部的動員、宣傳做的比較好，因此即便是有很多現在看來還沒有明確的情況下，項目便在大家的一腔熱情下開始。我也是這 樣。考|試/大我先是負責某一功能模塊的需求整理，于是我系統整理標準協議資料、又參考了一些同行相關產品的手冊，搞出來一份洋洋灑灑的需求文檔。然后滿懷著熱情提 交，等待確認開展后續工作。這個時候，忽然接到QA的通知，因為文檔不符合模板、郵件發布未上載服務器不符合規范，如同澆了一盆水，小小抵賴一通(搞技術 的通常比較好面子，希望被認可，但事實上，QA的這種要求對研發人員非常有幫助，養成良好習慣能幫我們減少很多不必要的彎路。模板能幫助大家系統思考，避 免遺漏思考;受控更多是一個安全措施，后來一個同事電腦壞了因為沒有及時上載，工作等白做，后悔不已)。
后續的工作更讓大家士氣低落，因為項目管理松散、沒有明確的配置和過程管理計劃，我這份需求的評審經過簡單的評審就進入了設計開發階段，也沒有進行需求跟 蹤矩陣處理。設計開發過程，我們發現一些需求很難實現、也沒有明確是否必須，在和部門負責人確認之后就跳過去，沒有進行正規的變更處理。結果，到了測試階 段提出了不少需求上列出但沒有開發的小問題，為此大家打了好半天仗。更頭痛的是，在項目結束的時候產品經理對項目提出了更大的質疑，一些他認為必要的功能 規格沒有完成，項目組提出“當初怎么沒有在規格上寫清楚”。考|試/大總結其中的問題，經驗是：變更一定要嚴格執行，也需要提前確認好變更委員會的成員。這里面，首 先可以方便需求的跟蹤，避免漏測試;其次，這是一個很好的溝通渠道，使得大家在信息上一致、更早發現問題。
其他的功能模塊問題也不少，主要是進度延遲的比較嚴重。后來才知道，項目還少了項目管理圖中的milestone階段評審環節。這個環節可以讓領導、項目 經理、項目成員對前一階段工作的工作成果給與審核(下階段準入條件)，總結成功經驗，分析風險問題。使得各相關人了解項目的現狀，以及是否需要給與特殊支 持。
同時，因為項目經理是協調型角色，沒有足夠的power，使得過程中各部門各自為政，一些上下層軟件接口、硬件聯調問題定位等事情遲遲不能落實。項目經理 做的工作，更像一個匯報員，把各組實際情況整理出來通報給大家與大領導。事實上，通報給大家，相信沒人為最終工作去負責推動;通報給大大領導，大領導日理萬 機、又認為有項目經理和部門經理推動，哪里會真正管理。更重要的問題是他在項目管理手段上不夠成熟，即便沒有power，但抓住人這個主觀因素多溝通，利 用個人影響力來保障團隊的有效開展，同時保障固定不變的項目例會制度，專題評審與匯報制度，相信一定會收效很多。當時的我還只是沉浸在項目存在的各種沖突 中，頻于奔命完成任務，感受到項目很不順利，并不知道哪里出了問題(真正的問題是當時還沒有明確的項目管理制度，更合理的項目管理組織結構，沒有明確的授 權，立項階段的不正規導致了項目從開始注定這樣的結局)
當然，項目最終還是上市了，但周期延遲了半年多，整個項目組被各種問題、長期的緊張折磨得疲憊不堪。項目經理也因為項目延遲太多和個人原因離開了公司，去了朗訊。我個人與項目經理的關系還不錯，第一聽說pmp(戲說拍馬屁)也是從他那里得知，到現在大家還有聯系。
下面是項目結束時項目做的總結提綱，從中可以看到管理的雛形。
1. 概述 3
2. 項目總結 3
2.1 項目計劃完成情況： 3
2.1.1 硬件模塊(以調試完成為準) 3
2.1.2 軟件模塊(以代碼提交為準) 3
2.1.3 測試(以測試報告提交) 3
2.1.4 項目變更情況 4
2.1.5 項目費用統計 5
2.1.6 人員工時統計 6
2.2 問題及解決情況 6
2.2.1 各次測試問題統計 6
2.2.2 硬件遺留問題和解決方案 7
2.2.3 軟件遺留問題和解決方案 7
2.3 BOM成本估算 8
2.4 剩余工作及計劃 8
2.4.1 硬件 8
2.4.2 軟件 9
2.4.3 測試 9
2.4.4 轉生產工作 9
2.5 COST Down的預計工作 9
3. 項目工作分析： 10
其次，從部分項目管理做起--子任務計劃安排與監控
后來，我開始負責一個小組的工作，在項目中開始接觸WBS和自任務計劃分解，嘗試了DELPHI估算等方法。開始時，很多理念還不是很清楚，通過收集學習 項目管理的相關材料，多與項目經理溝通等方式，自己逐步熟悉起項目管理的內容。于是，從點走向了面。自己期待的項目經理角色正慢慢走來!
回想當初個人的項目管理入門學習基本是零星積累的，很不系統。我前段收集的《項目運作的一般流程》對入門同學很有指導作用，當初如果有這么個文章能少走很多彎路。
反過頭來再看，it行業項目管理入門學習這兩本書，理論上很受用的：一是國際項目管理協會(PMI)研制的“項目管理知識體系”(PMBOK)，二是美國 卡內基梅隆大學軟件工程研究所(CMU/SEI)研制的“軟件能力成熟度模型”(CMM/CMMI)。然后，在實踐中鍛煉，總結適合自己的經驗。
