十、《uml設計說明》
這個文件不常用，我一般會在兩種情況下要求專案做業務模型設計：
1、 業務相當複雜的時候。
功能規格書更多的是從模組介面，操作方式上去闡述模組的功能，至於底層的資料模型還得用uml圖來輔助說明。uml圖有很多種，我們一般也只常用幾種，包括：用例圖，類圖，時序圖，其中類圖又最為重要。
2、 對原有系統進行重構的時候。
原有系統由於種種原因〔業務了解不透，工期緊張，人員能力不具備〕在做開發之前沒有對複雜的業務進行模型設計，開發出來的系統雖然能用，但漏洞百出，開發人員時常處於救火的狀態。隨著時間推移，開發人員對業務有了更深入的了解，慢慢的不滿足在現有的**基礎上修補，產生了強烈的重構的願望。就這樣，再作第二個類似系統的時候，很自然的就操起uml工具對現有的**進行重構。
有很多的朋友不理解為什麼要建模，直接用**說話不是更好麼？我舉個專案中的例子：我曾經帶隊實施過乙個有2000人企業的資訊管理系統，有14個子系統，600來個功能模組。其中有乙個物資子系統，做過類似專案的朋友應該知道，物資子系統流程複雜還要巢狀〔大流程中巢狀小流程〕，模組眾多。剛開始沒有進行業務建模，功能規格書設計完畢後，直接資料庫設計報告，然後上手編碼。整個子系統設計花了2人月，編碼用了4人月。等進入到測試階段後，bug滿天飛，真是按下葫蘆起來瓢，原定與1個月的穩定期最後又延遲了1個月才總算表面上穩定下來。在客戶那裡上線後，需求一旦發生變更，開發人員就心驚膽顫，生怕出現牽一髮而動全身。究其根本原因就是在面對如此複雜的業務系統面前，沒有用建模的手段將業務邏輯的全域性勾勒出來，每個人只關注自己的一塊，導致資料的互動出了很多的問題。最後，在專案總結會上，大家一致認為下乙個物資系統，要想辦法從根本上解決這些問題。結果，下乙個物資系統，我們做了充分的設計，用uml對業務建模，使每個開發人員既能清晰的看到業務的整體輪廓，又能深入細緻的了解到每個類之間的互動以及提供的介面。這樣開發出來的系統才有底氣，面對客戶的需求變更我們也能知道動哪個位置、影響到哪個地方，做到心中有數。
所以，在以後的專案裡，只要是碰見業務複雜的系統，都會要求進行建模。多花些功夫在前面，後面肯才不會被拖累。
十一、《專案開發進度報告》
這份文件由專案經理編制，作為專案的定期〔一周乙份〕文件提交給公司領導審閱。文件主要包括以下幾方面的內容：
1、總體開發進度
2、現場實施進度
3、專案組現有人員
4、本週工作完成情況
5、下週的工作計畫
6、專案存在的問題及解決方案
7、需要協調的資源
8、功能特性變更說明
9、重大缺陷列表
有數字，有比例，有詳情，能讓領導快速的掌握專案目前的進展。
我做開發部經理時，部門經常會同時開展多個專案。我要求每週五上午，每個專案經理在11點之前向我提交《專案進度報告》。我會在11點到12點這乙個小時內去瀏覽這些進度報告，從中發現問題。下午兩點準時召開周專案會議，人員不要太多，由每個專案組長及測試部所有人員〔測試開發比例是1:5〕參加。會議的主要目的其一是讓各小組之間對所有的專案進展都相互有所了解，便於資源的調配。其二是由測試人員強調目前專案中存在的問題，對共性問題制定統一的解決方案，達到知識共享。其三，確定下週任務的重點及難點，是否需要協調其他的外部資源。
會議時間控制在1小時內，由於事先都提交了專案進度報告，各專案組長都是帶著思考來的，因此溝通比較順暢。在會議上對需要的、屬於我職責範圍內的事情拍板，超出能力範圍的，請示公司領導後再作決策。會議結束後，我會綜合專案組長提交的進度報告的內容，同時也會附上自己的一些思考編寫乙份開發部本週工作情況匯報提交給公司領導審查。
十二、《專案版本說明》
在專案進展的過程中，我們規定了一旦專案進入實際**階段必須執行每日構建〔每日構建是心跳〕，然後直到專案處於非活動狀態為止。我們用的版本控制工具是cvs。專案組成員每日下午5點之前提交**，5點鐘開始構建**，構建成功就給專案打上標籤，並將標籤的資訊登記在《版本控制說明》文件裡。主要記錄的資訊有：打標的人，打標時間，標籤名稱，標籤型別〔普通標籤，內部測試標籤，客戶發布標籤，補丁標〕，標籤說明〔該標籤中新增了哪些內容，解決了哪些bug等等〕。測試部每天6點根據《版本控制說明》下最新的標籤執行自動化構建，第二天早上針對昨晚構建好的系統進行測試。
十三、《專案會議紀要》
分內部和客戶的。專案組內部開會時必須要有會議紀要，現場實施人員與客戶在一起開會同樣也需要會議紀要，列印出來雙方各執乙份，以便日後好對會議中所做的決議能有所追溯。如在會議中做了對專案影響重大的決定，還需要客戶負責人簽名確認。最後，臨專案驗收時，整理所有的會議紀要作為驗收文件的一部分提交給客戶。
專案文件知多少（四）
十八 客戶聯絡人表 這份文件的主要作用是留給客服人員做回訪。其次是專案組人員流動 離職 後，客戶關係不至於丟失。乙個專案在實施的過程中會接觸很多的人。有客戶高層，有中層領導，有專案負責人也有終端使用者。這些人員的姓名，性別，部門職務 辦公 手機 qq email等等相關資訊要記錄在文件中便於查詢。另...
軟體文件知多少？
如今，軟體開發越來越複雜，軟體功能也越來越豐富。而幾乎所有成熟的商業軟體，都是靠乙個開發團隊齊心協力的血汗結晶。羅馬不是一天建成的！當我們震撼於microsoft windows的驚世巨著的同時，也道聽途說了微軟公司軟體工程是如何的完善規範。的確，集數百名員工幾年的共同努力之大成，軟體專案管理的成敗...
軟體文件知多少？
如今，軟體開發越來越複雜，軟體功能也越來越豐富。而幾乎所有成熟的商業軟體，都是靠乙個開發團隊齊心協力的血汗結晶。羅馬不是一天建成的！當我們震撼於microsoft windows的驚世巨著的同時，也道聽途說了微軟公司軟體工程是如何的完善規範。的確，集數百名員工幾年的共同努力之大成，軟體專案管理的成敗...