[原創] 我的專案管理之路--2、認知專案管理

pharos發表於2019-03-17
專案管理
隨著對工作的熟悉，開始感知專案管理，感受到自己的工作是受約束的，在和一個小團隊一起工作。模糊認識到專案管理要界定需 求，再設定分解子目標，最後通過一系列規範、要求來約束專案成員保證任務的達成。但是，對專案管理的接觸是區域性的，並不清楚專案為什麼是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估算等方法。開始時，很多理念還不是很清楚，通過收集學習 專案管理的相關材料，多與專案經理溝通等方式，自己逐步熟悉起專案管理的內容。於是，從點走向了面。自己期待的專案經理角色正慢慢走來！
        回想當初個人的專案管理入門學習基本是零星積累的，很不繫統。我前段收集的《專案運作的一般流程》對入門同學很有指導作用，當初如果有這麼個文章能少走很多彎路。文章的索引參見：

        [專案管理入門系列] 師傅領進門-------專案運作的一般流程

        http://space.itpub.net/3433/viewspace-178874
        http://space.itpub.net/3433/viewspace-178876
        http://space.itpub.net/3433/viewspace-178878
        http://space.itpub.net/3433/viewspace-178879

        反過頭來再看，it行業專案管理入門學習這兩本書，理論上很受用的：一是國際專案管理協會(PMI)研製的“專案管理知識體系”（PMBOK），二是美國 卡內基梅隆大學軟體工程研究所（CMU/SEI）研製的“軟體能力成熟度模型”（CMM/CMMI）。然後，在實踐中鍛鍊，總結適合自己的經驗。

        下一篇談談開始負責專案管理。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-200450/，如需轉載，請註明出處，否則將追究法律責任。

相關文章