四、三層計劃的跟蹤和管理
參見圖 1的三層計劃管理框架，其制定的過程是“自頂向下”的，但是跟蹤過程則是“自底向上”的。根據計劃的不同層次，計劃的跟蹤和管理主要包括以下三種方式：
1.各個小組每天早晨的晨會
2.項目組每周的周例會
3. 組織層面的里程碑評審。
其中，后面的兩種跟蹤方式一般的項目經理都比較熟悉，只作簡單說明。這里重點介紹一下“底層計劃”的跟蹤和管理方法。
底層計劃的管理不僅為中層計劃提供了基礎信息，也是項目管理落地的基石。前面提到，底層計劃在白板上上公示，但小組長還需要配合使用一個管理底層計劃的關鍵工具——《完成度矩陣》。
參見圖 4，完成度矩陣用Excel表開發，是連接底層計劃中層計劃的橋梁。它成上下兩個部分：上半部分為“底層計劃”，下半部分左面為“任務”欄，右面為“關鍵步驟”欄，記錄了每項“任務”分解成“關鍵步驟”的過程。
圖4：完成度矩陣
通過一些簡單的開發，《完成度矩陣》可以根據“關鍵步驟”的分解結果自動導出上半部分“底層計劃”，還可以根據“底層計劃”的進展狀態，自動計算出每個“任務”的完成比例。后來還增加了《個人周報》自動導出功能，直接根據“底層計劃”導出每個成員的工作任務，減少小組長的工作量。
底層計劃采用晨會的方式進行跟蹤，晨會一般在15分鐘左右，要求小組所有成員站在白板前面完成。晨會的步驟如下：
第一步，小組長與項目組成員逐個確認昨天任務的完成情況，并進行標注。確認任務的完成情況不涉及執行細節，僅需要回答：“Yes/No”。一般任務按時完成用“√”別時，未按時完成用“○”;對于昨天未完成但是完成的任務，在原來“○”的基礎上增加一個“√”，將任務的完成情況分成三類：“按期完成”，“延遲完成”和“延遲中”，并進行匯總統計。這樣，只要看到“底層計劃”(圖 3)模版左上角的統計數字，可以對于小組的工作狀態有了大概的了解。
第二步，組長根據昨天任務的完成情況和的任務要求，對“底層計劃”進行適當調整，布置當天每個人的工作任務。會后，再將進展和計劃的調整信息更新到《完成度矩陣》中(幾分鐘應該可以完成)。
第三步，組長收集執行過程中遇到的問題(這時，成員可以說明沒有完成任務的原因是什么)，記錄到白板上，并審核以前的問題的狀態。除非簡單可以當場解決的問題，此時仍不要對問題展開討論，只要記錄到白板的問題欄。會后，對于這些問題再作進一步討論，或另行安排相關各方碰頭協調。
鑒于底層計劃的顆粒度已經到了每人每天的工作，一般變動比較頻繁。但是，小組長還是要盡量將變動減少到小，太多變更不僅浪費小組的工作時間，而且每個成員切換工作內容、進入工作狀態都會降低工作效率。
底層計劃如果不會影響到中層計劃的進展，組長可以直接調整底層計劃，而不需要通知PM或者架構師。但是，如果底層影響到了中層計劃，則應該通知PM和架構師，并說明變更的原因。項目管理團隊可以據此評估對于后續計劃的影響，并采取適當的措施進行管理。如果需要，還應該跟其他小組溝通中層計劃的變化。進一步，如果變化影響到了高層計劃的里程碑，則應該作為重大變更，由項目經理迅速匯報到項目總監層面，討論具體對策并采取措施。
有了底層計劃的管理基礎，中層計劃的管理效率會提高很多。中層計劃采用周例會方式管理，基本上是匯總每個小組的底層計劃的完成情況并局部進行調整的過程。主要任務包括：組長首先根據上周底層計劃完成狀態，更新《完成度矩陣》中各項任務的完成情況;然后，項目經理根據各小組長的提交的《完成度矩陣》，更新《中層計劃》中的任務完成情況;后，項目經理和小組長一起制定下周工作計劃。周例會的跟蹤方法參見筆者的另一篇文章《項目經理怎么知道每天該干什么》中的范例，這里不作贅述。
高層計劃的控制點在里程碑，但是有了中層計劃的信息基礎，其實每周、甚至每天都可以知道是否可以按期到達里程碑。里程碑評審是確認上個階段的完成、批準下個階段開始的過程。具體的任務包括：交付物納入基線并完成審計;項目經理對于里程碑完成進行說明，對于進度、成本、范圍的度量數據進行分析;對項目團隊進行評估;對于客戶反饋進行分析;評估風險及應對措施;質量經理評估項目質量狀況、交付物缺陷修改情況、階段審計不符合項的修改情況。后，由項目總監根據項目的狀況，批準本階段結束和進入下一階段。
五、 實踐效果總結
三層計劃的管理方法的核心，是對應項目組、小組和個人的組織結構，將項目計劃分成高層計劃、中層計劃、底層計劃三個層次，并采用滾動更新、分段制定的方法，隨著工作的進行逐步細化計劃。這樣的管理方法，可以幫助項目總理理清層次，從宏觀到微觀的逐層聚焦，不僅能夠看到項目的整體趨勢，還可以深入查出問題“點”。因此，可以與各個層面進行清晰的溝通，能夠“3分鐘說清項目狀況”。
針對“底層計劃”變動頻繁、要求“響應速度快、公示性強”的特點，采用“白板”動態跟蹤每個人的工作情況，逐層向上匯總以獲取項目的整體進展的信息。基于白板的底層計劃管理，還為CMMi4評估積累了寶貴的度量數據，“白板”文化在評估過程中獲得了主任評估師的贊賞。
但是，這種方法也有一定的適用條件。第一，需要有比較明確的“實施方法論”，即每個階段工作流程、任務比較清晰;其次，在規模比較大時才有必要，對于僅有一二十人的小型軟件項目來說，可以直接管理到底層計劃;第三，在基地化的開發的模式下比較有效，因為項目組有比較大自主權，受外界的影響比較小。
后，分享一點個人體會。在選擇底層計劃管理工具的過程中，嘗試過多種選擇。首先想到的是Project，但很快發現如果要分解到底層計劃的層次則過于龐大，很難管理;其次，想到了 Excel，盡管其項目管理功能非常有限，但用來開發一些類似《完成度矩陣》的小工具非常有效;后，選擇的卻是簡單、不自動的白板，但發揮了意想不到的作用。因此，軟件開發中“人”才是重要的，如果沒有“人”的能動性，再高級的工具也難以發揮作用—— “開著夏利還撞墻呢，難道換成奔馳不撞了”?
