如何做好軟件項目的驗收工作

 項目驗收是公司乃至每個項目成員都想要的結果,一旦驗收對公司來說就是,可以收驗收階段的款了,不需要再投入那麼多人力到項目當中,項目終於可以告一段落,大家都可以輕鬆一下了。項目驗收是一系列細緻工作完成到位的結果,而不是某一點的成功或某個人能力就可以促成的事情。一個項目的驗收,一般是由一系列驗收準備工作組成的。如果我們在最終驗收前,已經將很多階段的工作細化並得到認可執行,那麼項目驗收也就是水到渠成的事情了。

  首先我們要明確進入驗收的前提。很多人都認爲只要我們完成了合同中規定的內容,完成了需求規格說明中規定的工作,並且按合同試運行了幾個月,應該就可以驗收了。就可以拿着合同或技術協議與客戶談論驗收的相關事宜了。

  但實際上客戶往往不同意在此時驗收。他們的判斷往往不是招標書、合同、技術協議、需求規格說明書等文檔。其實這些文檔無論做得如何細緻,對用戶而言並沒太大的參考價值。客戶關心的是他們的業務是否真地在系統中運作,並且運行良好,並以此作爲檢驗項目驗收的標準。當然有的項目也可以通過商務運作,在業務實現不太好的情況下驗收。

  1、在項目實施過程中注重里程碑的確定,制定階段性目標

  如果要做好一個項目,完成項目的驗收條件,主要還是以業務是否可用作爲衡量的。不是一定得實現所有用戶的需求(這裏指的是口頭上的需求,如果落實到文字上的還是要實現的),也不是隻有將一些所謂的技術難點解決用戶就會同意驗收,而是我們可以完成一定的階段應用業務目標。

  我們從進行需求調研的時候就要主動控制項目的邊界,將一個一個業務流根據客戶方的實際情況合理組織實施順序,形成我們項目實施計劃中的里程碑點,明確達到里程碑點的條件,並得到雙方一致正式認可。

  沒有雙方高度達成一致的里程碑認可,也就是沒有項目目標約定,沒有目標約定的項目實施計劃一定會經常變更內容、變更初始設定目標,導致計劃不可控制,更談不上驗收。

  很多人希望通過詳細的系統需求規格說明書來定義項目要實現的內容和業務目標,這是很有必要的,但需求規格說明書得到認可並非是通過用戶審覈就可以的結果,應該想辦法讓用戶一起參與到需求規格說明書的制定過程中來,變成用戶自己推導出來的業務實施目標,未來纔不容易變形。

  2、積極主動地與客戶進行溝通

  項目中一定要有溝通策略,和高管如何彙報工作進展,取得支持?和中層如何就業務目標不斷確認,逐步清晰?和基層如何就項目應用操作模式達成一致,持續改進?都需要通過溝通反饋完成。

  溝通的作用對於高管是讓他們清楚我們一直按照項目目標前進,每個階段工作進展是否順利,影響項目正常運做原因是什麼,需要哪些資源幫助。和高管溝通比較多的話,第一個好處是高管經常聽彙報就知道項目進展程度,可以安排反饋檢查,看是否具備我們所說的進展,這樣一旦認可了各個階段目標後,最終要求高管簽字確認也就順理成章了。

  給高管彙報技巧就是簡潔明瞭,真實客觀,有理有據分析問題,提出對策建議請其決策即可。

  中層往往是項目主要的推動力量和實際執行者,也往往是對具體業務需求最主要的要求者,他們對企業實際運做過程最清楚,提出要求最具體,而且項目驗收與否沒有中層的同意往往也是不太容易做到的。

  往往通過前期業務調研只能對企業項目目標有一個大的,宏觀的認識,但如何細化並最終落實並非是一步到位的過程。因此在整個項目過程中,雙方項目組要不斷溝通,特別是企業中層溝通,才能逐步認識越來越深刻,最終達成一致。

  和基層的溝通主要體現對最終用戶的關懷,定期主動和最終用戶溝通,消除一些怨氣,讓用戶能堅持用下去,這個時候我們往往發現很多用戶真的是非常好相處,儘管軟件還有很多值得改進的地方,但他們一旦認可我們團隊,反而會盡心盡力幫助我們推動項目的進行。

  目前我們公司一般要求每個項目經理在項目進行中都要填寫詳盡的項目月報,反映項目的進度,與計劃的偏差,完成的項目內容,投入人力,目前項目存在的問題,以及預計項目下月的進度等等。將進度月報交部門負責人、項目管理中心、總經辦審閱。

  類似地也要制定針對客戶的月報甚至是週報,將相關的信息反應到客戶方的負責人,及相關高層。可以先發郵件,然後還要電話落實收到並口頭簡要彙報,特別是高管層,千萬不要以爲發了就等於別人會去看,一定要口頭跟進彙報一次,保證客戶各方面負責人對項目進展做到心中有數。

  在項目的過程中,我們也需要注意平時做人的積累,比如要做到講誠信,講原則。主要是三條:1)做不到的事情千萬別隨意承諾;2)承諾的事情一定要努力做到;3)每次做到的事情都進步一點點。按這三條做事,即使在系統的使用過程中總會有這樣或那樣的一些不方便,用戶也會慢慢接受稍微長一點的響應週期,也會用更多積極性眼光看現在的問題,也相信問題一定有人響應,也一定可以得到解決。進而使我們和客戶之間形成一種較爲和諧的關係。

  3、寫好備忘錄和問題跟蹤記錄

  在一個漫長項目週期中,很多工作做了也就做了,認可了也就認可了,時間一長也就忘記了很多承諾和約定,到了驗收的時候就可能重新翻出來,這種事情很多人可能都經歷過,明明說可以先不做的內容最終驗收的時候又成了必要條件。

  每次備忘錄要口頭交流認可後纔打印簽字確定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行,保障項目在每次工作基礎上不斷前進,並用備忘錄約束雙方的行爲。

  同時我們建議在收集項目出現的各種問題時,採用問題跟蹤記錄表的形式,這樣可以一目瞭然地顯示出我們曾經收集到的各種問題,目前的解決情況,以及還有什麼問題沒有解決,準備什麼時候解決。這樣客戶和我們都會對目前的情況非常瞭解,通過不斷地解決出現的問題,來收斂可能出現的問題,當存在的問題越來越少時,也就表示我們的系統已經在接近驗收的標準了。

  4、驗收階段的準備工作及注意事項

  當系統經過一段試運行,具備驗收的各項條件之後,我們就需要着手驗收階段的準備工作了。首先我們需要把到目前爲止完成的工作進行一個總結,列出我們已經完成的各項目工作成果、各類文檔,對合同以及各類約定的技術文檔中的相關內容進行自查,要徹底瞭解系統目前完成的情況如何,是否已經完成了與客戶方達成的各項書面約定以及口頭約定,沒有完成的,如果是書面約定,準備採取什麼策略去進一步完成或者採取一定的迴避措施,使客戶在驗收的時候不再提出這些未實現的需求。

  做一個詳細的驗收計劃是非常必要的,可以用來作爲驗收階段的工作指導。這就需要與客戶進行詳細的溝通,再次明確驗收前需要完成的工作,儘量避免客戶方在此階段提出過多的更改需求,這是極爲重要的。驗收計劃中不光要有需要繼續完成的工作,還需要有一個相對固定的工期,使雙方都繼續朝着這個方向去努力,防止無限制的拖延。

  我們很多的項目碰到的一些常見問題就是軟件開發完之後,很多客戶也不使用,如果我們去催促他們的時候,就經常推脫工作太忙,還有其它的事要做等等,或者也就是應付一下隨便提一兩個小問題。而等我們提出要驗收的時候,他們又總是覺得這也不滿意那也不滿意,總之是怕承擔相應的責任,不願意驗收。

  針對這種情況我想主要還是想辦法讓客戶儘量把系統使用起來,只有在使用中才能發現問題,我們也才能解決問題,使系統能更好地運行。如果是基層的人員不願意使用,我們可以走上層路線,使客戶的高層瞭解項目正常運行的重要性,也使他們意識到項目驗收的重要性,意識到無限制地拖延下去會對政府機會的權威、形象和公司的收益造成不好的影響,利用他們的主觀積極性剋制拖沓的工作作風。如果項目經理在這方面沒有太多的辦法的時候,可以讓市場人員動用一些商業運作的手段,或者提請公司高層出面與客戶方的高層儘早溝通,明確系統運行的各項工作。

  還有一種情況就是客戶無窮盡地提出一些需求,一些主要領導對系統指指點點,隨便一句話,就要進行需求變更,項目的範圍不斷擴大,導致項目試運行一直無法結束。甚至一些客戶追求系統的完美,提出了很多高難度的需求,導致我們需要投入較多的精力去解決。

  這種情況,我覺得是一些政府主管領導對電子政務認識上存在一定的誤區,認爲這麼一個系統就應該能夠解決所有的問題。其實信息系統只是政府管理工作的一種輔助性手段,信息化不是一步到位工程,而是一種長期的、不斷改善的系統工程。我們應該想法讓他們結合實際情況,提出他們真正需要解決的問題,而不是依靠他們的長官意志,提出一些不切合實際的、易變的需求。要實現這一點,就需要項目經理安排人員定期到政府機關進行信息化普及培訓以及項目管理知識培訓。同時在合適的情況下,建議在該項目驗收後啓動新的項目來完成一些新的需求。

  項目驗收對任何一個項目管理者都是一個極大的挑戰,即使已經採取本文提到的幾種手段,也不能保證我們的項目能夠順利驗收,但作爲項目的承建方,我們所能做到的就是儘量做好我們所能控制的事情,另外一些很難由我們控制的事情則需要借用一些其它的力量去完成,比如請市場部運用一些商業手段來促成項目的驗收等等。本文中提出的這些建議,是希望能夠起到拋磚引玉的效果,希望各位同仁可以提出更多更好的方法來促進我們的項目如期驗收。

發佈了4 篇原創文章 · 獲贊 0 · 訪問量 2萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章