閑話項目管理：如何做好項目Schedule？

來自專欄淳見1 人贊了文章

這是「淳見」的第11篇文章。

「閑話項目管理」系列文章主要側重於作者本人對項目管理的思考、體會、認知和理解，而並非對項目管理相關知識的梳理，再加上作者工作經歷和個人興趣原因，文章必然會經常出現疏漏、偏頗、謬誤甚至離題萬里的情況，大家可權當「閑話」，一笑置之。

1. 從20/80原則看項目經理的時間分配

項目經理的時間基本是按20/80原則進行分配的，20%的時間花在進度計劃(Schedule)、項目預算(Budget)等具體事務上，80%的時間花在管理(management)和領導力(leadership)上。領導力的基礎是情商，但企業里大部分和領導力相關的培訓都不會側重於情商培養，而是會把重點放在領導力行為方面，並且這些領導力行為也只局限於和工作相關的部分。領導力行為的最突出表現是溝通(communication)，所以我們經常會看到項目經理Jack的日常工作狀態就是開會、聊天和喝咖啡，但這才是項目經理的常態境界。

2. 項目進度計劃是項目里程碑計劃的基礎

我們在聊「項目計劃」時聊到過里程碑計劃，項目進度計劃(Schedule)是項目里程碑計劃的基礎。談到項目Schedule，我們會想到什麼呢？很可能是WBS結構、甘特圖(Gantt Chart)以及Finish/Start繼承關係等。對於項目經理來說，這三項內容絕對是編製項目Schedule最重要的基礎技能。

項目Schedule中會涉及到一些名詞，比如說里程碑(milestone)、工作包(workpackage)、任務(task)等，它們代表不同的粒度(granularity)，對於項目經理來說，Schedule中最小的粒度是到任務級別。任務是什麼？是產出、是結果，它不是行動；通常來說，任務的周期通常為40小時，最長不超過80小時。

對於任務來說，還可以繼續分解為不同的行動(action)，但這已經不是項目經理關注的級別了，這一粒度通常是工程師關注的層級。項目經理為什麼不再進一步關注action呢？首先，任務的進一步分解更為專業化，在專業深度上很容易超出項目經理的能力範疇；其次，在做schedule時，應該給工程師留出適當的空間，這樣，工程師在操作上更為靈活，也更可能創新和高效工作。

總之，在時間軸上，不同的人關注不同的粒度。對於管理層，他們關注的最小粒度是到里程碑級別；對於項目經理，他們關注的最小粒度是到任務級別；對於核心團隊和工程師，他們關注的最小粒度是到行動級別。

3. 編製項目Schedule的基本方法

編製項目schedule與其說是項目經理規劃項目進度計劃，倒不如說項目經理通過schedule這一過程獲得核心團隊在時間維度上的承諾。大家都知道，管理者的一個重要任務是就確定的目標和團隊成員達成清晰的協議，這一管理邏輯對項目經理來說也同樣適用。編製項目schedule從來就不是項目經理一個人的事情，而是項目經理牽頭項目核心團隊一起編製，一旦核心團隊共同認可了項目schedule，也就意味著項目經理獲得了項目核心團隊的承諾，項目經理就可以代表項目團隊向管理層承諾里程碑計划了。

編製項目schedule有兩種基本方法。

第一種方法可以參考圖3-1。我們通常會先考慮每個階段有哪些任務需要完成，如果覺得任務過大，我們通常會繼續降低其粒度，也就是分解成子任務，通過任務分解來降低管理風險。所以這一方法的邏輯順序是：項目階段1>>確定階段1任務>>根據需要分解為子任務>>確定各任務/子任務工期>>確定任務間的繼承關係；項目階段2>>確定階段2任務>>根據需要分解為子任務>>確定各任務/子任務工期>>確定任務/子任務間的繼承關係；項目階段2>>……

第二種方法可以參考圖3-2。第一步，我們通常會先根據項目目標定義工作包，再把工作包分解為詳細的任務；第二步，我們先估計各任務的工期，再添加任務之間的繼承關係；第三步，根據關鍵任務完成時間確定相關工作包最終完成時間；第四步，根據關鍵任務完成時間確定各里程碑的時間。

第一種方法是我們以前做schedule時最常用的，但第二種方法在當下的項目管理中更為流行，也是「淳見」推薦的方法。我們可以體會一下第二種方法的比較優勢：首先計劃編製的邏輯更為清晰和科學，層次感更強；其次，按不同的工作包分配人力資源使得資源更為集中，因此更便於資源管理，項目執行也更為高效；最後，項目里程碑計劃自然地從schedule中得出，因此更接近實際情況，也更具備可執行性。

