綜合項目管理知識之認知項目管理

申請免費試用、咨詢電話：400-8352-114

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