項目文檔知多少

---

一、《項目前景說明》

個人感覺是形式大于內容。該文檔主要談的是項目背景，客戶環境，預期建設目標，產生效益，都是些大而空的話，對項目開發沒有實際意義。這份文檔的作用僅供甲乙雙方的高層領導參閱，其他的項目關系人不是看不到，而是根本就不會看。這份文檔一般是由公司的管理咨詢部來編制，也只有他們才能站在領導的層面上去編寫非大眾閱讀的文檔。

二、《項目建設方案》

這份文檔大多時用在投標過程中，是用于投標的技術方案。文檔根據客戶在招標方案中所規定的內容來制定相對詳細的建設方案〔此時由于沒有經過需求調研，方案也無法過于詳細。不過，我還真沒見到中標之前就率隊到客戶現場開展需求調研的做法，客戶也不允許這樣干,否則容易產生誤會〕?！俄椖拷ㄔO方案》的好壞會直接影響到投標得分的高低，而且一般是由客戶方的信息化的專職牽頭組織，各業務部門派人配合，組成評審小組對其評審。因此方案的編寫大多情況下由管理咨詢顧問來編寫。另外，該方案也為項目范圍劃定了邊界，需求調研也會遵照著劃定的范圍開展工作，因此該文檔在項目前期具有指導意義。

注：如果項目合同附有《技術協議書》，那么《技術協議書》中所規定的項目范圍多數與《項目建設方案》一致，但最終的項目范圍應以《技術協議書》為準。

三、《需求調研報告》

這份文檔是必須的。原因其一：項目接下來的設計工作都將圍繞它來開展，起提綱挈領的作用。原因之二：一大幫人風風火火的在客戶處熱熱鬧鬧的折騰了大半月，總得有個書面的東西向自己老板和客戶的項目負責人交代吧。印象深刻的是我第一次帶隊到客戶現場作需求，連打印機，打印紙，筆記本，網線，小交換機裝著滿滿一大箱一個都不少的帶到現場。白天作需求，晚上聯機將各自的需求整理成word文檔,第二天再給客戶確認，反復修改。直到最終的需求評審會議通過后，連夜打印。厚厚的7大本文檔（每個業務子系統一本），然后乘以2，客戶一份，公司一份。那一晚，一個嶄新的打印機硬是被折騰得面目全非啊。第二天大清早，還特地跑到當地的裝幀店，將這些文檔精美的包裝一番，然后各自分頭將包裝好的需求文檔提交給客戶方對應的業務部門的經理簽名，最后匯總到客戶的項目負責人手里存檔，自己再帶一份回公司存檔并作為項目設計的依據。至此，《需求調研報告》就over了。由于項目是客戶化定制的，當項目進入到實施過程中的時候，往往需求的變更會占到當初需求調研的30%強，而且你還不能拿當初雙方簽訂的《需求調研報告》來說事兒，來約束客戶。除非你是行業標桿，很強勢很牛叉。所以當團隊將依據《需求調研報告》將《功能規格書》編制出來后，其使命基本完成，轉而束之高閣。

《需求調研報告》要根據客戶的描述加以分析和整理成如下要素：數據的輸入、輸出，業務數據量的大小及使用頻率（會據此作性能的特殊設計以及負載測試），參與業務的角色，有無特殊的權限控制，業務流程走向，是否與其他的業務相互關聯等等。這些要素不是通過與客戶的一次溝通交流就能獲取到。要有耐心，要細致，還要有技巧，最關鍵的是你要懂得客戶業務。否則，客戶說的你不懂，然后你一張嘴就顯外行。最后，你做出來的需求就三字：不靠譜。即使憑客戶關系過了評審這一關，報告上客戶也簽了字，但后等到系統實施上線的時候，你的需求變更基本就朝著80%的比例上奔去了。那時候，先不談老板會怎樣看你，就你旁邊那些個開發的兄弟看著自己辛苦的成果一個個被客戶推翻，你就知道可以殺人的眼神是神馬味道了。

步子邁得有些大了，扯的有些遠了。咱們這里只談項目文檔，關于需求如何作，如何才能做好，需要另起一篇詳述?？傊?，這份文檔如果交待的不清楚，會嚴重影響著項目的質量與進度。說直接一點，就是關系著項目成本或是成敗。

四、《需求評審報告》

