1、IT項目文檔匯總項目按時間先后順序會分為若干個階段， 每個階段會有大量的文檔產生。如：項 目前期會有項目前景說明書項目建設方案，項目需求調研階段有需 求 調研報告需求評審報告，項目設計階段有項目開發計劃功能特性列表功能規格書詳細設計報說明數據庫設計報告uml設計說明項目開發階段有項目開發進度報告項目版本說明項目會議紀要項目進入實施階段后，相關的文檔就更多了現場實施計劃項目安裝手冊系統管 理員手冊用戶手冊客戶聯系人表客戶服務器環境配置表 硬 件簽收單用戶反饋說明需求變更說明客戶培訓計劃客戶培訓簽 到表 項目試運行申請現場工作備忘錄現場人員評價表項目驗收 階段有項目階段驗收報告項目整體驗收報等等這

2、些較為常用的文檔。一、項目前景說明個人感覺是形式大于內容。該文檔主要談的是項目背景，客戶環境，預期建 設目標，產生效益，都是些大而空 的話，對項目開發沒有實際意義。這份文檔 的作用僅供甲乙雙方的高層領導參閱， 其他的項目關系人不是看不到，而是根本 就不會看。這份文檔一般是由公司的管理 咨詢部來編制，也只有他們才能站在 領導的層面上去編寫非大眾閱讀的文檔。 項目管理培訓二、項目建設方案這份文檔大多時用在投標過程中，是用于投標的技術方案。文檔根據客戶在 招標方案中所規定的內容來制定相 對詳細的建設方案此時由于沒有經過需求 調研，方案也無法過于詳細。不過，我還真沒見到中標之前就率隊到客戶現場開 展需

3、求調研的做法，客戶也不允許這樣 干，否則容易產生誤會。項目建設方 案的好壞會直接影響到投標得分的高低， 而且一般是由客戶方的信息化的專職 牽頭組織，各業務部門派人配合，組成評審 小組對其評審。因此方案的編寫大 多情況下由管理咨詢顧問來編寫。另外，該方案也為項目范圍劃定了邊界， 需求 調研也會遵照著劃定的范圍開展工作，因此該文檔在項目前期具有指導意義。注：如果項目合同附有技術協議書，那么技術協議書中所規定的項 目范圍多數與項目建設方案一致，但最終的項目范圍應以技術協議書為 準。三、需求調研報告這份文檔是必須的。原因其一：項目接下來的設計工作都將圍繞它來開展， 起提綱挈領的作用。原因之二：一 大幫

4、人風風火火的在客戶處熱熱鬧鬧的折騰 了大半月，總得有個書面的東西向自己老板和客戶的項目負責人交代吧。印象深刻的是我第一次帶隊到客戶現場作需求，連打印機，打印紙，筆記本，網線，小交換機裝著滿滿一大箱一個都不少的帶到現場。白天作需求，晚上聯機將各自的需求整理成word文檔，第二天再給客戶確 認，反復修改。直到最終的需求評 審會議通過后，連夜打印。厚厚的7大本文檔（每個業務子系統一本），然后乘以2,客戶一份，公司一份。那一晚，一個嶄新的打印機硬是被折騰得面目全非啊。 第二天大清早，還特地跑到當地的裝幀店，將這些文檔精美的包裝一番，然后各 自分頭將包裝好的需求文檔提交給客戶方對應的業務部門的經理簽名，

5、最后匯總到客戶的項目負責人手里存檔，自己再帶一份回公司存檔并作為項目設計的依 據。至此，需求調研報告就over 了。由于項目是 客戶化定制的，當項目進 入到實施過程中的時候，往往需求的變更會占到當初需求調研的30%雖，而且你還不能拿當初雙方簽訂的需求調研報告來說事兒，來 約束客戶。除非你是 行業標桿，很強勢很牛叉。所以當團隊將依據需求調研報告將功能規格書 編制出來后，其使命基本完成，轉而束之高閣。需求調研報告要根據客戶的描述加以分析和整理成如下要素：數據的輸入、輸出，業務數據量的大小及使用頻率（會據此作性能的特殊設計以及負載測 試），參 與業務的角色，有無特殊的權限控制，業務流程走向，是否與其

6、他的業 務相互關聯等等。這些要素不是通過與客戶的一次溝通交流就能獲取到。要有耐心，要細致， 還要有技巧，最關鍵的是你要懂得客戶業務。否則，客戶說的你 不懂，然后你一張嘴就顯外行。最后，你做出來的需求就三字：不靠譜。即使憑 客戶關系過了評審這一關，報告上客戶也簽了字，但后等到系統實施上線的時 候，你的需求變更基本就朝著80%勺比例上奔去了。那時候，先不談老板會怎樣 看你，就你旁邊那些個開 發的兄弟看著自己辛苦的成果一個個被客戶推翻，你 就知道可以殺人的眼神是神馬味道了。步子邁得有些大了，扯的有些遠了。咱們這里只談項目文檔，關于需求如何 作，如何才能做好，需要另起一篇詳述?？傊?，這份文檔如果交待的

