開始做專案是一件令人激動的事情，專案組的每個成員都面臨著新的機會和挑戰。但同時也多少有些令人不安，大家都會考慮這樣乙個問題："我們如何按時完成乙個高質量的專案?"因為在專案開始之前往往存在許多不確定的因素，它們也許會一直持續到整個專案結束。所以在專案準備階段，也有許多任務作要做。
前提條件與主要任務
開始做專案是需要前提條件的(輸入條件)，不同的專案型別有不同的前提條件。如果是為客戶定製的專案，需要與客戶達成某種形式的合作意向，對於比較大型的專案，則中標往往被作為乙個最基本的前提條件;如果是產品專案，則需要市場調研報告等作為輸入條件;即使是那些內部研發專案，也需要類似可行性報告的分析來表明執行專案的必要性。通常，我們把此階段稱為調研階段或論證階段，一旦此階段的結論認為可以正式啟動專案，就進入專案的準備階段或啟動階段。
專案準備階段的主要任務是簽訂合同(外部專案)或立項(內部專案)，此階段所生成的工作說明書(statement of work，sow)與後續軟體開發活動直接相關。sow通常作為合同或立項材料乙個最主要的組成部分。在sow中定義專案的工作範圍，並依據工作範圍確定所需的時間、質量、費用和資源。這些內容要得到相關利益人的認可，作為合同的組成部分對雙方具有約束力。
典型困境與分析
客戶：你們最多需要多長時間能夠完成專案?
開發方：我們現在還不清楚需要完成的工作，如果你們把需求提得更明確一些，我們會給出乙個可信度較高的計畫。
客戶：你們最好先做出乙個東西來，我們就可以提出更明確的需求。現在不可能提出所有的需求。
開發方：那我們如何確定交付時間?我們甚至不知道需要完成哪些功能。
這是軟體開發的乙個典型的例子，也許就是我們總有那麼多的專案滯後於交付時間的主要原因。這種情形對於開發商和客戶都充滿了風險，其結果往往是風險變成了事實。如何在這個階段降低這種由於工作範圍不明確所造成的風險，具有重要的意義。軟體開發的同行們經常會彼此詢問："你們是不是又要封閉開發了?"所謂的封閉開發即是每週工作六天(也有七天的情形)，每天工作接近12小時。封閉開發或專案延期的最主要原因來自兩個方面：一是工作範圍不明確;另一點是不知道自己的生產率有多高。這兩個因素使專案計畫與實際的情況偏離甚遠。
對於軟體專案而言，乙個最為直觀的衡量標準就是時間，每個人都可以對時間做出直觀的判斷。影響專案的交付時間主要有三方面的因素：專案的工作範圍、成本和質量。有這樣乙個比喻可以說明它們之間的關係：將專案看作是一部複雜的機械裝置，把專案的交付時間、工作範圍、成本和質量看作是四個控制桿，調節每乙個控制桿都要至少調節其它的控制桿。所以我們經常會在專案的執行過程中調節專案的人員投入。而對於質量的調節，則通過壓縮測試時間保證專案的交付時間不至於延遲過多。進度拖延的壓力使開發組織往往不計成本地投入人力，而使專案的收益狀況惡化;進度的壓力同時導致測試時間的壓縮，使專案在交付給使用者以後仍然存在許多遺留缺陷，降低了客戶的滿意度;而專案範圍的變更則更直接地影響到其它三個方面，會使本來就充滿風險的專案雪上加霜。基於上述原因，我們實際執行的專案往往需要同時滿足四個方面的要求。
git gerrit 實踐經驗
用git一段時間，體驗還是比較好。尤其沒次改一批檔案，檔案列表非常清晰。和gerrit結合，diff,review 都非常方便，尤其你不需要自己手動提交到伺服器 有些缺點 如果多人改同乙個目錄，不是很方便。有些體驗如下 1 工作前都用 repo start dev 開始乙個branch 再工作 2 ...
專案實踐經驗總結 （1）
media screen and min width 768px media screen and min width 992px media screen and min width 1200 注意下順序，如果你把 media min width 768px 寫在了下面那麼很悲劇，media sc...
有關專案管理的一點實踐經驗！
引言 在論壇上經常看到很多人有關專案管理的經驗，而且都是長篇大論，侃侃而談 總是看得我暈頭轉向，總感覺，都是停留在人的作用上，總是強調管理中的人為因素，幾乎很多條目都是帶有很強的人為色彩，看完後，總是覺得這些經驗很不錯，但是自己往往卻很難在自己的專案中具體實施。想法 本人是乙個實踐主義者 自己在專案...