類似于會議紀要性質的文檔，是需求評審會議后產生的結果。記錄會議的時間，地點，參與的人員，會議的主題，每一項業務需求在會議中是否得到確認〔這一點是整個文檔的關鍵之處，很有可能a部門提的需求與b部門的業務發生沖突，這種事情很常見，將來會在如何做好需求一篇中詳述〕?？傊?，這份報告應作為《需求調研報告》的修正文檔，將評審后的結果同步到《需求調研報告》中，也為下一次的需求評審做好準備，這樣反復幾次，《需求調研報告》才最終得以客戶確認。

五、《項目開發計劃》

開發計劃在需求調研需求完畢后就要著手開始制定。計劃書里包括設計、開發、測試、實施的具體時間，還要注明每個階段的關鍵點。比如，項目第一次構建的時間點，第一次提交測試的時間點，系統發布的時間點，項目驗收的時間點等等，都要在計劃書中明確標明。如果項目大、周期長，項目還要分為若干個里程碑，每個里程碑要有詳細的進度目標及質量目標說明作為里程碑到達的檢驗標準。另外，每個任務都除了有具體的時間點、優先級之外，還要有任務的責任人和需要客戶配合的事項。

《項目開發計劃》一般分兩個版本。一份給客戶，一份屬于項目組內部使用。兩個版本相比較而言，除了規劃的粒度粗細有差別外，有時候在不得以的情況下，其時間點也不相同。至于原因，主要是由于客戶對信息化的認知程度有限，認為開發系統是一件簡單的事情，從而限定的時間要求比較苛刻。但項目合同還得簽，計劃表還得照著客戶的時間限定來做。真正進入項目實施過程中的時候，跟客戶保持良好的溝通，讓客戶理解信息化建設是一個逐步有序的過程，引導客戶配合我們的步驟來實施。做好了這一點，我想客戶也不會在回頭在開發計劃上與我們糾結，畢竟，把項目做好才是硬道理。項目組內部的開發計劃要做好版本控制。比如：一個項目周期較長，分若干里程碑，那么在最初制定計劃的時候是允許前細后粗的。也就說，第一個里程碑規劃的比較詳細，后續的里程碑有意的放粗，而等到前個里程碑將近結束的時候再來細化后一個里程碑的工作內容，因此，《項目開發計劃》的每個版本都要留存，并做好文檔的版本變更說明。還有，你一定要相信，項目的執行情況與事先安排的計劃定會存在差距。那么就每周召集項目組開來一次項目會議，找出差距，分析原因，最后將計劃書完成一次同步。請記住《項目開發計劃》決不是由某個人或某些人拍著腦袋弄出來的一份毫無可執行性的文檔，它應該是指引項目最終走向勝利目標的航線。

六、《功能特性列表》

也可以叫做《功能模塊列表》。模塊是項目開發計劃制定過程中可劃分的最小粒度〔一般情況下如此〕，所以，《項目開發計劃》必須等到這份文檔出品后才能開始制定。 《功能特性列表》的內容包括：子系統名稱，模塊名稱，模塊編號。文檔由需求調研人員編制，格式簡潔，其目的是讓閱讀者毫不費勁就能了解項目的實質內容以及項目規模。

七、《功能規格書》

業內有句話：功能規格書是標桿，每日構建是心跳，里程碑是生命線。由此可見規格書的重要性。他不僅是項目開發的參照，同時也作為測試的依據，所以它也是開發與測試協作的紐帶。

《功能規格書》一般由富有項目經驗的開發人員編寫，能迅速、準確的根據需求調研的成果轉化為可編碼開發的功能模塊。一份好的功能規格書的標準是讓閱讀文檔的人能夠了解系統運轉的各方面細節。比如：某個模塊的初始界面是什么樣，初始加載的數據條件是什么，頁面上有哪些按鈕，其布局如何，每個按鈕如何響應，是彈出〔或跳轉〕另一個頁面，遇到異常情況的提示信息是什么。不僅是初始頁面，模塊中的每個頁面都要做如此細致的說明，要細致到哪怕是一個下拉框都要說明填充其中的值從哪里獲取。每個操作要說明成功與失敗的標準,有流程的模塊要畫出流程圖，流程的每一步注明參與的人員〔角色〕。