順便聊一個有趣的話題：項目交期或者里程碑計劃什麼時候可以確定？很多企業在給項目最終論功行賞時說項目未按項目啟動時的計劃時間交付，這對項目經理和項目團隊來說是不公平的。我以前在應聘項目總監時曾經和企業老闆討論過這個話題，我的看法是項目方案階段結束前的項目交期或者里程碑計劃才是靠譜的，才是衡量項目延期與否的依據。為什麼這麼說呢？原因很簡單，不同的方案對應不同的實現時間，方案不最終確定，項目交期的承諾就不可能靠譜。所以schedule是持續更新和優化的，方案定型時的schedule才是項目團隊可以有的承諾。

4. 編製項目schedule時要考慮項目的風險預算

編製項目計划過程中，項目經理經常會挑戰(challenge)任務工期的合理性，甚至會迫於項目交期壓力拚命壓縮任務工期。這樣的schedule或許從時間軸上滿足了交期需求，但我們千萬不要忽視一些基本常識。比如說，是項目就存在風險，應對風險需要額外費用。我們是否考慮了項目在時間上的風險預算？因此，有經驗的項目經理會在理想化的schedule中留出適當比例的風險預算時間，風險預算時間通常占項目總時間的10～20%，這個數字會因為項目的成熟度的不同而有所變化。

5. 項目經理在估算工期時參考的基本原則

項目通常有時間、質量、成本等多重目標，滿足項目交期目標並不只有粗暴地壓縮項目各任務的工期(時間)這一途徑，它還可以依靠團隊的智慧來尋求更好、更省時的解決方案，或者調配更合適的資源等等，這些才是正常的管理思維。不可否認，項目經理需要在scheduling過程中challenge核心團隊成員提供的任務工期，因為項目經理不challenge團隊成員的任務工期，管理層也會challenge項目經理提供的項目里程碑計劃。但challenge歸challenge，項目交期(也就是關鍵路徑時間)還是要基於務實的原則，否則項目實際交期相比計劃時間而延期造成的後果可能更為嚴重。

在談工期估算時，我們可能會想到Delphi技術、三點評測技術(PERT)等，但在真實的項目管理中，這些技術性的東西可能都不會用到，原因很簡單，過於僵化和低效。更為高效和實用的可能還是同時考慮手頭的資源、類似活動、歷史數據、專家建議等，這些考慮是在核心團隊一起討論schedule時自然而然地發生的，而非刻意為之；對於專家建議，通常也只是針對關鍵技術點而言的。

核心團隊對schedule的討論，儘管要關注所有的任務工期的合理性，但還是要給予「關鍵路徑」更多的關注，關鍵路徑決定項目交期，非關鍵路徑上的任務後面還有機會持續優化。

談到歷史數據，有個題外話，在做職能管理時通常會使用一個叫做TimeSheet的時間管理工具，有些企業也叫做工作周報、月報什麼的。名字不重要，重要的是它的管理思維。TimeSheet中最小的粒度也是到任務級別，裡面不但包括項目相關的內容，還包括諸如培訓、請假等日常活動。TimeSheet為管理者提供了很多靠譜的數據參考，比如項目任務工期估計、項目資源計劃、人員招聘/裁減計劃等。

6. 其他：45度曲線和項目進度計劃模板

我們在給管理層做項目彙報時，經常會用到一個和項目進度狀態相關的工具，叫做「45度曲線」。「45度曲線」見圖6-1，它通過圖形化的方式可以直觀地告訴我們項目進度狀態、或者里程碑趨勢是否異常。

在45度曲線中，橫軸代表實際時間的推移，縱軸代表計劃的里程碑時間，如果項目狀態一切正常，每條里程碑曲線都應該是水平直線，里程碑曲線到達45度趨勢線時代表該里程碑事件完成。當里程碑曲線出現上移時，表示里程碑時間延期；當里程碑曲線下移時，表示里程碑時間提前。對於上圖，我們可以輕易地看出，除了深紅色和黃色代表的兩個里程碑按計劃正常完成外，其他里程碑事件均出現了延期或者計劃向後調整，延期或調整的理由是什麼呢？這需要項目經理在項目彙報時向管理層說明。

為了提高編製項目進度計劃(schedule)的效率，我們通常會製作標準模板。有了標準模板，我們編製項目進度計劃的工作可能主要剩下刪除掉不需要的任務和修改任務工期了。

（全文完）