你可以通過看合同，向公司高層請示，了解到這些關鍵信息。當然很多公司合同是保密的，你可能無法直接看到合同，但你可以直接問高層領導嘛，盡量獲取上述關鍵信息。做項目就像打仗，秦國名將白起沒有一次敗仗，主要是因為他每次打仗之前，都會處在戰略高度來審視國與國之間的大勢。你要做好項目，先要把握項目的大勢！
在具體計劃時，往往會發現估算時遺漏考慮的內容，這時很有可能實際計劃的總工時會超出估算，或者是某類別的工時超出相應的子估算。這是很正常的事情，項目組對項目的認識是逐步深入的，不太可能在估算時就100%考慮周到。遇到這樣的情況，我們通常這樣處理：如果僅是某類別工時超出相應的子估算，如果能從別的子估算挪一點過來“補數”，而總估算不受影響，則不需要申請估算調整；但如果總估算受到影響，則需要申請變更估算。
前文講述估算時提到，會因為需求不能全部明確、設計也不能全部明確，估算往往不能一次完成，這時只需要估算能估算的部分就可以了。但我們需要隨著項目的開展，認識的加深，持續更新估算。估算與計劃的關系是：估算指導計劃，計劃反過來促進估算更新。
四、制定可執行可檢查的進度計劃。
具體工作任務的制定是很講技巧的，如何做到“可執行可檢查”是關鍵，下面是制定進度計劃的一些技巧：
1、每個任務的時長不要超過5天。
我們公司的項目，任務時長往往是在兩三天內。
2、任務只有完成與未完成兩種狀態。
所謂任務完成90%之類的說法是不靠譜，任務應該足夠細分，不要安排周期長的任務，這樣能更好控制項目進展。
3、每個任務都有可供檢查的工作產物。
不要籠統安排“研究什么什么技術點”之類的任務，必須明確工作產物，如：研究某某技術點，編寫研究報告，提交演示程序。而任務完成標準就是：這些工作產物能達到期望的要求。
4、一個任務一個人負責。
一般不要安排類似“小甲與小乙共同完成某設計文檔”之類的工作，多人同時負責一個事情，效率會很低，效果也不太好。
盡管實際工作中有可能需要多人同時做一個事情，你可以：
1）再次將任務分解，落實到具體的人頭上，如上述任務可以分解為兩個任務：小甲完成設計文檔的章節1、2、3，小乙完成章節4、5、6。
2）如果任務實在不好再分解，就只安排一個人去做。
在我們公司，一般只有評審任務是多人參與的，別的任務都會落實到具體的人頭上。
五、細化近期計劃，定下遠期計劃大節點。
我曾經負責一個房地產公司的成本管理系統，當時需求還沒有全部明確、技術也很不成熟，就被要求做出該項目的全部詳細計劃。我當時很郁悶，一個月后某一天誰干什么的事情也要計劃出來嗎？我只能明確近期一兩周的具體工作，而遠期的工作我只能定出大概，以后的事情可變因素太多，現在寫出所謂具體工作，其實是毫無價值的，浪費時間。
近期兩周內的工作能明確的工作，必須按照上述第四點的要求制定詳細的明確的可執行的可檢查的任務，而對于將來的工作，則需要定出關鍵節點，如什么時候發布什么版本，什么時候驗收。
六、讓項目組各成員詳細計劃自己的工作。
在項目經理主持下，項目組全體共同來制定進度計劃框架，明確任務的先后關系。而對于每個人的具體任務，則可以在項目經理的指導下，由每個人自己來確定。
項目組由項目管理、需求、設計、編碼、測試、實施等各專業人才組成，每個人承擔起自己專業方面的管理工作，項目管理其實是項目組成員每個人的事情，不是只由項目經理一個人來負責。
七、持續更新計劃。
計劃不是死的，是活的！項目計劃不是一次成型就固定不變的，項目組需要持續更新計劃細化計劃，要隨時保證近期的任務都已經明確，而遠期的任務如果能明確也應當盡量明確。任何項目組成員都可以發起計劃更新，項目經理要推動大家管理好自己工作，讓大家主動更新計劃。
這里要談談計劃變更問題，談到計劃變更很多人會“聞虎色變”，我們先要看看看什么叫“計劃變更”？
“計劃變更”要與“計劃調整和細化”區別開來，調整和細化是指根據實際情況，不斷的適時地去修改計劃。任務微調是很經常和很正常的時間，某某任務稍微延長一天，某某任務比計劃提早一天完成，某項目組成員請假等影響因素，都需要我們去調整計劃。與此同時，我們應當不讓去細化中遠期的任務，至少要一直保證近期的任務都是明細化的。
而計劃變更是指，項目關鍵節點受到影響的重大變化，關鍵節點一般有：需求規格說明書通過評審的時間點、版本發布時間點、驗收時間點等。這些關鍵節點的變化，會影響合同條款的履行，會影響公司的戰略規劃。通常是因為內因或外因導致計劃變更，內因一般有：遺漏重要需求、軟件設計出現重大失誤、代碼質量不過關；而外因一般有：客戶的需求變更，客戶未能做好項目上線準備，第三方未能及時完成相關工作（如：硬件提供商未能及時發貨）。
在我們公司，計劃調整和細化只需要項目組內達成一致便可，而計劃變更則需要報高層審批。
如何跟蹤計劃？
計劃做出來不是用來看的，而是要執行計劃！跟蹤計劃執行的難度和工作量比起做計劃要高出好多倍。
計劃跟蹤并不是對照進度計劃，按時間檢查每個人的任務完成情況這么簡單，下面介紹一些計劃跟蹤的關鍵要點。
1、建立便捷的項目組內溝通機制。
很多人強調加強溝通，雖然大家的意識算是加強了，但還是收不到理想效果。程序員不善溝通的特點（理科生往往是不善溝通），不是一下子能改變的。下面一些最佳實踐供大家參考：
1）所有人的工作產品必須share！我們要求大家的文檔要提交到項目網站，而代碼滿足提交條件的，每天都需要提交。工作產品不能幾天都只存在自己電腦上，哪天你不上班了，大家就無法接手。
2）每天站立會議。
口頭溝通是最有效的溝通辦法，我在很多項目中實施了每天站立會議的做法，要求大家簡要地說明工作情況及遇到的問題，需要大家提供什么支援等。每次會議，如果有決議和代辦事項，我都會安排記錄下來，并將會議記錄公布在項目網站上。
3）有問題即反饋！
很多項目組成員喜歡遇到問題就悶頭干活，不好意思問，也好像是怕被主管認為能力低。遇到問題有可能是任務本身有問題，也有可能是你的認識不到位，某些知識不具備等導致的。實際工作中遇到問題是很正常的事情，如果沒有人提出問題，這反而是項目的最大問題。我強調任何人都可以提問題和大家討論，任何人都可以發起項目會議討論問題。問題如果不在產生時消除，將來必定會因此徒增很多項目工作量。
2、建立項目組成員的自信。
我帶領過很多項目團隊，很多項目組成員是新手，甚至是應屆生，項目團隊中新手太多是很大的挑戰！在中國基本上不可能每個項目團隊一開始就是最強陣容的，大部分項目團隊是新老結合，中高低搭配的。我強調每個人的重要性，對于新手要給出更多的機會，更多的指導，更多的鼓勵！犯錯不要緊，犯錯多也不要緊，只要錯誤不是重復的，這就是好事！只要去做事情，就有機會犯錯，只要做未做過的事情，犯錯機會也會更大一點，關鍵是總結和進步！
3、質量投資，減少返工。
項目時間緊，大家就會一頭扎到編碼中，想盡快弄出個東西來。“謀定而后動”“磨刀不負砍柴工”等大道理大家都懂，但事到臨頭還是明知故犯，結果往往是工作質量低、返工一大堆！
要培養大家零缺陷意義，零缺陷意識包括零缺陷文檔、零缺陷代碼、零缺陷發布。我經常和大家強調，做一個事情只有兩種選擇，一種就是不做，一種就是認真做好！不要搞什么60分萬歲，不要應付完成，任何帶有缺陷的工作，會在將來帶來無窮無盡的“后患”。一步一個腳印，欲速則不達。
除了向大家灌輸這種思想并要求大家這樣去做，作為項目經理還需要盡早檢查和指導大家的工作。比方說：我安排小甲完成某模塊的設計文檔，我不會等文檔完成才去看，我會先要求小甲思考后找我口頭說明他的思路，大致沒有問題我就讓他動手寫文檔，而且我要求項目組所有人寫文檔都必需在線完成，我會隨時檢查文檔的質量。（說明：我們用SharePoint來管理項目文檔，Word、Excel等文檔都可以在項目網站上在線編輯。）
絕大部分項目是分秒必爭的，保證大家用正確的方法做正確的事情，才能最大限度地減少返工。不過上面提到的檢查辦法確實有點夸張，我一般對于新手才會這樣檢查，當新手已經成長起來，你對他有信心，就不需要檢查得這么密了。
4、不斷思考減少工作量的辦法。
失敗的項目特點，往往是無用功太多，返工太多！
軟件項目的特點是“兩不明確兩大限死”：需求不明確、設計不明確、工期限死、預算限死。要成功完成項目，不能光靠所謂的項目管理知識，你需要熟悉這個軟件開發的方方面面，想出降低工作量的方法。
能極大降低工作量的兩個方面：
1）需求方面：抓住本質需要，盡量簡化需求，優先實現穩定的需求。
穩定的需求是指我們基本能明確，客戶將來不太可能會變化的需求，這些需求應該優先實現。
2）設計方面：采用成熟設計，重用組件，采用能降低編碼和實施工作量的設計。
通過以上兩方面降低工作量，光靠項目管理知識是辦不到的，你需要在這兩方面有資深的經驗，你需要發動項目組全體人員的智慧，一起想出簡化工作的辦法。
5、密切留意需要客戶和第三方完成的工作。
我們公司的項目在開發階段還算比較順利，因為一切都是自己來掌控的，但一旦涉及到客戶或者第三方，問題就非常多。下面是常見的一些問題及應對辦法：
1）確認需求規格說明書，特別是一旦要求客戶簽字蓋章，就會左推右推。我們會跟客戶說明簽字是表示對前面工作的確認，不代表將來不允許變更。
2）客戶不能及時準備好實施所需的軟硬件環境。我們會提前很多提醒客戶，并盡可能幫助可以搭建實施環境。
3）系統上線后，客戶無法及時組織人員參加培訓，推動系統正式使用。我們一般會走高層路線，讓客戶高層推動系統上線。
4）系統需要用到的服務器或相關硬件不能及時采購。我們會事先做好供應商選擇，挑選合適的供應商。
不要忽視客戶和第三方的工作，一般需要打很大的提前量來進行預防性管理。
優秀項目經理是怎樣煉成的？
軟件項目經理往往是權力小而責任重大，軟件項目的“兩不明確兩大限死”特點，讓我們做項目猶如走鋼絲，而且要高速地走鋼絲！
你的綜合實力決定你能否成為優秀的項目經理！項目經理是練出來的，下面談談我的體會。
1、你需要有扎實而豐富的軟件工程實踐經驗。
想成為優秀項目經理，從編碼切入可能是最好的打基礎辦法。我編寫VB與C#的代碼都有若干年時間，編碼的工作其實不只是編碼的，你還需要考慮測試，你還需要思考軟件是否符合需求，考慮軟件如何安裝部署等。只要你能堅持3年以上的編碼工作，相信你一定會有軟件工程的多方面經歷，如需求、測試、實施，這些經歷都是你寶貴的財富！如果你是從測試、實施切入，你可能難以獲取軟件編碼、軟件設計、軟件技術方面的經驗。
2、學習軟件開發牛人總結出來的項目管理知識。
關于項目管理的資料書籍很多，強烈建議大家重點閱讀軟件開發牛人總結出來的經驗。如果你還沒有實際工作經驗，大學中學習的軟件工程知識，可能還能“忽悠”一下你。但如果你已經有實際工作經驗了，建議你一邊工作一邊學習資深軟件開發人員的著作，會讓你產生極大的共鳴，讓你思考如何工作得更好。我最開始看的一批項目管理書是微軟資深開發人員編寫的，大家找實用項目管理知識書一定要注意作者有沒有多年的實際軟件項目管理經驗。
3、主動承擔項目管理工作。
我剛開始的三年編碼生涯，基本上是出于“無人管理”狀態下完成一個技術含量較高的桌面程序。當時沒有人帶領我做這個軟件，我完全是靠自己一邊探索，一邊前進，這無疑是給了我自己管理自己的鍛煉機會。不要等別人來管理你，你首先應該要會自己管理自己！如果你能管好自己，你就應該主動申請帶領團隊完成一些工作。項目經理可以說是訓練綜合素質的最好職位，無論你將來升任部門經理、高層領導，甚至做老板，還是回頭鉆研技術，項目經理一職絕對是你以后成功的超級助力器！
4、持續總結，不斷進步。
總結使人進步！你應該利用一切機會思考和改進。很多人不喜歡寫文章，這一個很大的問題，寫文章其實不需要什么文采，關鍵是你腦袋中有沒有東西？我主要通過以下幾種途徑來幫助自己總結：
1）在項目中我會編寫計劃、需求、設計等各種文檔。
2）我平時會整理出很多文章。
3）我會整理出很多課程，在公司的每日培訓中與大家分享。
本文介紹了我在項目估算與計劃的實踐體會，希望能為大家帶來有益的啟發。