功能規格書分階段寫，以劃分的里程碑為準。每一階段的功能規格書完成后，召集項目小組開規格書評審會議。測試人員必須到場，一方面是為了盡早的介入項目，對項目的構成有更直觀的認識。另一方面，也可以就前期從《需求調研報告》獲得的理解來對開發人員設計的規格書提出自己的意見。評審會議由項目組長主持，每位參與設計的人員輪流上臺講解自己設計的那部分，其余的人員主要從以下幾個方面進行評審：
1、功能設計是否滿足客戶需求。
2、面布局是否美觀、合理。操作是否簡單、易用。
3、據流向是否清晰，模塊之間的數據關聯設計是否合理。
4、預計的開發時間是否合理，是否滿足項目的整體開發周期要求。

評審完畢后，各自根據修改意見下去調整規格書。如此反復幾個回合，確定了功能規格書作為了項目的標桿。這個時候，項目組的所有成員〔包括測試〕都統一了對項目的認識，規格書進入了凍結階段，任何人無法修改。接下來，開發人員開始按照規格書中的設計進行編碼，測試人員開始根據規格書編寫測試用例。

編寫功能規格書〔其實是設計的過程〕是一項繁復的工作，尤其是進入項目實施階段。用戶的需求變更會不可避免的導致系統與規格書的不同步。按照正規的流程，變更首先會導致設計的變更〔規格書〕，設計的變更指導代碼的變更。但實際上，項目進入實施階段后，留給項目組處理反饋的時間往往并不多，再者，一些細微的調整〔比如界面的改動，控件的初始值〕如果遵循正規的流程會使開發人員怨聲載道，士氣低下。因此，我采用了折中的方法：第一次設計一氣呵成，必須保證實際運行的系統與設計同步。這一點由測試部負責監控。系統上線后，同步的工作可以專門抽個時間來完成。即，前期是系統參照規格書開發，后期是規格書參照系統來同步。在頻繁的修改下必須保證一周內至少同步一次，并且將文檔提交給測試部檢查，出現問題，以bug論處。那有朋友會問，既然規格書在后期失去了標桿的作用，那還費時費勁的同步它有何意義？
1、對項目后期維護起至關重要作用，完整的設計文檔在加上良好的代碼注釋，會讓維護人員迅速的進入項目狀態。
2、讓新進入項目組的成員能盡快的對項目有整體的印象，從而擔任工作。另外還可以減少項目培訓的成本。

然而，后期的同步又引發了另一個棘手問題：測試人員對需求變更的測試標準從哪里獲取呢？于是我們又做了改進，當需求變更到項目組手里后，召開會議，測試人員參加。會議上，對小的、簡單的修改當即提出解決方案，測試人員記錄，以此作為測試依據。對于大的改動〔有可能會增加功能模塊〕，則還是采用先設計后開發的原則。

八、《詳細設計報說明》

作為《功能規格書》的一份補充文檔，主要解決如何編碼的問題，測試人員一般不看。開發人員在編碼之前或編碼過程中如果遇到了復雜的算、業務邏輯，可以在該文檔中詳細的說明解決思路，也可以用一段偽代碼來說明。

九、《數據庫設計報告》

該文檔與《功能規格書》配套。規格書中關于數據庫設計的說明直接引用該文檔。另外，項目驗收時，客戶也常要求開發方提供數據庫設計報告，作為日后其他系統與本系統做接口的依據說明。

《數據庫設計報告》記錄的內容有：模塊名，數據表名，英文字段名，中文說明，主鍵，外鍵，索引，約束〔注明關聯的表及字段〕，數據類型，長度，能否為空以及對整張數據表的備注信息。對于某些關鍵字段還要對他的值所表示的含義做詳細說明。另外，《數據庫設計報告》也會面臨后期同步的棘手問題，其同步的策略是做了修改就立即同步〔數據庫的改動較少，且簡單。這一點與規格書還有所不同〕。

數據庫設計報告的評審與規格書相同，評審依據有如下幾點：
1、是否留有適當的冗余便于系統的擴展。
2、性能是否能達標。索引是否合理。
3、數據字段描述是否清晰易懂。

評審通過的數據庫設計報告交給測試一份，測試人員會針對具有特殊性能要求的模塊編寫腳本做壓力測試。

十、《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點根據《版本控制說明》下最新的標簽執行自動化構建，第二天早上針對昨晚構建好的系統進行測試。

