專案計劃與跟蹤(轉)

專案計劃與跟蹤
專案計劃是專案管理的第一步，它可以讓思想成為產品。一個專案的管理是否混亂的判斷首先應該從專案計劃開始。以一個專案為例，我們可以將從混亂到清晰的狀態分成幾種情況：

第一種是知道目標，知道現在該作什麼，知道將來該做什麼，稱之為“清晰”。

第二種是知道目標，知道現在可以做什麼，但是不清楚將來該做什麼，這稱之為“半混亂或者半清晰”。

第三種是什麼都不知道，那就是“混亂”。

我們實際遇到的大部分是第二種情況。在這種情況下，專案開始是有計劃的。出現這種情況大概有以下幾種原因：

對計劃認識不清，長遠計劃或者是整體計劃不實際、不準確、不具備實施的指導意義。

計劃是為了應付領導或者客戶，僅以此搪塞而已。而且領導/客戶對拖延、返工司空見慣，不足為奇，所以就完全接受。

計劃不夠周密，計劃總是趕不上變化，總是出現較大的差錯。久而久之失去耐心就置之不理。

實際操作中幾乎不可能100%的遵照計劃，總有些沒有想到的事情，這些事情就會影響計劃的實施。計劃是為了使事情變簡單，使事情可見，但是如果計劃被變化打亂，那就必然重回混沌狀態，計劃也就成了擺設！計劃被打亂不足為奇，關鍵是及時的修正計劃。所以對於計劃必須有一個跟蹤。專案跟蹤就是及時發現實施中的問題，能夠及時的修改計劃，使整個專案處於控制之中。

1. 專案計劃

專案計劃直接關係到專案的好壞、成敗。它是整個專案的頭腦，專案計劃越詳細越好。但是在專案工作中，這種情況是很難達到的，而且專案計劃可能會有不同的層次和結構，所以專案計劃不應該是一個人完成的，應該是整個專案組成員思想的結晶。專案計劃就是專案的設計書。

計劃是給自己用的，因為它就為指導自己的工作。計劃不是靠拍腦門子搞出來的，這樣的計劃會給你帶來很大的麻煩，因為對於這種計劃你只有兩個選擇：要麼拋棄；要麼修正。修正肯定會產生新計劃。拋棄就又面臨兩個選擇：要麼重新做計劃；要麼破其計劃陷入混亂。所以這種計劃最終的結果只有兩種：一是製作新計劃，二是陷入混亂。所以與其做兩次，甚至更多，不如一次就完成。陷入混亂那就不用多說了。計劃的內容最少應該包含任務、時間和資源。但這裡不談這些，而是說說其他幾個容易被忽視的地方。

重視管理首先應該重視計劃工作，先認識、再重視、然後實施。認識就是要弄清計劃的必要性和科學性，那些內容需要計劃，那些內容需要明確。重視就是行動，這個行動就是加強計劃的管理，確定計劃編制、修改的方法和過程。實施就是計劃真正的指導實際工作。

1.1. 計劃的層次和結構

計劃難以一次性徹底完成，所以專案計劃應該保持一個層次機構。應該分成大、中、小三個層次，大計劃由中小計劃構成，中計劃由小計劃構成，小計劃可以說就是個人任務的規劃。這樣做也是為了使我們工作容易進行。這樣做的好處是：

首先層次結構體現了工作流程，符合專案的實際工作需要。在專案開始時，一般是很難具體的策劃專案的細節工作，所以這時要求製作大計劃，一般不包含細節內容，但列出了相對精細的中計劃。之後中計劃就開始被清晰的制定了出來，此時的中計劃包含了粗糙的小計劃。隨著中計劃的實施，小計劃也就從粗糙變成了詳細了。這個結構賦予任何成員一個自我施展的空間。當然計劃的制定必須經過專案經理的認可。只要專案經理願意，可以設計自己的所有工作。