7、不清楚，會 嚴重影響著項目的質量與進度。說直接一點，就是關系著項目成本或是成敗。四、需求評審報告 類似于會議紀要性質的文檔，是需求評審會議后產生的結果。記錄會議的時 問，地點，參與的人員，會議的主 題，每一項業務需求在會議中是否得到確認 這一點是整個文檔的關鍵之處，很有可能a部門提的需求與b部門的業務發生 沖突，這種事情很常見，將來會在如何做 好需求一篇中詳述。總之，這份報 告應作為需求調研報告的修正文檔，將評審后的結果同步到需求調研報告 中，也為下一次的需求評審做好準備，這樣反復幾次，需求調研報告才最終得以客戶確認。五、項目開發計劃開發計劃在需求調研需求完畢后就要著手開始制定。計劃書里包括設

8、計、開 發、測試、實施的具體時間，還要 注明每個階段的關鍵點。比如，項目第一次 構建的時間點，第一次提交測試的時間點，系統發布的時間點，項目驗收的時間 點等等，都要在計劃書中明確標明。如果 項目大、周期長，項目還要分為若干 個里程碑，每個里程碑要有詳細的進度目標及質量目標說明作為里程碑到達的檢 驗標準。另外，每個任務都除了有具體的時間點、優先級之外，還要有任務的責任人和需要客戶配合的事項。項目開發計劃 一般分兩個版本。一份給客戶，一份屬于項目組內部使 用。兩個版本相比較而言，除了規劃的粒度粗細有差別外，有時候在不得以的情 況下，其時間點也不相同。至 于原因，主要是由于客戶對信息化的認知程度有

9、限，認為開發系統是一件簡單的事情， 從而限定的時間要求比較苛刻。 但項目合 同還得簽，計劃表還得照著客戶的時間限定來做。真正進入項目實施過程中的時候，跟客戶保持良好的溝通，讓客戶理解信息化建設是一個逐步有序的過程， 引導客戶配合我們的步驟來實施。做好了這 一點，我想客戶也不會在回頭在開 發計劃上與我們糾結，畢竟，把項目做好才是硬道理。項目組內部的開發計劃要做好版本控制。比如：一個項目周期較長，分若干里程碑，那么在最初制定計劃的時候是允許前細后粗的。也就說，第一個里程碑規劃的比 較詳細，后續的里程碑有意的放粗，而等到前個里程碑將近結束的時候再 來細化后一個里程碑的工作內容，因此，項目開發計劃的每

10、個版本都要留存，并做好文檔的版本變更說明。還有，你一定要相信，項目的執行情況與事先 安排的計劃定會存在差距。那么就每周召集項目組開來一次項目會議，找出差距，分析原因，最后將計劃書完成一次同步。請記住項目開發計劃決不是由 某個人或某些人拍著腦袋弄出來的一份毫無可執行性的文檔，它應該是指引項目最終走向勝利目標的航線。 項目經理圈子六、功能特性列表 也可以叫做功能模塊列表。模塊是項目開發計劃制定過程中可劃分的最 小粒度一般情況下如此，所以，項目開發計劃必須等到這份文檔出品后 才能開始制定。功能特性列表的內容包括：子系統名稱，模塊名稱，模塊編號。文檔由 需求調研人員編制，格式簡潔，其目的是讓閱讀者毫不

11、費勁就能了解項目的實質 內容以及項目規模。項目管理者聯盟文章七、功能規格書業內有句話：功能規格書是標桿，每日構建是心跳，里程碑是生命線。由此 可見規格書的重要性。他不僅是項目開發的參照，同時也作為測試的依據，所以 它也是開發與測試協作的紐帶。功能規格書一般由富有項目經驗的開發人員編寫，能迅速、準確的根據 需求調研的成果轉化為可編碼開發的功能模塊。一份好的功能規格書的標準是讓閱讀文檔的人能夠了解系統運轉的各方面細節。比如：某個模塊的初始界面是 什么樣，初始加載的數據條件是什么，頁面上有哪些按鈕，其布局如何，每個按 鈕 如何響應，是彈出或跳轉另一個頁面，遇到異常情況的提示信息是什么。 不僅是初始頁