每日構建的工作由項目組長安排組員輪流構建。在項目多的情況下，由于都規定在5點鐘從服務器上下載代碼執行構建會導致服務器負載過大，相應較慢的現象。后來，我們做了制度上的調整不再硬性規定必須5點構建，處在活動狀態的項目只要每天構建一次，有一個標簽就行了。倘若6點鐘某個測試人員來告訴我某個項目沒有標簽，那么項目組長必須有一個非常合適的理由對我解釋，當日負責構建的人員會受到考核，很顯然，這樣的問題會導致測試人員第二天只能在舊版本上工作，測試任務無法完成，影響項目進度。

十三、《項目會議紀要》

分內部和客戶的。項目組內部開會時必須要有會議紀要，現場實施人員與客戶在一起開會同樣也需要會議紀要，打印出來雙方各執一份，以便日后好對會議中所做的決議能有所追溯。如在會議中做了對項目影響重大的決定，還需要客戶負責人簽名確認。最后，臨項目驗收時，整理所有的會議紀要作為驗收文檔的一部分提交給客戶。

十四、《現場實施計劃》

是臨去客戶現場之前編制的現場工作計劃。因為涉及到出差費用，首先要經過部門批準，再上報公司核準，然后再電郵給客戶，獲取客戶對計劃的認可后才能到現場工作。

文檔內容包括：目標，現場負責人，預計工作時間，現場工作內容〔安裝部署，數據初始化，用戶培訓，需求調研，現場跟蹤使用情況等等〕，每項內容預計工作時間，需客戶配合事項等等。最后還要留有雙方簽名認可的位置。到現場后，第一件事就是找客戶簽訂該文檔〔前期要電話溝通好〕。

剛開始我的項目中是沒有這份文檔的，結果出現多次現場實施效果不理想的情況。有客戶引起的原因，當然也有我們自身的原因。有的客戶火急火燎的讓我們派實施人員到現場去，等我們的人到現場后，客戶反而把我們晾在那里好多天開始配合我們做實施的工作。我們自己的實施人員在去現場實施之前心里也沒有一個明確的目標：要達到什么目的，做哪些事情，需要提前準備，找哪些人協助，每天的安排是什么，什么時候返程等等這些都從沒有認真的考慮，一到現場就被客戶牽著鼻子走，實施工作非常被動。為此，我需要制定一份實施計劃，我要求實施人員每次將出差申請單給我審批時必須附帶實施計劃，實施計劃經我認可后，再提交給客戶確認?？蛻粢豢凑幰幍奈臋n提交過來了，還帶有公司電子簽章，自然也就認真對待了〔對此依舊毫不在意，我行我素的客戶還真有，但不多。我們規規矩矩的做事，客戶也不好經常出爾反爾〕。雙方確認了計劃后，實施人員到現場開展工作就順利多了，計劃執行的偏差率能控制在10%以內，節省了出差費用成本，項目進度也大步提高。其實我們也碰到過由于客戶原因〔客觀因素，突發事件〕現場實施條件不具備了，我們會立即和客戶商定終止計劃，返回公司，等客戶現場條件具備后再續實施。所以說，這份文檔有他的靈活性，它更多的被認為的是雙方的一種約定，至少看上去很正規。

十五、《系統安裝手冊》

在項目發布之前，這份文檔就應該準備好。雖然你或者你的客戶可能從來不會總到它，但你如果在驗收的時候因為沒有這份文檔而慘遭用戶拒絕簽字，那我向你深表同情，因為我曾經就這樣同情過自己。不要在簡單的事情上犯錯誤，或許它只是疏忽而已。

安裝手冊要有有步驟，有截圖，還要有安裝過程中易出現問題的解決辦法。最后，把客服的電話留在文檔中最醒目的位置。

十六、《系統管理員手冊》

每個系統都會有管理員，負責系統的正常運行。除此之外，他要能運用開發方提供的工具對系統做出靈活的配置以適應業務部門需求的變更。最基本配置包括部門人員組織結構的設定，權限的分配，工作流的調整，字典的設置，日志的審計。較高級的就涉及到表單的自定義，報表自定義等。這些操作都不是三言兩語，或經過幾次培訓就能讓管理員能實際操作，更談不上理解。如果有一份系統管理員手冊擺在管理員的案前，能隨時指導他如何操作，如何能達到目標，那不是很方便?！踩绻龅酶N近用戶，還可以將用文字難以描述、理解的地方做成視頻演示。不過，系統在設計的時候應盡可能的做到功能強大，操作簡化?！吃谙到y上線的時候，如果系統管理員能順利確定下來〔往往這一點還不太容易〕，就該把操作手冊交給系統管理員，一份電子檔，一份包裝精美的紙質檔。

