進度表：
基於程式設計師的工作專案而制定的進度表，叫做自下而上進度表。
基於管理階層而制定的進度表，叫做由上至下進度表。
通常需要對兩種進度表進行協商。
「我該回答你什麼問題，才能讓你更有信心給出估算？」
多做幾次估算（通過兩個不同的開發人員）是一種明智的檢查方法。
pert:（最佳估算值+4x最可能估算值+最差估算值）/6
如果你的團隊每週以90%的機率按時完成工作，隨著時間的進展，延遲的機率將會持續增加。
遠景文件很差或沒有 + 規格說明書很差或沒有 + 工作估算悲觀或樂觀 + 沒有用於整合的預算 + 沒有用於ui迭代的預算 = 進度表的祈禱
在寫下工作花費時間的估算數字時，需要對墨菲定律保持真誠的敬重。
讓測試/qa團隊參與進度安排很重要，因為他們會用自然的質疑和批評的眼光來看待工程工作。
嘗試在某一天，你開始和結束每件事情都嚴格準時。然後問問自己，是否值得這樣？為什麼是或為什麼不是？
專案規劃：
誰能對需求授權？
誰能對設計授權？
誰能對技術授權？
誰能對預算授權？
對需求及設計進行檢查的頻度如何？調整依據是什麼？
（大體來說，你所擁有的授權越少，就越需要勤奮地檢視好確認設計，並引導調整方式。）
規劃產物：
市場需求文件（mrd）：這是業務團隊或營銷團隊對世界的分析。mrd幫助定義了專案中的「what」。
遠景/範圍文件：延續並大量引用mrd。遠景文件直接定義了專案的「what」。
規格說明書：捕獲了專案最終成果的樣子。繼承遠景文件的思想，從設計和工程角度定義專案的"how"。
待續···
《專案管理之美》
最近一直在看 專案管理之美 這本書，覺得裡面的內容無論針對專案開發人員，還是產品人員都很有幫助。我們專案組一直在開發一款基於商業商業社交的一款移動應用 商麥。專案基本功能已經完成，業務功能會逐步引入，但是使用者量始終不多，所以如何引流和營銷推廣是現在的首要問題。自看過這本書之後我覺得我們開發人員忽略...
推薦好書 《專案管理之美》
軟體開發的漫長航程中，也有這樣的百慕達三角存在。在很多情況下，專案經理不得不同時對付資源 範圍 進度這三個問題。而無數的軟體專案之船，被拖入這個百慕達怪圈，喪失了自己的航向 專案管理之美 一本可以讓你從一位經驗豐富 從事多年軟體開發和web開發的經理那裡學習如何計畫 管理和領導專案。書中的那些寶貴 ...
專案整合專案管理之專案範圍管理
7.1專案範圍和專案範圍管理 7.1.1專案範圍的定義 專案範圍 為完成具有規定特徵和功能的產品 服務或結果，而必須完成的專案工作。7.1.2專案範圍管理的作用 確定在專案內包括什麼工作和不包括什麼工作 由此界定的專案範圍在專案的全生命週期內可能因某種原因而變化，專案範圍管理也對這種變化進行管理。專...