12、面，模塊中的每個頁面都要做如此細致的說明， 要細致到哪怕是一 個下拉框都要說明填充其中的值從哪里獲取。每個操作要說明成功與失敗的標 準，有流程的模塊要畫出流程圖，流程的每一步注明參與的人員角色。 項目 經理圈子功能規格書分階段寫，以劃分的里程碑為準。每一階段的功能規格書完成后， 召集項目小組開規格書評審會議。測試人員必須到場，一方面是為了盡早的介入 項目，對項目的構成有更直觀的認識。另一方面，也可以就前期從需求調研 報告獲得的理解來對開發人員設計的規格書提出自己的意見。評審會議由項目組長主持，每 位參與設計的人員輪流上臺講解自己設計的那部分，其余的人員 主要從以下幾個方面進行評審：1、功能設計

13、是否滿足客戶需求。2、面布局是否美觀、合理。操作是否簡單、易用。 3、據流向是否清晰，模塊之間的數據關聯設計是否合理。4、預計的開發時間是否合理，是否滿足項目的整體開發周期要求。評審完畢后，各自根據修改意見下去調整規格書。 如此反復幾個回合，確定 了功能規格書作為了項目的標桿。這個時候，項目組的所有成員包括測試都 統一了對 項目的認識，規格書進入了凍結階段，任何人無法修改。接下來，開 發人員開始按照規格書中的設計進行編碼， 測試人員開始根據規格書編寫測試用 例。項目經理博客編寫功能規格書其實是設計的過程是一項繁復的工作，尤其是進入項目 實施階段。用戶的需求變更會不可避免的導致系統與規格書的不同

14、步。按照正規的流程，變更首先會導致設計的變更規格書，設計的變更指導代碼的變更。 但實際上，項目進入實施階段后，留給項目組處理反饋的時間往往并不多， 再者， 一些細微的 調整比如界面的改動，控件的初始值如果遵循正規的流程會使 開發人員怨聲載道，士氣低下。因此，我采用了折中的方法：第一次設計一氣呵 成，必須保證實際 運行的系統與設計同步。這一點由測試部負責監控。系統上 線后，同步的工作可以專門抽個時間來完成。即，前期是系統參照規格書開發， 后期是規格書參照系統來同步。在頻繁的修改下必須保證一周內至少同步一次， 并且將文檔提交給測試部檢查，出現問題，以 bug論處。那有朋友會問，既然規 格書在后期失

15、去了標桿的作用，那還費時費勁的同步它有何意義？1、對項目后期維護起至關重要作用，完整的設計文檔在加上良好的代碼注 釋，會讓維護人員迅速的進入項目狀態。2、讓新進入項目組的成員能盡快的對項目有整體的印象，從而擔任工作。另外 還可以減少項目培訓的成本。然而，后期的同步又引發了另一個棘手問題： 測試人員對需求變更的測試標 準從哪里獲取呢？于是我們又做了改進，當需求變更到項目組手里后，召開會議， 測試人 員參加。會議上，對小的、簡單的修改當即提出解決方案，測試人員記 錄，以此作為測試依據。對于大的改動有可能會增加功能模塊，則還是采用 先設計后開發的原則。八、 詳細設計報說明作為功能規格書的一份補充文檔

16、，主要解決如何編碼的問題，測試人員 一般不看。開發人員在編碼之前或編碼過程中如果遇到了復雜的算、業務邏輯， 可以在該文檔中詳細的說明解決思路，也可以用一段偽代碼來說明。九、數據庫設計報告該文檔與功能規格書配套。規格書中關于數據庫設計的說明直接引用該 文檔。另外，項目驗收時，客戶也常要求開發方提供數據庫設計報告，作為日后 其他系統與本系統做接口的依據說明。項目管理論壇數據庫設計報告記錄的內容有：模塊名，數據表名，英文字段名，中文 說明，主鍵，外鍵，索引，約束注明關聯的表及字段，數據類型，長度，能 否為空以及對整張數據表的備注信息。對于某些關鍵字段還要對他的信所表示 的含義做詳細說明。另外，數據庫

17、設計報告也會面臨后期同步的棘手問題， 其同步的策略是 做了修改就立即同步數據庫的改動較少，且簡單。這一點與 規格書還有所不同。數據庫設計報告的評審與規格書相同，評審依據有如下幾點：1、是否留有適當的冗余便于系統的擴展。 項目管理者聯盟文章2、性能是否能達標。索引是否合理。 轉自項目管理者聯盟3、數據字段描述是否清晰易懂。 評審通過的數據庫設計報告交給測試一份，測試人員會針對具有特殊性能要 求的模塊編寫腳本做壓力測試十、uml設計說明項目管理者聯盟文章這個文檔不常用，我一般會在兩種情況下要求項目做業務模型設計：1、業務相當復雜的時候。功能規格書更多的是從模塊界面，操作方式上去闡述模塊的功能，至于