在我們公司，管理員操作手冊由測試人員編制，包括前面提到的《系統安裝手冊》以及后面將要提到的《用戶手冊》都是由測試人員完成，實際上他們兼著文檔工作。至于對文檔質量的檢測，我一般會選取一個對該系統不太了解的實施人員，模擬為系統管理員，依據管理員手冊中的說明，完成我提出的任務。如果能比較順利的操作下來，ok，那就證明這文檔還不錯。如果在操作過程中多次發生疑問，那我會仔細的查看這些疑問點是由于文檔沒描述清楚呢，還是依靠文字和截圖實在難以描述，還是參與檢測的實施人員的能力或態度出現問題?？傊?，這份文檔的好壞，之于管理員的有用還是無用，直接影響到客服人員能否減少2／3的電話接聽量，你知道，我指的是系統操作方面的問題。

十七《用戶手冊》

拆分到各功能模塊中就成了模塊的幫助文件，合并起來就成為系統的用戶手冊。用戶手冊中的大部分內容可以取自功能規格書，但是要將規格書里的界面圖〔可能是用viso繪制的〕換為系統實際的截圖，再配上常見問題的qa,就可以交付給用戶了。由于規格書是由開發人員編制的，其語言風格偏向與技術型，因此測試人員要根據具體的情況將其轉換為用戶易于理解的語言風格。

另外，用戶手冊有可能還要會根據不同崗位的用戶編制不同的手冊，也就是我們常說的細分。舉個例子：我們曾經給某企業做過一套物資管理系統。系統上線前夕，有一位組員對用戶手冊提出了建議，建議將手冊分為2種，一種是給客戶公司領導〔中、高層〕看的。由于領導在系統中多數時候僅進行查詢，比對和最終審批的操作，因此這本手冊很薄。第二種是給操作人員〔計劃員，采購員，庫管員，統計員〕看的，涉及系統使用的各方面，所以這本手冊就比較厚。在實際使用過程中，客戶看到我們對用戶手冊都做了精心的設計，考慮如此周到，首先就對我們的系統報以期待的印象。特別是客戶領導，工作很忙，時間精力有限，我們就將他最需要了解的東西呈現給他，隱去無關的內容，降低學習使用系統的難度，節省他的時間，從而受到領導好評。

十八《客戶聯系人表》

這份文檔的主要作用是留給客服人員做回訪。其次是項目組人員流動〔離職〕后，客戶關系不至于丟失。一個項目在實施的過程中會接觸很多的人。有客戶高層，有中層領導，有項目負責人也有最終用戶。這些人員的姓名，性別，部門職務、辦公電話、手機、qq、email等等相關信息要記錄在文檔中便于查詢。另外還要用備注說明該用戶在系統中承擔的角色。比如說，人力資源部的主任不一定就是人力資源系統的最了解的用戶，倒是下面的某位具體辦事的人員反而是系統最熟悉的人員，所有的需求都由他來提出。那么我們就要將這個信息錄入到備注中，客服在回訪時才能抓住關鍵人物，獲取有價值的信息。

項目聯系人表由項目實施人員編制，根據現場情況隨時補充更新。

十九《客戶環境配置表》

我們做的項目大多是b/s架構，客戶端零安裝的系統。所以這份文檔記錄的是服務器配置的信息，包括：服務器的類型〔應用服務器，數據庫服務器，中間件服務器，文檔服務器，備份服務器〕，雙機熱備還是負載均衡，服務器名和ip,登錄名和密碼，數據庫用戶名和密碼，服務器硬件配置，軟件配置，應用系統安裝目錄等。由于我們的項目一般都附帶著硬件的采購和部署安裝，因此這些信息在系統安裝完畢、正常運行后，都要記錄在該文檔中提交給用戶簽字。該用戶不一定是系統管理員，也不一定是最終用戶〔一般是企業負責信息化的部門，掌管所有的服務器的運行和維護〕，但系統驗收的流程中有他簽名的一個環節。