其次層次結構是分工的體現，同時也體現出專案組的組織結構。在一個大專案組中（如果有十幾個人的時候）就需要再分組。而這種分組，必然是基於工作上的分工。分工的同時也把壓力、責任等分配了下去。這種小組的計劃當然應該主要由這樣的小組制定。這既是減輕專案經理工作壓力的辦法，也是發揮成員積極性的渠道。在實際操作中，大計劃由專案經理負責協調、整理、編寫，中計劃可以由組長負責編寫，專案經理負責協調、整理，小計劃可以有專案成員完成。

1.2. 計劃的詳細程度

“計劃越詳細越好”。計劃至少應該有三個要素被真正的落實下去，這就是任務、進度和資源。計劃的詳細程度就取決於對這三項的考慮。按照現在的情況來說，計劃應該細到人/日（小計劃的粒度），專案越緊計劃就應該越細。做計劃的時間，絕對不會拖延專案。計劃越細專案中不確定的東西就越少，專案就越順利。正所謂“磨刀不誤砍柴工”。

針對不同層次的計劃，詳細程度有不同的要求，大計劃應該確定中計劃的任務，安排各任務實施的先後和用時的多少，以及人員組織；中計劃應該確定階段中的子任務（如編碼階段的某個模組），任務開始和結束時間，任務負責人；小計劃應該確定個人進度的詳細安排（日進度）。因為很多專案經理可以不用考慮資金、辦公場所等資源，所以這裡重點考慮人力資源。如果用一個例子來說明它們之間的關係的話，那麼大計劃是整個身體，中計劃是支援身體的骨骼，小計劃是血和肉。所以他們組成一個有機的整體。以瀑布模型為例，專案整體計劃作為大計劃，階段（設計、編碼……）計劃作為中計劃，然後分配到具體個人的工作為小計劃。（具體情況視專案大小而定）

計劃不但需要任務明確，還需要明確的完成標準。這個標準應該能夠衡量產物的優劣。每個人的工作都有一個不同的標準，所以如果標準不明確，必將增加跟蹤的工作量。標準是否達到是跟蹤結束與否的依據，也是工作合理安排的依據。

1.3. 計劃三步方略

計劃的實施是有先後順序的，尤其對於中、小計劃。計劃與實施之間可能會存在一定的偏差，如果偏差積累起來，就會導致計劃失效和專案失控。所以應該實時對計劃進行調整。跟蹤會發現計劃/實施的問題，這些問題就是調整的依據。

在實施中，人們應該注重小計劃，因為：

計劃的誤差可能最早出現在小計劃中，而且小計劃的誤差也最容易被忽視。

小計劃的實施會影響中計劃，也會影響大計劃。

小計劃的問題可能比較獨特，對問題的認識可能侷限於某個或者某幾個人。

計劃的制定應該是整個專案組的事情，人人都應該參與專案計劃的制定。所以全員參與計劃制定/修改才能及時將問題都反應出來，只有這樣才能避免小計劃問題的淤積。如果等到發現中計劃已經不適合的時候，就說明你已經失去了最佳調整時機，而你要承受的就是拖延。

大計劃可以和第一個中計劃一起制定，緊接著應該考慮實施的問題。對於多箇中計劃來說是按照一定時間順序來實施的，前面計劃出現問題可能會影響後面的計劃。所以這裡建議實行三步走的方略。總結一個，實施一個，籌劃一個。

總結一個：需要專案組能夠對照大計劃和中計劃的進度，及時的收集並總結前一箇中計劃，甚至大計劃的實施問題。

實施一個：根據前一個的實施問題，及時調整當前計劃/大計劃的內容和實施方式，包括時間、資源分配等。

籌劃一個：根據以上兩個中計劃的內容，根據重新調整的大計劃的內容策劃下一個中計劃的詳細內容。

專案經理在這個過程中更重要的是起到強力的協調作用。

三步走可以使我們修改和完善計劃。但前提是有良好的跟蹤！在第一個中計劃的實施中得到的跟蹤資料，可以直接幫助我們修改和完善第二個計劃和第三個計劃。每個計劃的跟蹤結果必然會影響到今後幾個計劃的制定。三步走的方略一直迴圈下去，直到專案結束。

1.4. 設定警戒線和底線

