最近工做中在接觸一些項目管理的內容,在工做中上級要求對於某件事情叫我作一份計劃,作計劃這個過程當中反反覆覆改了幾回。才造成最後的計劃。程序員
在項目管理過程當中計劃的重要性不言而喻,無論你是項目經理仍是普通的開發人員、測試人員在工做中實際上都須要有計劃,在項目管理領域中,項目管理中的五大過程組中,規劃過程組就是其中一個,規劃的核心其實就是計劃、一份計劃基本上是貫穿了整個項目管理過程。測試
在項目管理中,一份計劃實際上是項目經理和相關干係人集體對焦的過程。它指引着項目的進度的推動、直到完成。設計
一份計劃這麼重要,但實際工做中大部分人作的計劃其實稱不上一份完整的計劃。下面我將從計劃的幾個注意要點來和你講一下如何作出一份完整的計劃。項目管理
剛剛轉管理時,上級分配任務下來,可能會叫你列舉個大概計劃,這個時候的計劃就是這樣的:我將在xxx時間完成這個模塊的功能。這種計劃對於我的來講問題也不大,若是對於管理人員來講簡單的回覆是不行的,由於這樣的計劃太不具體了。資源
好的計劃要給出時間節點,並給出依據。因此咱們拿個一個任務以後須要經過wbs過程,分解任務過程,就是把項目工做按階段可交付成果分解成較小的、易於管理的組成部分的過程。開發
經過wbs工做分解任務以後的計劃還不是一份完整的計劃,由於 計劃不是簡單的任務列表,程序員只須要關心本身何時把任務列表做爲結果,而項目管理人員須要總體看計劃,須要有關鍵路徑, 作計劃的方式的轉變,背後實際上是思惟方式的根本轉變。 明確整個項目分紅多少塊工做內容、涉及哪些角色和哪些環節工做項、每一個任務對應到我的,每項工做拆解到 3 個工做日之內。bug
若是一份計劃只有任務列表,沒有識別關鍵資源和關鍵依賴,也沒有考慮研發以外其餘環節是不夠的。程序
識別依賴並畫出關鍵路徑,這一步意味着咱們開始從目標的角度對資源進行統籌思考。同時若是在計劃中增長里程碑標識。就會使得計劃更加清晰。im
在計劃中節點完成標準須要統一。需求、設計確認完成 功能完成、提測、里程碑完成、這些完成怎麼纔算完成,例如是開發人員說開發完成,仍是須要測試纔算完成,提測的標準是什麼?是開發人員說能夠提測了就能夠嗎?仍是bug率要達到某個標準才行。這個標準最好提早定義好總結
有些項目經理定出計劃以後和相關人員說完以後就等最後的成果檢查,這樣是不行的,口頭說可能後面都說不清,可能相關人員也沒有正確吸取計劃。
計劃要透明,而不能只是口頭和相關人員說。須要將計劃發到各個相關人員手上, 作計劃自己並非最難的,真正難的是什麼?對焦!沒有達成共識的計劃,是不具有任何效力的。 達成共識並公開透明 只有你們對節點的狀態達成了共識,纔可以更加順利的推動項目,若是沒有共識,可能就出現一種狀況,到了某個里程碑節點,準備進行成果檢查時,發現事情的結果壓根沒有達到預期的要求,從而致使項目推後。
在項目進展過程當中,老是有一些特殊的事情發生或者開始作計劃時沒有考慮到的事情,因此說作計劃是個反覆修正、漸進明晰的過程,若是有變更咱們要對計劃進行持續地跟進與調整。重要的是,每一次進行調整,都要確保項目中的每一個人知道當前的計劃是什麼,調整計劃須要怎樣的決策過程,都須要誰參與決策。而及時調整變動。 即時調整 並告知相關人員。
從上面幾點能夠總結,一份完整的計劃須要幾個過程,