寫到這里，我想起了不久前的一件事。我們實施人員到現場做完了項目實施，款也回了90%。等到銷售人員再去現場回10%的尾款時，卻遇到了客戶信息部門的投訴。那老哥顯然憋了很久一肚子火全撒在銷售人員身上，意識是說前幾次回款找我簽名我都沒為難你們，但這一次質保金的驗收我不能簽名，你們的服務器雖然托管在我這里，但所有的信息我都不知道，那個是數據庫服務器，哪個是應用服務器，用戶名和密碼，系統安裝路徑全部都沒有。系統出了問題，業務部門全都找我，現在有質保金在這，你們還會幫著處理，我這個字一簽，出了問題我先誰去。很顯然，我們實施人員怠慢了這位老哥。這也難怪，什么東西都沒留下就讓別人驗收，擱誰誰都不樂意啊。我了解到這個情況后，立即派那位實施人員趕赴現場與銷售人員匯合，補交了該文檔并請那老哥吃餐飯，賠個禮，字總算是簽上了。等實施人員回來后，我在部門內樹了典型，以示警戒。我還列出了現場實施所需要的文檔，并強制規定今后出差報銷找我簽字必須附帶著實施文檔，否則就準備找一個很充分的理由向我解釋。

二十《客戶培訓計劃》

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

二十一《客戶培訓簽到表》

等到開始培訓了，就要準備簽到表了，每個參加培訓的人都要簽上自己的大名。目的其一是有實際在的數據向客戶領導匯報培訓的效果，其二是讓各位培訓人員能嚴肅認真的對待培訓，其三是可以根據簽到表來下發考試試卷，也可以得到參與培訓但未考試的數據。

有人跟我抱怨過，說培訓做得這么正規很難，首先是自己要有充分準備，其次還得客戶配合。對于是自己的問題那沒得說，咱們必須得做好，否則系統上線后麻煩很多，而且客戶會把所有的責任推向我們。另外，客戶是否配合，這一部分取決于項目經理的現場掌控能力，一部分在于我們是不是自始至終都表現的很正規。只有我們自身正規做事，才能引導客戶正規的開展培訓，讓我們的系統能順利上線。 《系統試運行申請》：系統部署好了，數據初始化的工作也完成了，培訓也大規模開展并取得了不錯的效果，接下來就該進入系統試運行的階段了。與客戶做好溝通，向客戶提交一份試運行申請，說明前期所做的工作，列出系統具備試運的條件，系統目前存在的問題以及上線后的保證措施，后續的工作安排。這份文檔是系統進入到運行階段的重要標志，是客戶對我們系統的認可，對我們工作的認可，也為后期項目驗收奠定基礎。

文檔中要對自己所做的工作進行量化。比如做了多少次培訓，有哪些部門參加，合計多少人，數據初始化的工作涉及到哪些方面等，一定要有詳實的數據輔征，給客戶以系統能順利上線的信心。

二十二《現場工作備忘錄》

實施人員在現場做了哪些工作，很難為公司界定，甚至連客戶有時只知道人到現場了，但具體做了哪些事情不清楚，反而有時候會投訴公司派來的人員不得力，沒解決什么問題。到底是現場實施的人員消極怠工，還是由于沒有溝通好引起客戶的誤會，我們需要有一份文檔記錄現場工作情況。這份文檔要求實施人員每天將工作內容詳細記錄，包括本次現場實施人員的姓名，實施時間，每天什么時間做了什么事情，接觸了哪些人，解決了什么問題，此次實施還遺留什么問題，下階段的工作安排。最后在臨走之前提交給客戶，一方面讓用戶知曉我們的工作成果，另一方面讓給客戶留有反饋渠道，簽署自己的意見。我們在很多的項目中就采取這樣的工作方式，客戶認可這種做法，公司內部對外地出差人員的工作也有檢驗的依據。到驗收時候，這些文檔我們也會作為項目過程文檔提交給客戶。

二十三《項目階段驗收申請》

