【正文】 公司，等客戶現(xiàn)場條件具備 后再續(xù)實施。我們規(guī)規(guī)矩矩的做 事，客戶也不好經(jīng)常出爾反爾〕。為此，我需要制定一份實施計劃，我要求實施人員每次將出差申請單給我審批時必須附帶實施計劃，實施計劃經(jīng)我認(rèn)可后，再提交給客戶確 認(rèn)。有的客戶火急火燎的讓我們派實施 人員到現(xiàn)場去，等我們的人到現(xiàn)場后，客戶反而把我們晾在那里好多天開始配合我們做實施的工作。　　剛開始我的項目中是沒有這份文檔的，結(jié)果出現(xiàn)多次現(xiàn)場實施效果不理想的情況。最后還要留有雙方簽名認(rèn)可的位置。因為涉及到出差費用，首先要經(jīng)過部門批準(zhǔn)，再上報公司核準(zhǔn)，然后再電郵給客戶，獲取客戶對計劃的認(rèn)可后才能到現(xiàn)場工作。最后，臨項目驗收時，整理所有的會議紀(jì)要作為驗收文檔的一部分提交給客 戶。項目組內(nèi)部開會時必須要有會議紀(jì)要，現(xiàn)場實施人員與客戶在一起開會同樣也需要會議紀(jì)要，打印出來雙方各執(zhí)一份，以便日后好對會議中所做的 決議能有所追溯。倘若6點鐘某個測試人員來告 訴我某個項目沒有標(biāo)簽，那么項目組長必須有一個非常合適的理由對我解釋，當(dāng)日負(fù)責(zé)構(gòu)建的人員會受到考核，很顯然，這樣的問題會導(dǎo)致測試人員第二天只能在舊 版本上工作，測試任務(wù)無法完成，影響項目進(jìn)度。在項目多的情況下，由于都規(guī)定在5點鐘從服務(wù)器上下載代碼執(zhí)行構(gòu)建會導(dǎo)致服務(wù)器負(fù)載過大，相應(yīng) 較慢的現(xiàn)象。測試部每天6點根據(jù)《版本控制說明》下最新的標(biāo)簽執(zhí)行自動化構(gòu)建，第二天早上針對昨晚構(gòu)建好的系統(tǒng)進(jìn)行測試。項目組成員每日下午5點之前提交代碼，5點鐘開始構(gòu)建代碼，構(gòu)建成功就給項目打上標(biāo)簽，并將標(biāo)簽的信息登記在《版本控制說明》文檔 里。轉(zhuǎn)自項目管理者聯(lián)盟　　十二、《項目版本說明》　　在項目進(jìn)展的過程中，我們規(guī)定了一旦項目進(jìn)入實際代碼階段必須執(zhí)行每日構(gòu)建〔每日構(gòu)建是心跳〕，然后直到項目處于非活動狀態(tài)為止。在會議上對需要的、屬于我職責(zé)范 圍內(nèi)的事情拍板，超出能力范圍的，請示公司領(lǐng)導(dǎo)后再作決策。其三，確定下周任務(wù)的重點及難點，是否需要協(xié)調(diào)其他的外部資源。會議的主要目的其一是讓各小組之間對所有的項目進(jìn)展都相互有所了解，便于資源的調(diào)配。我會在11點到 12點這一個小時內(nèi)去瀏覽這些進(jìn)度報告，從中發(fā)現(xiàn)問題?！　∥易鲩_發(fā)部經(jīng)理時，部門經(jīng)常會同時開展多個項目?！　∈弧ⅰ俄椖块_發(fā)進(jìn)度報告》　　這份文檔由項目經(jīng)理編制，作為項目的定期〔一周一份〕文檔提交給公司領(lǐng)導(dǎo)審閱?！　∷裕谝院蟮捻椖坷?，只要是碰見業(yè)務(wù)復(fù)雜的系統(tǒng)，都會要求進(jìn)行建模。結(jié)果，下一個物資系統(tǒng)，我們做了 充分的設(shè)計，用uml對業(yè)務(wù)建模，使每個開發(fā)人員既能清晰的看到業(yè)務(wù)的整體輪廓，又能深入細(xì)致的了解到每個類之間的交互以及提供的接口。究其根本原因就是在面對如此復(fù)雜的業(yè)務(wù)系統(tǒng)面前，沒有用建模的手段將業(yè)務(wù)邏輯的全局勾勒出來，每個人只關(guān)注自己的一 塊，導(dǎo)致數(shù)據(jù)的交互出了很多的問題。等進(jìn)入到測試階段 后，bug滿天飛，真是按下葫蘆起來瓢，原定與1個月的穩(wěn)定期最后又延遲了1個月才總算表面上穩(wěn)定下來。剛開始沒有進(jìn)行業(yè)務(wù)建模，功能規(guī)格書設(shè)計完畢后，直接數(shù)據(jù)庫設(shè)計報告，然后上手編碼?！　∮泻芏嗟呐笥巡焕斫鉃槭裁匆?，直接用代碼說話不是更好么?我舉個項目中的例子：我曾經(jīng)帶隊實施過一個有2000人企業(yè)的信息管理系統(tǒng)， 有14個子系統(tǒng)，600來個功能模塊。隨著時間推移，開發(fā)人員對業(yè)務(wù)有了更深入的了解，慢慢的不滿足在現(xiàn)有的代碼基礎(chǔ)上修補(bǔ)，產(chǎn)生了強(qiáng)烈的重構(gòu)的愿望?！　?對原有系統(tǒng)進(jìn)行重構(gòu)的時候。功能規(guī)格書更多的是從模塊界面，操作方式上去闡述模塊的功能，至于底層的數(shù)據(jù)模型還得用uml圖來輔助說明。轉(zhuǎn)自項目管理者聯(lián)盟　　數(shù)據(jù)字段描述是否清晰易懂。項目管理者聯(lián)盟文章　　性能是否能達(dá)標(biāo)。這一點與規(guī)格書還有所不同〕。對于某些關(guān)鍵字段還要對他的值所表示的含義做詳細(xì)說明。另外，項目驗收時，客戶也常要求開發(fā)方提供數(shù)據(jù)庫設(shè)計報告，作為日后其他系統(tǒng)與本系統(tǒng)做接口的依據(jù)說明?！　【?、《數(shù)據(jù)庫設(shè)計報告》　　該文檔與《功能規(guī)格書》配套。　　八、 《詳細(xì)設(shè)計報說明》　　作為《功能規(guī)格書》的一份補(bǔ)充文檔，主要解決如何編碼的問題，測試人員一般不看。會議上，對小的、簡單的修改當(dāng)即提出解決方案，測試人員記錄，以此作為測試依據(jù)。另外還可以減少項目培訓(xùn)的成本。那有朋友會問，既然規(guī)格書在后期失去了標(biāo)桿的作 用，那還費時費勁的同步它有何意義?　　對項目后期維護(hù)起至關(guān)重要作用，完整的設(shè)計文檔在加上良好的代碼注釋，會讓維護(hù)人員迅速的進(jìn)入項目狀態(tài)。即，前期是系統(tǒng)參照規(guī)格書開發(fā)，后期是規(guī)格書參照系統(tǒng)來 同步。這一點由測試部負(fù)責(zé)監(jiān)控。但實際上，項目進(jìn)入實施階段后，留給項目組處理反饋的時間往往并不多，再者，一些細(xì)微的 調(diào)整〔比如界面的改動，控件的初始值〕如果遵循正規(guī)的流程會使開發(fā)人員怨聲載道，士氣低下。用戶的需求變更會不可避免的導(dǎo)致系統(tǒng)與規(guī)格書的不同步。接下來，開發(fā)人員開始按照規(guī)格書中的設(shè)計進(jìn)行編碼，測試人員開始根據(jù)規(guī)格書編寫測試用例。如此反復(fù)幾個回合，確定了功能規(guī)格書作為了項目的標(biāo)桿?！　☆A(yù)計的開發(fā)時間是否合理，是否滿足項目的整體開發(fā)周期要求。操作是否簡單、易用。評審會議由項目組長主持，每 位參與設(shè)計的人員輪流上臺講解自己設(shè)計的那部分，其余的人員主要從以下幾個方面進(jìn)行評審：　　功能設(shè)計是否滿足客戶需求。測試人員必須到場，一方面是為了盡早的介入項目， 對項目的構(gòu)成有更直觀的認(rèn)識。項目經(jīng)理圈子　　功能規(guī)格書分階段寫，以劃分的里程碑為準(zhǔn)。不僅是初始頁面，模塊中的每個頁面都要做如此細(xì)致的說明，要細(xì)致到哪怕是一個下拉 框都要說明填充其中的值從哪里獲取。一份好的功能規(guī)格書的標(biāo)準(zhǔn) 是讓閱讀文檔的人能夠了解系統(tǒng)運轉(zhuǎn)的各方面細(xì)節(jié)。他不僅是項目開發(fā)的參照，同時也作為測試的依據(jù)，所以它也是開發(fā)與測試協(xié)作的紐帶。項目管理者聯(lián)盟文章　　七、《功能規(guī)格書》　　業(yè)內(nèi)有句話：功能規(guī)格書是標(biāo)桿，每日構(gòu)建是心跳，里程碑是生命線。　　《功能特性列表》的內(nèi)容包括：子系統(tǒng)名稱，模塊名稱，模塊編號。項目經(jīng)理圈子　　六、《功能特性列表》　　也可以叫做《功能模塊列表》。那么就每周召集項目組開來一次項目會 議，找出差距，分析原因，最后將計劃書完成一次同步。也就說，第一個里程碑規(guī)劃的比 較詳細(xì)，后續(xù)的里程碑有意的放粗，而等到前個里程碑將近結(jié)束的時候再來細(xì)化后一個里程碑的工作內(nèi)容，因此，《項目開發(fā)計劃》 的每個版本都要留存，并做好文檔的版本變更說明。項目組內(nèi)部的開發(fā)計劃要做好版本控制。真正進(jìn)入項目實施過程中的時候，跟客戶保持良好的溝通，讓客戶理解信息化建設(shè)是一個逐步有序的過程，引導(dǎo)客戶配合我們的步驟來實施。至 于原因，主要是由于客戶對信息化的認(rèn)知程度有限，