18、底層的數 據模型還得用uml圖來輔助說明。uml圖有很多種，我們一般也只常用幾種，包 括：用例圖，類圖，時序圖，其中類圖又最為重要。2、對原有系統進行重構的時候。原有系統由于種種原因業務了解不透，工期緊張，人員能力不具備在做 開發之前沒有對復雜的業務進行模型設計， 開發出來的系統雖然能用，但漏洞百 出，開發 人員時常處于救火的狀態。隨著時間推移，開發人員對業務有了更深 入的了解，慢慢的不滿足在現有的代碼基礎上修補，產生了強烈的重構的愿望。就這樣，再作第 二個類似系統的時候，很自然的就操起 uml工具對現有的代碼 進行重構。有很多的朋友不理解為什么要建模，直接用代碼說話不是更好么？我舉個項目中的

19、例子：我曾經帶隊實施過一個有 2000人企業的信息管理系統，有14個子系統，600來個功能模塊。其中有一個物資子系統，做過類似項目的朋友應該 知道，物資子系統流程復雜還要嵌套大流程中嵌套小流程，模塊眾 多。剛 開始沒有進行業務建模，功能規格書設計完畢后，直接數據庫設計報告，然后上 手編碼。整個子系統設計花了 2人月，編碼用了 4人月。等進入到測試階段后, bug滿天飛，真是按下萌產起來瓢，原定與1個月的穩定期最后又延遲了 1個月 才總算表面上穩定下來。在客戶那里上線后，需求一旦發生變更，開發人員就 心 驚膽顫，生怕出現牽一發而動全身。究其根本原因就是在面對如此復雜的業務系 統面前，沒有用建模的

20、手段將業務邏輯的全局勾勒出來，每個人只關注自己的一塊，導致數據的交互出了很多的問題。最后，在項目總結會上，大家一致認為下 一個物資系統，要想辦法從根本上解決這些問題。結果，下一個物資系統，我們 做了充分的設計，用uml對業務建模，使每個開發人員既能清晰的看到業務的 整體輪廓，又能深入細致的了解到每個類之間的交互以及提供的接口。這樣開發出來的系 統才有底氣，面對客戶的需求變更我們也能知道動哪個位置、影響到 哪個地方，做到心中有數。 所以，在以后的項目里，只要是碰見業務復雜的系統，都會要求進行建模。 多花些功夫在前面，后面肯才不會被拖累。十一、項目開發進度報告這份文檔由項目經理編制，作為項目的定期

21、一周一份文檔提交給公司領 導審閱。文檔主要包括以下幾方面的內容：1、總體開發進度 項目管理論壇2、現場實施進度3、項目組現有人員4、本周工作完成情況5、下周的工作計劃 項目管理者聯盟文章6、項目存在的問題及解決方案7、需要協調的資源 項目經理圈子8、功能特性變更說明9、重大缺陷列表 項目經理圈子有數字，有比例，有詳情，能讓領導快速的掌握項目目前的進展。 我做開發部經理時，部門經常會同時開展多個項目。 我要求每周五上午，每 個項目經理在11點之前向我提交項目進度報告。我會在 11點到12點這一 個小時內去瀏覽這些進度報告，從中發現問題。下午兩點準時召開周項目會議， 人員不要太多，由每個項目組長及

22、測試部所有人員測試開發比例是1:5參加。 會議的主要目的其一是讓各小組之間對所有的項目進展都相互有所了解，便于資源的調配。其二是由測試人員強調目前項目中存在的問題，對共性問題制定統決的解決方案，達到知識共享。其三，確定下周任務的重點及難點，是否需要協 調其他的外部資源。會議時間控制在1小時內，由于事先都提交了項目進度報告， 各項目組長都 是帶著思考來的，因此溝通比較順暢。在會議上對需要的、屬于我職責范圍內的事情拍板，超出能力范圍的，請示公司領導后再作決策。會議結束后，我會綜 合項目組長提交的進度報告的內容，同時也會附上自己的一些思考編寫一份開發 部本周工作情況匯報提交給公司領導審查。轉自項目管

23、理者聯盟十二、項目版本說明 在項目進展的過程中，我們規定了一旦項目進入實際代碼階段必須執行每日 構建每日構建是心跳，然后直到項目處于非活動狀態為止。我們用的版本控制工具是cvs。項目組成員每日下午5點之前提交代碼，5點鐘開始構建代碼， 構建成功就給項目打上標簽，并將標簽的信息登記在 版本控制說明文檔 里。 主要記錄的信息有：打標的人，打標時間，標簽名稱，標簽類型普通標簽，內 部測試標簽，客戶發布標簽，補丁標，標簽說明該標簽中新增了哪些內容， 解決了哪些bug等等。測試部每天6點根據版本控制說明下最新的標簽執 行自動化構建，第二天早上針對昨晚構建好的系統進行測試。每日構建的工作由項目組長安排組員

