引言：
專案工期的控制，應該是開發人員，專案經理，產品經理最為之關心，也最頭疼的問題。
關於工期的控制，我有幾點思考：
具體實施：
在需求階段，應該對專案的可行性進行分析。結合團隊的技術實力，客觀的分析。制定每個階段，可量化的需求標準。需求不確定或者根本就是不行的專案，工期控制是無從談起的。
在實施階段，對於每個階段的目標，應該確定需求是明確，可以量化標準。驗收時，嚴格按照本階段制定需求進行驗收，避免想當然或者驗收本不屬於本階段的內容。
對於專案乙個階段的時間粒度，不應太大，不然為驗收帶來很大的難度，導致過程失控。
對於時間的控制，我個人覺得一周二次，應該是比較好的粒度。對於大型專案，可以對每個迭代期，劃分成幾個小的階段。這樣每次需求的量都不會太大，開發人員，也能比較輕鬆的完成目標，不會帶來太大的心理負擔。
對於細節的追求，我覺得無可厚非，不過應該能在掌控全域性的基礎上，快速的開發出功能的原型。
對於領導過程干預，也可能影響到工期控制。應該讓開發人員擁有適當的自由度，不能讓開發人員束手縛腳。領導能做到放得開，也hold住就最好的。
對於團隊的技術氛圍的營造，雖然不提倡加班，日以繼夜，但是對於難題的攻關，在乙個技術氛圍很濃厚的團隊，對於專案進展絕對是有利的，和催化劑的作用很像。
結尾：
工期控制肯定是有很多方法，可以借鑑和學習的，希望我們的團隊能走的更遠。也希望園子裡的朋友給我們提出寶貴的意見，謝謝。
關於專案的管理
從上學到現在已經2個學期了。再過一學年就畢業了。準確的說是再過6個月！學了不少，專案也做了不少，我常常聽見人們說程式設計師是在專案中成長起來的。不做專案，你自認為學得再精，也是無用的，就像乙個書呆子，飽腹經綸，卻毫無用處。在學習中老師也經常提及專案的流程，技巧，但真正體會到團隊合作專案時的流程的好處...
專案管理（八） 控制專案的範圍
接著上篇，確定了專案的利益相關者之後，先別急著進入開發階段，我們接下來要做的是先控制專案的範圍,專案的範圍控制好了才能保證後續的開發不會因為專案範圍變更而做大量無用功,看下面介紹 一 確定專案不做什麼 實踐經驗告訴我們，在進行專案範圍變更時，或者說在劃分專案邊界時，確定專案不做什麼比確定專案做什麼更...
關於專案工期的欺騙
現在做定製軟體專案有一種趨勢，就是對工期的欺騙。對方客戶上層領導要求工期是12個月，直接負責專案的客戶會說你們要在6個月完成，等到公司領導說要4個月，專案經理可能說要3個月。每一層都要剝削一點，一般到真正做專案，沒多少時間了。說的好聽一點，是給風險預留一段時間，但每一層都這麼做，嚴重擠壓專案時間。一...