計劃會有拖延的情況。這種情況發生的頻率非常的高。很多拖延在發生之前是難以明確的，就像風一樣在不知不覺間到來、並流過。對於專案組來說，最好是通過設定警戒線和底線的方法來控制這種風險。警戒線和底線可以時間和階段成果為標誌。警戒線是為了認清發生拖延的標誌，就像水位的警戒線一樣。當警戒訊號出現後，就應該執行應急措施。警戒線上應該設定必要的解決或緩解問題的活動。底線本身是一種預測，預測拖延可能的時間。

雙線設定可以使我們對問題快速做出反應。這種反應就是效率。尤其是專案組出差在外，或者涉及到計劃重大變更的時候，這種預防更是必要的。比如專案組要在5天內完成A、B、C、D四個工作（ABCD存在先後順序），警戒線設定為：第四天的中午完成工作C，底線為5＋1天。

當警戒訊號出現後，專案經理應該儘快進行一次全面的檢查，瞭解各個成員的工作情況，分析專案的整體進度狀況，然後制定相應的對策。警戒發生後的應急措施應該是提前設計好的，例如加班、增加成員等計劃。

警戒線就是風險的觸發值，當警戒訊號出現後，說明風險已經變成現實了。底線是對風險處理的預計時間。如果把警戒線和底線推而廣之，那就是對風險的管理。對重大的風險都應該這樣考慮。風險管理應該是每個階段最先做的事情，首先認識風險，然後在計劃中充分考慮。

1.5. 工作量的評估

軟體本身是科學的產物，但是在軟體開發之中，很多工作卻處於原始狀態，根本談不上科學，這尤其表現在工作量的評估上。計劃中的任務、時間和資源等內容都是依據工作量來安排的。所以工作量的評估是至關重要的。工作量評估不準，必然會影響成本和進度。工作量的評估是個讓人頭痛的問題，但這個問題主要是自己造成的，是我們在面對這個問題的時候採取了鴕鳥政策。

世界上已經有幾種被人稱道的工作量評估方法，比如PERT、Delphi、Cocomo等。對於軟體工作人員來說，“學”並不是難事，難在是不是願意去做。變革對任何人來說都是比較難以接受的，但是不變就難以改善。也許這些方法也有不科學的地方，但這是走向科學管理的必要的一步。

2. 專案跟蹤

專案跟蹤主要針對計劃，是為了瞭解專案的實際進展情況而採取的活動。如瞭解成員工作完成情況，瞭解整個專案計劃完成情況等內容。跟蹤主要是為了及時瞭解專案中的問題，並及時解決，不使問題淤積而釀成嚴重後果。

專案跟蹤是必要的，因為它可以證明計劃是否可實施，同時可以證明計劃是否可以被完成。因為可以對計劃進行檢驗，所以如果我們把計劃和跟蹤作為一個工作迴圈，那麼計劃將得到適時的改進，因為跟蹤過程中會發現計劃的不當之處。詳細的計劃可以提高跟蹤的準確性，提高跟蹤的效率和效果。粗糙的計劃則會加大跟蹤的工作量，並降低跟蹤的效果。這是迴圈所必然導致的結果。

計劃中很多事情是無法寫進去的，例如人員士氣變化，人員的思想變化等，但這些事情很有可能影響專案的進展。跟蹤——及時發現問題就變得尤為重要。

專案跟蹤實施人應該是專案經理，因為專案經理負責制定專案計劃，並且專案經理可以進行工作的協調和調動。跟蹤可以給專案所有成員一個工作的參考，跟蹤的結果和資料是“最好的教材”。跟蹤主要是通過與專案成員的交流來完成，這種交流包括口頭的和書面的。

跟蹤的益處有：

2.1. 瞭解成員的工作情況

一個任務分配下來後，專案經理應該知道工作的進展情況，那麼他就必須去跟專案成員進行交流，瞭解這個成員的情況。所以他要得到的資訊是“能不能按時並保質保量的完成？如果不能按時完成，需要什麼樣的幫助呢？”這是專案經理最關心的。而且需要隨時的收集。如果這個資訊沒有被收集上來，那麼專案經理就失去了對專案的瞭解，也就失去可適時調整的時機，如此，後果就可想而知了。

2.2. 調整工作安排，合理利用資源