這份文檔要根據項目規模的大小以及簽訂合同時所約定的付款方式來決定是否需要。一般的小項目都采用是3:6:1的付款方式，那就不存在項目階段驗收的情況。如果是大項目，我們一般會力爭的付款方式是3:3:3:1，那么在申請第二個30%的款項時，就必須向客戶提交《項目階段驗收申請》了。該文檔要詳細描述前階段的項目進展情況，能量化的地方一定要用數字說話，比如項目歷時多長，完成了哪些功能模塊，有哪些模塊上線運行了，沒有投運行的模塊是出于什么原因。到現場工作了多長時間，做了多少次培訓等等，最后還要列出下階段的工作安排，需要客戶配合的工作。除了這些有據可查的數據描述外，一些宏觀的，客套的，應景的話也要作為總結信的語言放在最后。比如：項目為客戶信息化取得什么成果，給客戶解決了什么問題、帶來什么好處，還要重點感謝客戶的配合等。這份文檔的終極目標是讓參與驗收的客戶人員能在上面簽字蓋章，所以這份虛實結合、講求策略〔面對一塌糊涂的項目這是必須的〕的文檔一般由項目經理親自操刀。

二十四《項目整體驗收申請》

基本上和階段驗收報告類似——虛實結合、講求策略。但階段驗收申請中的下階段計劃安排要改為項目的后期維護服務，算是在這里做個小小的承諾〔一定要根據合同條款來〕。另外，在提交整體驗收申請時，要附上項目過程文檔。除了涉及到公司機密的文件之外，能夠給的全部復印一份交給客戶，不要讓客戶在文檔方面挑我們的毛病。當然，能否順利通過驗收，絕不是文檔做好就能搞定的事情，更多的是我們要用項目文檔來管理〔規范〕我們的項目過程，畢竟，項目做得好才是通過驗收的堅實基礎。

終于寫完了項目文檔知多少這一系列博客，也是自己的第一篇博客。在上下班的途中，在出差的火車上用手機一個字，一個字碼出來的?；仡欁约簭臉Iit行業8年，從程序員，項目經理，部門經理一步步的走開，始終堅持在一線上。既要深入到現場與各種類型客戶打交道、協調關系，又要在部門內部深抓項目管理、平衡人力資源。在完成公司的任務之外還要考慮團隊的建設，技術的走向，產品的創新。面對公司的發展，還得從公司層面上去和高層保持思想統一，帶領部門人員貫徹執行，即使是以犧牲部門利益為代價。

這么多年的忙與累，成功與失敗，經驗與教訓，責難與鼓勵，技術與管理，點點滴滴、積累于心。寫博客既是表達心中所想的一種渠道，更是自我梳理項目管理經驗的過程。之所以選擇項目文檔之多少作為開篇博客，其理由是因為我所列的文檔貫穿于項目的整個過程，包括項目前期的投標，項目進行中的需求，設計，開發，測試，實施以及項目后期的驗收及維護。通過這么些個文檔首先將項目流程梳理清楚，至于流程的每個環節那都需要單獨的篇章來回顧和總結。

有的公司規模小，項目用不上這么些文檔。有的公司規模大，管理更為規范，文檔不止我列的這么一些〔例如：代碼復查報告，風險分析報告等〕，還有的公司走的是敏捷開發之路，遵循簡單的文檔、面對面的溝通原則?？傊?，文檔在項目管理的過程中起著工具、手段的作用，是溝通的橋梁，是約束的規范，是產出的結果。

我們公司做得是行業應用軟件，技術門檻不高，所以在招聘人員的時候，我大多數都會考察應聘人員的項目經歷，團隊合作經驗及現場應對能力。在問到項目經歷的時候，我一般會問應聘者在項目過程中會留下哪些文檔。從他對文檔的描述細節中我大都能看出他參與過項目的哪些階段。然后再根據文檔把問題延伸下去。我發現，看文檔的人和寫文檔的人根本是兩回事?？次臋n的人多是在別人的成果上進行工作，而寫文檔的人才真正參與到工作其中。因此，從文檔的角度來考察個人的項目經歷具備一定的說服力。

寫到最后，我還想再強調一下。文檔只是工具，是需要靈活運用的工具，是需要根據項目的規模，人員的素質來匹配組合的。如果一味的遵守某些Iso或cmmi的要求為了文檔而文檔，其結果將會適得其反，不僅項目質量與進度沒有顯著的改善，還會弄得怨聲四起，士氣低落。只有弄清每個文檔背后所要解決的問題〔文檔只是結果〕，才能有效的利用文檔這個工具去解決自己的問題。