24、輪流構建。在項目多的情況下，由于都規定在5點鐘從服務器上下載代碼執行構建會導致服務器負載過大，相應 較慢 的現象。后來，我們做了制度上的調整不再硬性規定必須 5點構建，處在活動狀 態的項目只要每天構建一次，有一個標簽就行了。倘若6點鐘某個測試人員來告 訴我某個項目沒有標簽，那么項目組長必須有一個非常合適的理由對我解釋，當日負責構建的人員會受到考核，很顯然，這樣的問題會導致測試人員第二天只能 在舊 版本上工作，測試任務無法完成，影響項目進度。 項目經理圈子十三、項目會議紀要分內部和客戶的。項目組內部開會時必須要有會議紀要， 現場實施人員與客 戶在一起開會同樣也需要會議紀要， 打印出來雙方各執一份

25、，以便日后好對會議 中所做的決議能有所追溯。如在會議中做了對項目影響重大的決定，還需要客 戶負責人簽名確認。最后，臨項目驗收時，整理所有的會議紀要作為驗收文檔的 一部分提交給客 戶。十四、現場實施計劃 是臨去客戶現場之前編制的現場工作計劃。 因為涉及到出差費用，首先要經 過部門批準，再上報公司核準，然后再電郵給客戶，獲取客戶對計劃的認可后才 能到現場工作。文檔內容包括：目標，現場負責人，預計工作時間，現場工作內容安裝部 署，數據初始化，用戶培訓，需求調研，現場跟蹤使用情況等等，每項內容預 計工作時間，需客戶配合事項等等。最后還要留有雙方簽名認可的位置。到現 場后，第一件事就是找客戶簽訂該文檔前

26、期要電話溝通好。剛開始我的項目中是沒有這份文檔的，結果出現多次現場實施效果不理想的 情況。有客戶引起的原因，當然也有我們自身的原因。有的客戶火急火燎的讓我 們派實施 人員到現場去，等我們的人到現場后，客戶反而把我們晾在那里好多 天開始配合我們做實施的工作。我們自己的實施人員在去現場實施之前心里也沒 有一個明確的目 標：要達到什么目的，做哪些事情，需要提前準備，找哪些人 協助，每天的安排是什么，什么時候返程等等這些都從沒有認真的考慮， 一到現 場就被客戶牽著鼻子 走，實施工作非常被動。為此，我需要制定一份實施計劃， 我要求實施人員每次將出差申請單給我審批時必須附帶實施計劃，實施計劃經我認可后，再

27、提交給客戶確 認?？蛻粢豢凑幰幍奈臋n提交過來了，還帶有公 司電子簽章，自然也就認真對待了 對此依舊毫不在意，我行我素的客戶還真有， 但不多。我們規規矩矩的做 事，客戶也不好經常出爾反爾。雙方確認了計劃 后，實施人員到現場開展工作就順利多了，計劃執行的偏差率能控制在10犯內， 節省了出差費用成本，項目進 度也大步提高。其實我們也碰到過由于客戶原因 客觀因素，突發事件現場實施條件不具備了，我們會立即和客戶商定終止計 劃，返回公司，等客戶現場條件具備 后再續實施。所以說，這份文檔有他的靈 活性，它更多的被認為的是雙方的一種約定，至少看上去很正規。十五、系統安裝手冊在項目發布之前，這份文檔就應該準

28、備好。雖然你或者你的客戶可能從來不 會總到它，但你如果在驗收的時候因為沒有這份文檔而慘遭用戶拒絕簽字，那我向你深表同情，因為我曾經就這樣同情過自己。 不要在簡單的事情上犯錯誤，或 許它只是疏忽而已。安裝手冊要有有步驟，有截圖，還要有安裝過程中易出現問題的解決辦法。 最后， 把客服的電話留在文檔中最醒目的位置。項目管理培訓十六、系統管理員手冊每個系統都會有管理員，負責系統的正常運行。除此之外，他要能運用開發 方提供的工具對系統做出靈活的配置 以適應業務部門需求的變更。最基本配置 包括部門人員組織結構的設定，權限的分配，工作流的調整，字典的設置，日志 的審計。較高級的就涉及到表單的自定義，報表自定

29、義等。這些操作都不是三言兩語，或經過幾次培訓就能讓管理員能實際操作，更談不上理解。如果有一份系統管理員手冊擺在管理員的案前，能隨時指導他 如何操作，如何能達到目標， 那不是很方便。如果要做得更貼近用戶，還可以將用文字難以描述、理解的地 方做成視頻演示。不過，系統在設計的時候應盡可能的做到功能強大，操作簡化。在系統上線的時候，如果系統管理員能順利確定下來往往這一點還不太 容易，就該把操作手冊交給系統管理員，一份電子檔，一份包裝精美的紙質檔。在我們公司，管理員操作手冊由測試人員編制， 包括前面提到的系統安裝 手冊以及后面將要提到的用戶手冊都是由測試人員完成，實際上他們兼著 文檔工 作。至于對文檔質

