【正文】 這份文檔出品后才能開始制定。文檔由需求調(diào)研人員編制，格式簡潔，其目的是讓閱讀者毫不費勁就能了解項目的實質(zhì)內(nèi)容以及項目規(guī)模。由此可見規(guī)格書的重要性?！　　豆δ芤?guī)格書》一般由富有項目經(jīng)驗的開發(fā)人員編寫，能迅速、準確的根據(jù)需求調(diào)研的成果轉(zhuǎn)化為可編碼開發(fā)的功能模塊。比如：某個模塊的初始界面是什么樣，初始加載的數(shù)據(jù)條件是什么，頁面上有哪些按鈕，其布局如何，每個按鈕 如何響應，是彈出〔或跳轉(zhuǎn)〕另一個頁面，遇到異常情況的提示信息是什么。每個操作要說明成功與失敗的標準,有流程的模塊要畫出流程圖，流程的每一步注明參與的人員〔角色〕。每一階段的功能規(guī)格書完成后，召集項目小組開規(guī)格書評審會議。另一方面，也可以就前期從《需求調(diào)研報告》獲得的理解來對開發(fā)人員設計的規(guī)格書提出自己的意見?！　? 、面布局是否美觀、合理?！　? 、據(jù)流向是否清晰，模塊之間的數(shù)據(jù)關聯(lián)設計是否合理?！　≡u審完畢后，各自根據(jù)修改意見下去調(diào)整規(guī)格書。這個時候，項目組的所有成員〔包括測試〕都統(tǒng)一了對 項目的認識，規(guī)格書進入了凍結(jié)階段，任何人無法修改。項目經(jīng)理博客　　編寫功能規(guī)格書〔其實是設計的過程〕是一項繁復的工作，尤其是進入項目實施階段。按照正規(guī)的流程， 變更首先會導致設計的變更〔規(guī)格書〕，設計的變更指導代碼的變更。因此，我采用了折中的方法：第一次設計一氣呵成，必須保證實際 運行的系統(tǒng)與設計同步。系統(tǒng)上線后，同步的工作可以專門抽個時間來完成。在頻繁的修改下必須保證一周內(nèi)至少同步一次，并且將文檔提交給測試部檢查，出現(xiàn)問題，以bug論處。讓新進入項目組的成員能盡快的對項目有整體的印象，從而擔任工作?！　∪欢笃诘耐接忠l(fā)了另一個棘手問題：測試人員對需求變更的測試標準從哪里獲取呢?于是我們又做了改進，當需求變更到項目組手里后，召開會議，測試人 員參加。對于大的改動〔有可能會增加功能模塊〕，則還是采用先設計后開發(fā) 的原則。開發(fā)人員在編碼之前或編碼過程中如果遇到了復雜的算、業(yè)務邏輯，可以在該文檔中詳細的說明解決思路，也可以用一段偽代碼來說明。規(guī)格書中關于數(shù)據(jù)庫設計的說明直接引用該文檔。項目管理論壇　　《數(shù)據(jù)庫設計報告》記錄的內(nèi)容有：模塊名，數(shù)據(jù)表名，英文字段名，中文說明，主鍵，外鍵，索引，約束〔注明關聯(lián)的表及字段〕，數(shù)據(jù)類型，長度，能否為空以 及對整張數(shù)據(jù)表的備注信息。另外，《數(shù)據(jù)庫設計報告》也會面臨后期同步的棘手問題，其同步的策略是 做了修改就立即同步〔數(shù)據(jù)庫的改動較少，且簡單?！　?shù)據(jù)庫設計報告的評審與規(guī)格書相同，評審依據(jù)有如下幾點：　　是否留有適當?shù)娜哂啾阌谙到y(tǒng)的擴展。索引是否合理?！　≡u審通過的數(shù)據(jù)庫設計報告交給測試一份，測試人員會針對具有特殊性能要求的模塊編寫腳本做壓力測試　　十、《uml設計說明》項目管理者聯(lián)盟文章　　這個文檔不常用，我一般會在兩種情況下要求項目做業(yè)務模型設計：　　 業(yè)務相當復雜的時候。uml圖有很多種，我們一般也只常用幾種，包括：用例圖，類圖，時序圖，其中類圖又最為重要。　　原有系統(tǒng)由于種種原因〔業(yè)務了解不透，工期緊張，人員能力不具備〕在做開發(fā)之前沒有對復雜的業(yè)務進行模型設計，開發(fā)出來的系統(tǒng)雖然能用，但漏洞百出，開發(fā) 人員時常處于救火的狀態(tài)。就這樣，再作第 二個類似系統(tǒng)的時候，很自然的就操起uml工具對現(xiàn)有的代碼進行重構。其中有一個物資子系統(tǒng)，做過類似項目的朋友應該知道，物資子系統(tǒng)流程復雜還要嵌套〔大流程中嵌套小流程〕，模塊眾 多。整個子系統(tǒng)設計花了2人月，編碼用了4人月。在客戶那里上線后，需求一旦發(fā)生變更，開發(fā)人員就 心驚膽顫，生怕出現(xiàn)牽一發(fā)而動全身。最后，在項目總結(jié)會上，大家一致認為下一個物資系統(tǒng)，要想辦法從根本上解決這些問題。這樣開發(fā)出來的系 統(tǒng)才有底氣，面對客戶的需求變更我們也能知道動哪個位置、影響到哪個地方，做到心中有數(shù)。多花些功夫在前面，后面肯才不會被拖累。文檔主要包括以下幾方面的內(nèi)容：　　總體開發(fā)進度項目管理論壇　　現(xiàn)場實施進度　　項目組現(xiàn)有人員　　本周工作完成情況　　下周的工作計劃項目管理者聯(lián)盟文章　　項目存在的問題及解決方案　　需要協(xié)調(diào)的資源項目經(jīng)理圈子　　功能特性變更說明重大缺陷列表項目經(jīng)理圈子　　有數(shù)字，有比例，有詳情，能讓領導快速的掌握項目目前的進展。我要求每周五上午，每個項目經(jīng)理在11點之前向我提交《項目進度報告》。下午兩點準時召開周項目會議，人員不要太多，由每個項目組長及測試部所有人員〔測試開發(fā)比例是 1:5〕參加。其二是由測試人員強調(diào)目前項目中存在的問題，對共性問 題制定統(tǒng)一的解決方案，達到知識共享?！　h時間控制在1小時內(nèi)，由于事先都提交了項目進度報告，各項目組長都是帶著思考來的，因此溝通比較順暢。會議結(jié)束后，我會綜合項目組長提交的進度報告的內(nèi)容，同時也會附上自己的一些思考編寫一份開發(fā) 部本周工作情況匯報提交給公司領導審查。我們用的 版本控制工具是cvs。主要記錄的信息有：打標的人，打標時間，標簽名稱，標簽類型〔普通標簽，內(nèi)部測試標簽，客戶發(fā)布標簽，補丁標〕，標簽說明〔該標簽中新增了哪些內(nèi)容， 解決了哪些bug等等〕?！　∶咳諛嫿ǖ墓ぷ饔身椖拷M長安排組員輪流構建。后來，我們做了制度上的調(diào)整不再硬性規(guī)定必須5點構建，處在活動狀態(tài)的項目只要每天構建一次，有一個標簽就行了。項目經(jīng)理圈子　　十三、《項目會議紀要》　　分內(nèi)部和客戶的。如在會議中做了對項目影響重大的決定，還需要客戶負責人簽名確認。　　十四、《現(xiàn)場實施計劃》　　是臨去客戶現(xiàn)場之前編制的現(xiàn)場工作計劃?！　∥臋n內(nèi)容包括：目標，現(xiàn)場負責人，預計工作時間，現(xiàn)場工作內(nèi)容〔安裝部署，數(shù)據(jù)初始化，用戶培訓，需求調(diào)研，現(xiàn)場跟蹤使用情況等等〕，每項內(nèi)容預計工作時 間，需客戶配合事項等等。到現(xiàn)場后，第一件事就是找客戶簽訂該文檔〔前期要電話溝通好〕。有客戶引起的原因，當然也有我們自身的原因。我們自己的實施人員在去現(xiàn)場實施之前心里也沒有一個明確的目 標：要達到什么目的，做哪些事情，需要提前準備，找哪些人協(xié)助，每天的安排是什么，什么時候返程等等這些都從沒有認真的考慮，一到現(xiàn)場就被客戶牽著鼻子 走，實施工作非常被動?？蛻粢豢凑?guī)規(guī)的文檔提交過來了，還帶有公司電子簽章，自然也就認真對待了〔對此依舊毫不在意，我行我素的客戶還真有，但不多。雙方確認了計劃后，實施人員到現(xiàn)場開展工作就順利多了，計劃執(zhí)行的偏差率能控制在10%以內(nèi)，節(jié)省了出差費用成本，項目進 度也大步提高。所以說，這份文檔有他的靈活性，它更多的被認為的是雙方的一種約定，至少看上去很正規(guī)。雖然你或者你的客戶可能從來不會總到它