今天來討論一下怎麼PMP的指導，我們應該怎麼去制訂項目進度計劃。在這裏想先討論一下，項目開發到底需不需要制訂計劃。其實很多項目都是有計劃的，只是在與計劃的詳細程度或者說是對計劃的認識與理解的不同。就比如我早期在的公司中，所謂的計劃其實是一個工作週期的承諾（而且是沒有文檔記錄的），例如：老大：Jason，幫我開發一個集成微信與支付寶的SDK需要多長時間。 我：大概需要兩週吧 老大：好的，那你今天開始做，兩週後給我。 我：回到工位上，開始埋頭苦幹了，老大每天過來問一次進度。兩週後就拿出來一個SDK給老大。你說這不算計劃吧，其實對我來說其實是計劃。或者說一個更簡單的例子，我今天晚上計劃做個番茄炒蛋，其實根據我們經驗來說都知道是怎麼做，計劃都在我們腦海裏面內，先買番茄和蛋，然後放一起炒，裝碟，喫。
要不要做項目進度計劃，PMP告訴我們是需要做的。因爲這樣我們可以更好的控制項目進度，以保證項目在規定時間與成本內完成。所以我們進去正題，到底要怎麼制訂項目進度計劃。可以分爲幾步：規劃項目進度管理--->定義活動--->排列活動順序-->估算活動持續時間-->制訂項目進度計劃，這幾步活動中工作可粗可細，畢竟PMP也說了需要根據項目情況進行剪裁。
規劃項目進度管理
在這個過程中，最後需要輸出一個文檔【項目進度管理計劃】的，這個文檔可以指導我們後面怎麼去完成項目進度計劃與控制項目進度。那這個文檔記錄了我們所要用的進度模型，進度的計量單位 如 人/天，人/月。我們項目的發佈計劃、進度計劃維護 如：多久更新一次進度計劃以及進度的報告格式。要知道，我們進度計劃制定後並不是一成不變的，做過項目都知道。項目開發過程中總會遇到各種各樣的奇葩問題，然後導致了無法按原來計劃繼續執行下去。但是有時候，我們就算是原來計劃執行不了，也不會更新項目進度計劃，因爲覺得這是一件不好的事情。最後導致了項目的失真。其實我們做計劃的原因就是爲了應對變化的，當我們制訂進度計劃後，其實可以更好的控制項目的進度，可以更好更早的發現問題，從而提前制訂應對計劃。所以要明白進度計劃不是一成不變的，需要定期的進行維護更新，以保證剩餘計劃的可控性。擁抱變化，積極應對。
定義活動
定義活動是什麼意思？在這裏之前，我們需要經過一個過程-範圍管理。在範圍管理的時候，我們是有了範圍基準-也即是WBS（可交付成果），項目是由一個個的可交付成果組成，這裏就不展開去談了。在我們有了可交付成果後，定義活動就是完成這些可交付成果，我們所需要進行的一系列活動。例如：做番茄炒蛋，我們需要番茄，雞蛋。番茄和雞蛋是可交付成果，而我需要去菜市場某個檔口裏面購買番茄與雞蛋是一系列活動。然後我們需要把這些活動用一個文件記錄（活動清單）起來，這樣做的好處是我們可以時刻知道，完成項目需要做哪些活動。除非範圍基準變更了，要不除了這些活動以外的工作都不做，這樣可以有效控制住我們是朝着正確的目標行動。當我們把所有活動都識別出來並記錄，我們就可以把一些活動集合在一起，組成一個里程碑清單，里程碑清單相當於我們項目的控制節點，領導們也是看里程碑清單多一點。除了這兩份文件以外，還需一個活動屬性的文件來描述活動，對活動進行說明。
排列活動順序
當我們手裏有了三份文件：活動清單、活動屬性、里程碑清單。就需要對活動開始先後進行排序了，要知道我們上面一步只是把需要做的工作識別出來了。但是要怎麼做還沒有定義的，我們總不能先把番茄炒熟了，再洗番茄吧。所以我們把需要做的工作識別出來後，還需排列一下順序。知道要怎麼做，哪個先做哪個後做。這裏我給大家介紹活動之間的4種順序關係：FS、SS、SF、FF。F代表Finish S代表Start，所以用中文說 FS:前一個活動結束後，後一個活動才能開始 SS:前一個活動開始後，後一個活動才能開始 SF：前一個活動開始後，後一個活動才能結束 FF:前一個活動結束後，後一個活動才能結束。用圖表示的話，就是下面。
活動順序排列完成後，我就知道完成項目要怎麼做了。但是結合上面的信息，我們還可以繪製出一個進度網絡圖，進度網絡圖是一個好東西，它可以給團隊成員清晰明確項目路徑，相當於一個導航，也便於項目經理對進度的管理。就像下圖這樣
網絡進度只有唯一一個開始和一個結束，不允許有多個開始或者結束。所以你們可以從上圖的例子看出幾點。第一活動之間的排列順序可以直觀看出，B、C、D活動都需要在A活動完成後才能開始。第二g以A活動爲開始，G活動爲結束。當然有些複雜的項目，可能會分爲多個子項目，從而有多個進度網絡圖。
估算活動持續時間
在上一步工作中得出的進度網絡圖，只是一個初步的。細心的朋友可能會發現，在每個活動的上面和下面都有空的網格。這些空的網格就是用來填充我們估算出每個活動的持續時間，填充完成後纔是一個完整的進度網絡圖。估算活動持續時間的方法幾種，比如【類似估算】就是根據曾經做過類似的功能進行估算，說白了就是根據豐富的經驗進行估算。【參數估算】是根據功能的各種參數，然後通過數學模型進行估算，這種估算比【類似估算】更準確。【自下而上估算】是從活動最底部開始估算，然後逐漸往上層彙總，最後得到一總的項目時間，這樣的估算一般都是找最熟悉這項活動的同事進行估算，最好是以後就是該同事負責開發的，這樣估算出來的時間是誤差比較小的，也是我們使用的最多的估算方式。【三點估算】是根據活動的最樂觀，最可能，最悲觀三點的時間進行估算，例如：完成活動最樂觀時間是8天，可能10天，悲觀12天。然後用一個公式（樂觀+可能*4+悲觀）/6， (8+10*4+12)/6=10天，最期望能完成的工期就是10天。當我們把所以活動的持續時間都估算完成後，還需要考慮到一個活動需要多長時間完成，既取決於活動的性質，也取決於資源配置情況。最後編寫的出【活動持續時間估算】文件還需根據【風險登記冊】進行調整，估算持續時間還需考慮各種假設條件與制約因素並記錄到【假設日誌】上去。下圖是我們最後完成的網絡圖
制訂項目進度計劃
從上面工作中得到的文件【活動清單】、【活動屬性】、【里程碑清單】【活動持續時間估算】、【估算依據】然後就可以編寫出【項目進度計劃】，【項目進度計劃】通常包括【詳細進度計劃】、【概括性進度計劃】、【里程碑進度計劃】三份計劃滿足不同層次人員，經過高層領導批准的【概括性計劃】、【里程碑進度計劃】就是進度基準。需要注意，一般我們編寫好的項目進度計劃不會直接提交給領導進行審批，因爲我們只是編寫好了進度計劃，並沒有做優化。所以我們需要對進度計劃進行優化一下。我們需要先試用【關鍵路徑法】編寫出理論上可行的項目計劃，再使用【資源優化】把上述計劃調整爲實際可行的項目計劃，在使用【提前量與滯後量】對上述計劃進行優化（縮短工期）。最後得出的一個比較好的項目計劃。這裏簡單介紹一下【關鍵路徑法】與【資源優化】，【關鍵路徑法】就是完成項目持續時間最長的一條路徑（比如看上圖：A->D->F->G是關鍵路徑），關鍵路徑完成了就代表項目完成了，關鍵路徑延遲了，就代表項目要延遲了。所以項目經理一般都需要特別關心關鍵路徑，關鍵路徑上的活動不能有延遲。【資源優化】 可以分爲資源平衡與資源平滑，資源平衡解決的是關鍵路勁上資源被超負荷使用，就是說把非關鍵路徑上的資源借調到關鍵路徑上使用，這樣的做法可能會導致關鍵路徑的變化。資源平滑是將非關鍵路徑上的活動推遲或提前，讓資源符合保持在一個相對平衡線上。
今天就到這爲止吧，還有很多不足，還需更多的實踐。每天多學習一點，成長一點。