30、量的檢測，我一般會選取一個對該系統不太了解的實 施人員，模擬為系統管理員，依據管理員手冊中的說明，完成我提出的任務。如 果能比較順利 的操作下來，ok,那就證明這文檔還不錯。如果在操作過程中多 次發生疑問，那我會仔細的查看這些疑問點是由于文檔沒描述清楚呢，還是依靠文字和截圖實在難 以描述，還是參與檢測的實施人員的能力或態度出現問題。 總之，這份文檔的好壞，之于管理員的有用還是無用，直接影響到客服人員能否 減少2/3的電話接聽 量，你知道，我指的是系統操作方面的問題。十七用戶手冊拆分到各功能模塊中就成了模塊的幫助文件， 合并起來就成為系統的用戶手 冊。用戶手冊中的大部分內容可以取自功能規格書，但

31、是要將規格書里的界面圖可能是用viso繪制的換為系統實際的截圖，再配上常見問題的 qa,就可以 交付給用戶了。由于規格書是由開發人員編制的， 其語言風格偏向與技術型，因 此測試人員要根據具體的情況將其轉換為用戶易于理解的語言風格。另外，用戶手冊有可能還要會根據不同崗位的用戶編制不同的手冊，也就是我們常說的細分。舉個例子：我們曾經給某企業做過一套物資管理系統。系統上 線前夕，有一位組員對用戶手冊提出了建議，建議將手冊分為2種，一種是給客戶公司領導中、高層看的。由于領導在系統中多數時候僅進行查詢，比對 和最終審批的操作，因此這本手冊很薄。第二種是給操作人員計劃員，采購 員，庫管員，統計員看的，涉及

32、系統使用的各方面，所以這本手冊就比較厚。 在實際使用過程中，客 戶看到我們對用戶手冊都做了精心的設計，考慮如此周 到，首先就對我們的系統報以期待的印象。特別是客戶領導，工作很忙，時間精 力有限，我們就將他最需要了 解的東西呈現給他，隱去無關的內容，降低學習 使用系統的難度，節省他的時間，從而受到領導好評。項目管理培訓十八客戶聯系人表這份文檔的主要作用是留給客服人員做回訪。 其次是項目組人員流動離職 后，客戶關系不至于丟失。一個項目在實施的過程中會接觸很多的人。 有客戶高 層，有 中層領導，有項目負責人也有最終用戶。這些人員的姓名，性別，部門 職務、辦公電話、手機、qq、email等等相關信息要

33、記錄在文檔中便于查詢。另 外還要 用備注說明該用戶在系統中承擔的角色。比如說，人力資源部的主任不 一定就是人力資源系統的最了解的用戶，倒是下面的某位具體辦事的人員反而是系統最熟悉的 人員，所有的需求都由他來提出。那么我們就要將這個信息錄入 到備注中，客服在回訪時才能抓住關鍵人物，獲取有價值的信息。項目經理博客項目聯系人表由項目實施人員編制， 根據現場情況隨時補充更新。項目經理博客十九客戶環境配置表我們做的項目大多是b/s架構，客戶端零安裝的系統。所以這份文檔記錄的 是服務器配置的信息，包括：服務器的類型應用服務器，數據庫服務器，中間 件服務器，文檔服務器，備份服務器，雙機熱備還是負載均衡，服務

34、器名和 ip,登錄名和密碼，數據庫用戶名和密碼，服務器硬件配置，軟件配置，應用系 統安裝目錄 等。由于我們的項目一般都附帶著硬件的采購和部署安裝，因此這 些信息在系統安裝完畢、正常運行后，都要記錄在該文檔中提交給用戶簽字。該 用戶不一定是系統管理員，也不一定是最終用戶一般是企業負責信息化的部 門，掌管所有的服務器的運行和維護，但系統驗收的流程中有他簽名的一個環 節。寫到這里，我想起了不久前的一件事。我們實施人員到現場做完了項目實施， 款也回了 90%等到銷售人員再去現場回10%勺尾款時，卻遇到了客戶信息部門 的投訴。那老哥顯然憋了很久一肚子火全撒在銷售人員身上，意識是說前幾次 款款找我簽名我都

