筆者問過不少做軟體專案管理的人，問他們感覺最困惑的事情是什麼，大部分人的回答是「如何制定乙個真正有意義的專案計畫」。
專案開始不久，客戶和老闆就會來要專案的計畫；而此時專案組還不清楚專案的規模等細節，自然也定不出具體的工期與日程表；被逼無奈之下，專案經理只好先編造乙個計畫來應付了事。
這裡出現了乙個悖論：專案初期是否需要制定乙個計畫來指導專案後續工作的開展；如果需要，那麼在專案細節不清楚的情況下，是否可能制定出乙個足夠準確的日程計畫；如果計畫本身不正確，那麼又如何指導專案的工作。
打破悖論的關鍵在於我們如何理解「計畫」本身。人們常常將計畫
plan等同於詳細的日程表schedule，這是對計畫的一種狹隘理解。所謂計畫，指的是人們事先對未來要做什麼、以及如何做的一種約定，它並不一定要具體落實到日程表上。
工程專案的最初計畫，描述的是專案組選擇怎樣的工程方法來解決專案問題。具體到軟體專案計畫，其內容應當包括：專案組選定了什麼樣的開發生命週期模型（比如迭代模型），設定了幾個里程碑階段；準備採用什麼樣的軟體過程（比如
up統一軟體過程）來組織專案的開發活動；以及按照什麼順序來從事相關活動（比如是否在需求開發前先做業務建模）。總之，專案計畫實質上可以看作是標準的工程方法與過程在當前專案中的一次例項化。
專案組明確專案的性質並不需要太多時間，專案經理很快就能夠在計畫中，記錄下如何應用適合本專案性質的方法的決定，並定下較近時間（比如一周）內的日程安排；之後專案組遵照計畫中的方法來執行各項活動；當專案組對專案的了解程度足以支援精確估算專案規模、工作量時，才正式制定詳細的日程表，它規定了較長時間內（例如幾個月）的日程安排。也就是說，先決定怎麼做，然後才確定做的具體時間。
作為客戶和老闆，總是有一開始就想知道專案的工期和成本的衝動。這種心理雖然可以理解，但卻違背了自然規律。專案初期問專案組要專案計畫的真實目的，不是了解專案何時能夠結束，而是用來監督專案組是否選擇了正確的方法，專案是否在朝著正確的方向推進。我們必須清楚一件事情——時間搞錯了會使專案延期，但方法搞錯了卻可能使專案失敗。
Atitit 每週計畫日程表 流程表v3
atitit.每週計畫日程表 流程表 每週趨勢總結 新特性聚合 最佳實踐聚合。上週總結 本度計畫 檢查於推進年度計畫月度計畫里程碑 檢查於推進季度計畫月度計畫里程碑 上週todo彙總結轉。待報銷費用總結 大事記記錄。考勤記錄檢查以防遺漏 零時記錄清理 rembs rec casuout cc out...
忙啊，日程表排的滿滿的
advanced rails 一書的合譯和 web開發ror 大全一書的合著終於接近尾聲 公司日常工作一直緊張有序的進行著，從未遇到比較閒的sprint mysql stored procedure programming project 2007寶典 經典的7本c c primer the c p...
迴圈賽日程表的多邊形解法
迴圈賽要求比賽的每兩個選手都要進行一次比賽，而且每個選手每天都要比賽一場。這種題目的解法通常是用分治的思想來做，並且是分治方法解題的經典題目。下面的一種受多邊形啟發的方法，也能巧妙解決迴圈賽日程表問題。如圖所示，有八個選手要進行迴圈賽，畫七邊形，每個點表示乙個選手。其中最高點所代表的選手與第八位選手...