背景：最近我們啟動一個專項項目。該項目涉及與銀聯的對接，需求很大程度來源於銀聯方的反饋。對方有很多輸出不一致和難以最終定版的不確定內容。導致我方產品經理無法準確的獲知需求的範圍，一半猜測，一半驗證。摸索導出銀行的需求。但是，做這個項目有一個“政治任務”，到月底必須搞定，也就是說deadline是固定的。
所以，我們面臨一個問題：不確定情況下，如何確保項目能夠保質保量按期完成！
這種情況在IT行業特別常見吧。為了能夠順利完成該項目。我們組織人員對項目範圍和風險做了全面的識別。同時為了規範各口的順暢執行。我們制定了“按天跟蹤進度及彙報”的制度。經過一週的執行，發現大家在“項目計劃”的管理思維上存在很大的差異。據此，組織各口負責人進行了一次簡短的知識宣貫。具體內容如下：
知識點：我們所說的項目計劃其實是一個統稱。包含兩層意思，一層是動作做規劃項目，另一層是名詞《項目計劃書》的簡稱。實際上，我們做項目管理，對項目的規劃過程以及它的產出《項目計劃書》要有一個關係的區分。“計劃書”是分層次的，關聯到我們具體的任務進度管理，是要做好不同層次的計劃管理的。
第零，所謂《項目計劃》的分層次。包括：
（1）《項目高層計劃》裡面規定了重要的里程碑節點和資源安排。------這是管理層看的。
（2）《項目計劃書》是項目完整的規劃的產物，包括：範圍、成本、進度、質量、干係人、資源、溝通、風險、採購等方方面面的計劃安排。------這是整個項目的計劃基準。
（3）《項目任務進度計劃》通常是甘特圖或EXCEL做的進度表。主要就是到任務級，通過任務匹配時間和人員，查看具體末端任務執行的進展情況，用以跟蹤項目進度。------這是任務進度監控使用。
基於以上知識點。我們在做當前專項項目，做精細化按天跟蹤管理的過程，需要做到：
第一，識別出大家對於計劃更新的誤解。所謂項目計劃，並不是我3月11日估計的計劃、拆解任務到我3月31日開發完成、全程就按部就班的按照這個執行，當出現風險、湧入新需求等，發生進度調整，就定性為管理做的不好。這種僵化的思維“大錯特錯”！
相反，做計劃的人，要定期去根據當下蒐集到的項目執行過程中出現的溝通問題、新湧入的需求以及風險等一切項目信息，去及時更新同步計劃，確保計劃與實際項目狀態相符，至少可以指導短期的人員任務推進。
第二，計劃更新。有兩種策略可選。
（1）第一種，按照里程碑節點或deadline不變的情況。如果蒐集到的信息顯示我們需要更新計劃，那麼具體人員在日均完成任務量上可能要發生調整。舉個例子我們原來計劃完成10個任務，排定的3月31日必須要開發完成，可能需要開發人員3天做1個任務，那麼現在突然發現有新需求加入了，有其他風險存在，我們這時候就需要安排開發人員3天做3個任務，才能保證能在截止日期完成工作。而且，這種變化也是需要定期更新和同步到相關人的。這種在項目管理是推薦的作法！
（2）第二種，按照人員日均任務量不變的情況。設想一下如果我們期望的是開發人員每天處理任務數量不變，那麼如果湧入新需求，任務總量變多的情況。策略就是根據日均完成的產能，順延估計排出後續工作的介入和完成時間。如果這個完成時間不被接受，倒推看看我們人員在哪個節點需要趕工、需要加班、需要增人等。
所以，基於以上，我們的項目計劃跟進要這樣做，才夠好！：
第一步，產品口及時識別需求變更，要努力保證需求內容的清晰和範圍的穩定。如果有變更及時同步大家。設計、開發、測試聯動調整各自具體任務。
第二步，設計、開發、測試口做任務推進計劃的人。每天捋一下，是否有相關風險和問題，衝擊當前任務計劃的執行。如果有，想一下單項任務的完成時間能不能變，要不要變。如果不變，如何安排具體設計、開發、測試人員在發生變化情況，還要保證當天任務能夠執行。（加班、加人還是其他？）
第三步，設計、開發、測試口每天更新具體任務的完成進度。重點識別：任務的範圍是否發生了變化，任務的完成會不會存在延期，單個任務會不會影響項目的總工期。
第四步，每天都按照如上步驟檢視、調整、更新。（當然，“每天”這個情況目前僅適用專項這個項目，其他項目的檢視節點、和檢視頻率是需要根據具體情況進行設定的。）
總結核心知識點：計劃分級，各級關注點不一樣。精細化管理核心是風險識別、問題暴露、變更同步、計劃及執行策略及時根據變更做好聯動調整、鉚著目標執行！.
閱讀更多 alicejs 的文章