35、沒為難你們，但這一次質保金的驗收我不能簽名，你們的服務 器雖然托 管在我這里，但所有的信息我都不知道，那個是數據庫服務器，哪個 是應用服務器，用戶名和密碼，系統安裝路徑全部都沒有。系統出了問題，業務 部門全都找我， 現在有質保金在這，你們還會幫著處理，我這個字一簽，出了 問題我先誰去。很顯然，我們實施人員怠慢了這位老哥。這也難怪，什么東西都 沒留下就讓別人驗收， 擱誰誰都不樂意啊。我了解到這個情況后，立即派那位 實施人員趕赴現場與銷售人員匯合，補交了該文檔并請那老哥吃餐飯，賠個禮， 字總算是簽上了。等實施人員 回來后，我在部門內樹了典型，以示警戒。我還 列出了現場實施所需要的文檔，并強制規定今

36、后出差報銷找我簽字必須附帶著實 施文檔，否則就準備找一個很充分的 理由向我解釋。二十客戶培訓計劃在現場實施過程中，培訓是必須的。有面向個人單獨的培訓，有面向部門的 大規模培訓。在遇到大規模培育時，我們都會先和客戶溝通，制定培訓目標、了 解大概多少人參與培訓，屬于哪些部門，是什么級別，分多少輪次，什么時間 開展，培訓地點在哪里，現場有沒有投影儀然后我們根據了解的情況來制作 相關的培訓資料，包括ppt,演示數據，紙質資料人手一份，考試試卷。這 些培訓資料要根據面向的培訓人員的不同而準備不同的內容，以獲得更好的培訓效果。培訓計劃 制定完畢后，再次和用戶確認，雙方認可后在計劃上簽名，接 下來就是開始準

37、備培訓資料了。客戶培訓簽到表 等到開始培訓了，就要準備簽到表了，每個參加培訓的人都要簽上自己的大 名。目的其一是有實際在的數據向客戶領導匯報培訓的效果，其二是讓各位培訓人員能嚴肅認真的對待培訓，其三是可以根據簽到表來下發考試試卷， 也可以得 到參與培訓但未考試的數據。 項目管理者聯盟有人跟我抱怨過，說培訓做得這么正規很難，首先是自己要有充分準備，其 次還得客戶配合。對于是自己的問題那沒得說，咱們必須得做好，否則系統上線 后麻煩很 多，而且客戶會把所有的責任推向我們。另外，客戶是否配合，這一 部分取決于項目經理的現場掌控能力，一部分在于我們是不是自始至終都表現的 很正規。只有我 們自身正規做事，

38、才能引導客戶正規的開展培訓，讓我們的系 統能順利上線。系統試運行申請：系統部署好了，數據初始化的工作也完成了，培訓也 大 規模開展并取得了不錯的效果，接下來就該進入系統試運行的階段了。與客 戶做好溝通，向客戶提交一份試運行申請，說明前期所做的工作，列出系統具備 試運的條 件，系統目前存在的問題以及上線后的保證措施，后續的工作安排。 這份文檔是系統進入到運行階段的重要標志，是客戶對我們系統的認可，對我們工作的認可，也 為后期項目驗收奠定基礎。 項目管理培訓文檔中要對自己所做的工作進行量化。 比如做了多少次培訓，有哪些部門參 加，合計多少人，數據初始化的工作涉及到哪些方面等， 一定要有詳實的數據輔

39、 征，給客戶以系統能順利上線的信心。 項目管理者聯盟二十二現場工作備忘錄實施人員在現場做了哪些工作，很難為公司界定，甚至連客戶有時只知道人 到現場了，但具體做了哪些事情不清楚，反而有時候會投訴公司派來的人員不得 力，沒解 決什么問題。到底是現場實施的人員消極怠工，還是由于沒有溝通好 引起客戶的誤會，我們需要有一份文檔記錄現場工作情況。這份文檔要求實施人 員每天將工作內 容詳細記錄，包括本次現場實施人員的姓名，實施時間，每天 什么時間做了什么事情，接觸了哪些人，解決了什么問題，此次實施還遺留什么 問題，下階段的工作安 排。最后在臨走之前提交給客戶，一方面讓用戶知曉我 們的工作成果，另一方面讓給客

40、戶留有反饋渠道， 簽署自己的意見。我們在很多 的項目中就采取這樣的工作方 式，客戶認可這種做法，公司內部對外地出差人 員的工作也有檢驗的依據。到驗收時候，這些文檔我們也會作為項目過程文檔提 交給客戶。 二十三項目階段驗收申請 項目管理者聯盟文章這份文檔要根據項目規模的大小以及簽訂合同時所約定的付款方式來決定 是否需要。一般的小項目都采用是3:6:1的付款方式，那就不存在項目階段驗收 的情況。如果是大項目，我們一般會力爭的付款方式是3:3:3:1，那么在申請第二個30%勺款項時，就必須向客戶提交項目階段驗收申請了。該文檔要詳 細 描述前階段的項目進展情況，能量化的地方一定要用數字說話，比如項目歷

