項目經(jīng)理經(jīng)常會被一些不了解的人問，“項目經(jīng)理不就是管進度的么？”，可見管理進度是項目經(jīng)理多么重要的一個職責，當然這樣問的小伙伴多少對項目經(jīng)理的職責缺乏理解，但不妨礙進度管理是項目經(jīng)理重要職責這一事實。接下來我們就來看看怎么做好進度管理，要如何一步步做好項目的進度管理。
一、制定計劃
互聯(lián)網(wǎng)軟件項目，唯快不破的文化氛圍下，造成程序員對于計劃往往不屑一顧，經(jīng)常會有這樣的反對聲音，“計劃趕不上變化，做計劃有什么意義”，那是不是制定計劃真的不重要呢？那必然不是，那計劃的價值究竟是什么呢？
1.1 為什么需要計劃
其實，無論是在傳統(tǒng)項目管理中，還是敏捷迭代中，計劃都是完成目標的第一步。
美國質(zhì)量管理專家沃特·阿曼德·休哈特（Walter A. Shewhart）首先提出的，由戴明采納、宣傳的著名的管理理論“PDCA環(huán)”，也稱為戴明環(huán)，其中P（Plan）計劃就是第一步，然后才是行動D（Do)，C(Check)檢查，A（Action）改進（行動，跟前面的行動有點重疊，我更愿意將它解釋為改進。
圖1.PDCA循環(huán)
《高效能人士的七個習慣》這本書提到一個概念，可以幫助大家重新理解計劃的價值。
任何事情都是先在頭腦中構思，也就是智力上的第一次創(chuàng)造，然后再付諸實踐，也就是體力上的第二次創(chuàng)造
頭腦中的第一次創(chuàng)造，就是計劃，也是頭腦中對于未來的一種正向的預想，有助于我們實現(xiàn)計劃。所以如果你想讓你的項目順利交付，就好好的做計劃，制定計劃的過程也可以幫助我們發(fā)現(xiàn)問題和風險。
1.2 那么如何做計劃呢
提到制定計劃，大家應該都聽過WBS（Work Breakdown Structure)，什么是WBS，又該如何來制定WBS。學習過PMP的人應該對這個詞不會陌生，WBS就是工作分解結構，把項目工作拆解為具體的，易于管理的子任務。
這里需要遵循的原則就是不漏不重，以及適度，不漏就是需要考慮把與項目范圍相關的所有事項都包括在內(nèi)，不重就是避免任務和任務之間交叉，WBS分解后的最小工作包都需要分別對應到人，明確交付的時間節(jié)點，如果出現(xiàn)重疊就會造成職責不清。
拆分的顆粒度是越細越好嗎？如果每個任務都拆分到1個小時以內(nèi)，是不是會更加好管理，但實際上這是不可能的，因為任務拆得太細，會使管理成本急劇上升。我們的2周一個迭代的管理中，一般任務顆粒度在4~16小時，大部分任務控制在1天以內(nèi)，這樣我們每天在晨會跟進任務的時候，就可以看出是否存在延期，及時發(fā)現(xiàn)問題并作出調(diào)整。
原則解釋起來簡單，但是在實際操作中，卻非常容易犯錯。尤其是不漏，項目中就經(jīng)常會出現(xiàn)這樣的情況，項目臨近尾聲，才發(fā)現(xiàn)按照產(chǎn)品要求，此需求需要完成另一套環(huán)境上進行測試驗證，而實際在評估的過程中根本沒有把此項工作考慮在內(nèi)。
另外，開發(fā)同學評估工作時，往往容易忽視研發(fā)以外的工作評估，例如，環(huán)境部署、數(shù)據(jù)驗證（一些數(shù)據(jù)統(tǒng)計類的需求，由于測試環(huán)境數(shù)據(jù)不足或者無法真實模擬真實數(shù)據(jù)，還需要考慮在預發(fā)環(huán)境中進行數(shù)據(jù)驗證工作量）等等。那么如何來避免呢？
我們在實踐過程中積累了一套創(chuàng)建任務的規(guī)范，此規(guī)范除了建立統(tǒng)一的管理規(guī)范以外，也起到了提醒和檢視的作用。這份規(guī)范包括兩部分：任務的標題規(guī)范、任務內(nèi)容規(guī)范
圖2.任務創(chuàng)建方法
1、任務的標題規(guī)范，分為三個部分
1）標明角色，是前端、后端、還是測試
2）需求內(nèi)容，把此任務對應的需求名稱簡要描述作為任務的一部分
3）具體內(nèi)容，是完成開發(fā)任務，還是完成前后端聯(lián)調(diào)，亦或是測試任務。
簡單來說，標題中的這三部分就是2W1H（Who、What、How）
2、任務中具體內(nèi)容部分
1) 預計工時，任務的顆粒度需要控制在4~16個小時之間
2) 截止日期，這部分表示完成這個任務的時間W（When）
這個規(guī)范一個任務需要包括3W1H這四個方面展開的。
任務是作為計劃的一部分，有了任務，還需要做一個重要的動作就是核對任務，識別好相互之間的依賴關系，定義好任務的前后順序，最后在團隊中同步（郵件或者即時聊天工具）。
二、設置檢查點
檢查屬于項目管理中的監(jiān)控過程組，沒有檢查的計劃無法真正得到落實，因為計劃是建立在假設的基礎上的，而檢查就是將假設與實際情況進行比較，及時發(fā)現(xiàn)問題，作出調(diào)整，以確保項目目標的達成。
Scrum的特點就是及時檢查，及時反饋，具體的檢查點有哪些呢？除了前面Daily Scrum（每日站會），還有Sprint Review（評審會）。
瀑布型項目中也同樣有檢查點，他的檢查點一般在階段交付的檢查上，稱為交付的驗收，也有一些方法是公用的，瀑布模式中也同樣可以安排日會，在項目前期需求比較模糊的階段，或者項目沖刺階段，都可以安排日會來每日同步進展和風險。
Scrum中的Daily Scrum通常在同一時間統(tǒng)一地點舉行，一般會回答三個問題：昨天完成了什么？今天計劃完成什么？有沒有什么問題或者風險？可以幫助大家很好的同步團隊進展，及時發(fā)現(xiàn)和解決項目問題。
這里要特別注意在同步進展的時候，經(jīng)常出現(xiàn)的一個詞，就是“差不多”，這個功能是否已經(jīng)完成了，團隊成員回答“差不多吧”，或者“完成80%”。這個時候項目經(jīng)理就要注意了，在這個“差不多”中間其實“暗藏玄機”，可能就是一個風險信號。聽到這個詞你需要停下來，要求對方把詳細的信息量化的表達出來，然后重新進行評估，分析具體的問題，再有針對性的提出解決方案。量化的表達出來，是問題被解決的基礎。舉個具體的例子：
項目團隊來了一個新成員N，一天早會的時候，跟進到他對應負責的需求時，他回答是'差不多吧，加加班應該可以完成的'，這句話的潛臺詞其實是“按期完成存在風險”，因為當前他處于接口開發(fā)過程中，于是我接著往下問，”具體有哪些接口，每個接口的進展情況分別是怎么樣的呢？”于是這位同學回答說，“我需要回去整理一下”。
早會后，這位同學把所有接口的進展情況整理發(fā)到群里，可以看出其他接口都已經(jīng)完成處于待自測狀態(tài)，還有一個復雜接口還未完成，由于剛來項目組不久這個接口對他來說需要花費更多的時間去熟悉，團隊其中一個組員看到他發(fā)出來的接口完成情況清單，隨即自告奮勇決定幫助N同學完成待開發(fā)的接口功能，及時解除了風險。
三、適時調(diào)整
適時調(diào)整的方式有很多，快速可以處理的問題，我們會直接在Daily Scrum中就做出調(diào)整，如果Daily Scrum中無法及時解決的，我們會在會后組織小會展開討論。一般會從范圍、進度、成本三個角度考慮做出調(diào)整，以滿足交付要求。
1)、范圍的角度，需求、項目范圍是否可調(diào)整
需求范圍一樣遵循2/8原則，可以根據(jù)需要交付內(nèi)容的優(yōu)先順序，優(yōu)先完成對客戶重要的需求，或者計劃時是否有備選方案可供調(diào)整，比如簡版的實現(xiàn)方案，出現(xiàn)延期時立即啟用備選方案。
2)、成本的角度，是否需要安排加班，或者外包出去
加班或者外包出去，都會導致成本的增加，但是在面對團隊人員有限，或者短期工作量增加的情況，短期加班或者將功能外包也是不錯的選擇。
3)、進度的角度，及時匯報或者升級風險
如果以上幾個方面全部做出考慮，依然無法解決延期問題，那么及時匯報也是進度管理中非常關鍵的一個方面，哪怕計劃做得再好，項目中總是會出現(xiàn)這樣那樣的意外情況。
當意外情況發(fā)生的時候，項目經(jīng)理要做的要把項目進度及時的同步出來，不要讓項目進度成為你一個人知道的秘密。有些情況下，團隊內(nèi)部無法做出調(diào)整時，可以在跟業(yè)務方、其他重要項目干系人溝通的過程中得到支持，以幫助解決問題。
作者介紹：傅益利
PMP/Prince2/CSM；
現(xiàn)任國內(nèi)500強公司PMO，項目管理經(jīng)驗超過10年。
近期熱文：敏捷項目中如何做好進度管理及其步驟方法【管理有度1】
聯(lián)系客服