如果專案組中有幾個或者幾十個人的時候，就可能出現完成任務早晚的不同，完成早的不能閒著，完成晚的要拖後腿。也可能發現某人更適合某項工作，某人不適合某項工作。這時就需要專案經理進行工作的調整。那麼這個跟蹤結果和資料就可以幫助專案經理完成這個工作。

2.3. 促進完善計劃內容

專案人員多了，又去跟蹤，這就必然要求專案經理做出詳細的計劃，這個計劃必須要明確任務，明確任務的負責人，明確任務的開始和結束時間，明確產物的標準（至少是專案經理和製作人雙方可以接受且明確的內容）。這就要求專案經理把整個專案分成若干部分。詳細的考慮分工。專案經理的跟蹤必然促使專案組成員更加詳細、合理的制定自己工作計劃，最終形成一種良好的氛圍，那就是計劃展現出的層次結構（專案大計劃、中計劃和個人計劃）。

2.4. 促進專案經理對人員的認識

工作分解後，應該按照個人的特長分配工作，因為特長就是效率。所以專案經理必須瞭解專案成員的情況。即使在開始時不瞭解這種情況，這種資訊在跟蹤中也會很快的被體現出來。也就是說跟蹤促使專案經理對成員進行一個評估，並且這個評估是可以找到根據的（專案跟蹤的結果）。

2.5. 促進對專案工作量的估計

在一個好的跟蹤工具中應該有對工作量的估計。工作量的估計總是很不準確，這個問題在跟蹤中表現為完不成任務/計劃，或者工作超前。在這種情況發生後，也必然促使專案組去考慮工作量的評估問題，包括整個專案的工作量，各個任務的工作量，還有可能導致整個計劃的修改。

2.6. 統計並瞭解專案總體進度

經常會遇到這種情況，專案組在同一時間進行不同階段的工作。這時對於工作進度的把握，尤其是總體進度的把握就比較困難。如果專案經理把階段劃分的很清楚，並且階段工作量也很明確，而且專案成員也對自己的工作量進行評估的話，那麼專案的總體進度可以由工具自動生成（完成的百分比）。這當然不是很準確，但卻可以作為一個參考。而且是一個比較好的參考。

2.7. 有利於人員考核

專案成員的工作能力，例如“是否按時完成任務，完成工作量的大小，工作內容的難易…… ”，很多資訊都可以在跟蹤工具中體現出來。使專案考核有理有據，人人信服。

3. 小結

對於我們現在來說要想做好事情，首先是增加管理工作的內容和工作量，改變以往“專案只有技術重要”的看法和做法。管理的工作很雜而且很多，很多情況下我們不知道該管些什麼，該如何去管？所以很多工作都被有意或者無意錯過。

計劃是管理的第一步。計劃是為自己做的。計劃應該是切合實際的。在國內定製軟體開發領域有這樣一個認識，那就是一個專案一般會有三個計劃，第一個是給客戶的，第二個是最初的，第三個是神仙計劃；但只有第三個沒有形成文件。這主要是客戶催的緊，所以第一個是應付客戶的。第二個計劃本想是用來指導自己工作的，或者給領導的，但是由於內容粗糙，再加上變化太多，失去耐性後就被束之高閣。第三個計劃只有神仙才知道，就是做到什麼時候算什麼時候！要讓計劃變得可行，首先要求公司領導重視計劃，按照計劃對專案組考核。

從跟蹤方面來說，是專案經理主動去了解專案的情況。但專案成員也應該主動向專案經理彙報工作，尤其是工作中的問題，但不能完全依靠成員的問題反饋，在專案工作中，專案經理採取主動是應該的，很多情況下沒有問題，但卻孕育著問題。所謂“沒有問題就是問題”，專案經理應該注重這種情況。現在我們需要一個好的工具，來建立並完善我們的跟蹤工作。跟蹤工具可以是一個表格，很多著名的大公司都是採用Excel來完成的。

讓計劃和跟蹤形成一個有機的整體，做了計劃就要考慮跟蹤。我們以前的做法是丟棄了跟蹤，所以計劃也就變得可有可無了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21289/，如需轉載，請註明出處，否則將追究法律責任。