41、 時多長，完成了哪些功能模塊，有哪些模塊上線運行了，沒有投運行的模塊是出于什么原 因。到現場工作了多長時間，做了多少次培訓等等，最后還要列出下 階段的工作安排，需要客戶配合的工作。除了這些有據可查的數據描述外， 一些 宏觀的，客套 的，應景的話也要作為總結信的語言放在最后。比如：項目為客 戶信息化取得什么成果，給客戶解決了什么問題、帶來什么好處，還要重點感謝 客戶的配合等。這份 文檔的終極目標是讓參與驗收的客戶人員能在上面簽字蓋 章，所以這份虛實結合、講求策略面對一塌糊涂的項目這是必須的的文檔一 股由項目經理親自操刀。二十四項目整體驗收申請基本上和階段驗收報告類似一一虛實結合、 講求策略。但階

42、段驗收申請中的 下階段計劃安排要改為項目的后期維護服務， 算是在這里做個小小的承諾一定 要根據合 同條款來。另外，在提交整體驗收申請時，要附上項目過程文檔。 除了涉及到公司機密的文件之外，能夠給的全部復印一份交給客戶，不要讓客戶 在文檔方面挑我 們的毛病。當然，能否順利通過驗收，絕不是文檔做好就能搞 定的事情，更多的是我們要用項目文檔來管理規范我們的項目過程，畢竟， 項目做得好才是通過驗 收的堅實基礎。終于寫完了項目文檔知多少這一系列博客， 也是自己的第一篇博客。在上下 班的途中，在出差的火車上用手機一個字，一個字碼出來的。回顧自己從業 it 行業8年，從程序員，項目經理，部門經理一步步的走開

43、，始終堅持在一線上。 既要深入到現場與各種類型客戶打交道、 協調關系，又要在部門內部深抓項目管 理、平衡人 力資源。在完成公司的任務之外還要考慮團隊的建設， 技術的走向， 產品的創新。面對公司的發展，還得從公司層面上去和高層保持思想統一， 帶領 部門人員貫徹執 行，即使是以犧牲部門利益為代價。這么多年的忙與累，成功與失敗，經驗與教訓，責難與鼓勵，技術與管理， 點點滴滴、積累于心。寫博客既是表達心中所想的一種渠道， 更是自我梳理項目 管理經驗 的過程。之所以選擇項目文檔之多少作為開篇博客，其理由是因為我 所列的文檔貫穿于項目的整個過程，包括項目前期的投標，項目進行中的需求， 設計，開發，測 試，

44、實施以及項目后期的驗收及維護。通過這么些個文檔首先 將項目流程梳理清楚，至于流程的每個環節那都需要單獨的篇章來回顧和總結。有的公司規模小，項目用不上這么些文檔。有的公司規模大，管理更為規范， 文檔不止我列的這么一些例如：代碼復查報告，風險分析報告等，還有的公 司走的 是敏捷開發之路，遵循簡單的文檔、面對面的溝通原則。總之，文檔在 項目管理的過程中起著工具、手段的作用，是溝通的橋梁，是約束的規范，是產 出的結果。我們公司做得是行業應用軟件，技術門檻不高，所以在招聘人員的時候，我 大多數都會考察應聘人員的項目經歷， 團隊合作經驗及現場應對能力。在問到項 目經歷的 時候，我一般會問應聘者在項目過程中

45、會留下哪些文檔。從他對文檔 的描述細節中我大都能看出他參與過項目的哪些階段。 然后再根據文檔把問題延 伸下去。我發 現，看文檔的人和寫文檔的人根本是兩回事?？次臋n的人多是在別人的成果上進行工作，而寫文檔的人才真正參與到工作其中。因此，從文檔的角度來考察個人的項 目經歷具備一定的說服力。寫到最后，我還想再強調一下。文檔只是工具，是需要靈活運用的工具，是需要 根據項目的規模，人員的素質來匹配組合的。如果一味的遵守某些Iso或cmmi的 要求為了文檔而文檔，其結果將會適得其反，不僅項目質量與進度沒有顯著的改 善，還會弄得怨聲四起，士氣低落。只有弄清每個文檔背后所要解決的問題文 檔 只是結果，才能有效的利用文檔這個工具去解決自己的問題。四、一輩子孤單并不可怕，如果我們可以從中提煉出自由，那我們就是幸福的。許多長久的關系都以為忘記了當初所堅持與擁有的，最后又開始羨慕起孤單的人。五、戀愛，在感情上，當你想征服對方的時候，實際上已經在一定程度上被對方征服了。首先是對方對你的吸