[軟體專案]怎樣做好軟體專案驗收工作
大中小[軟體專案]怎樣做好軟體專案的驗收工作
專案驗收是公司乃至每個專案成員都想要的結果，一旦驗收對公司來說就是，可以收驗收階段的款了，不需要再投入那麼多人力到專案當中，專案終於可以告一段落，大家都可以輕鬆一下了。專案驗收是一系列細緻工作完成到位的結果，而不是某一點的成功或某個人能力就可以促成的事情。乙個專案的驗收，一般是由一系列驗收準備工作組成的。如果我們在最終驗收前，已經將很多階段的工作細化並得到認可執行，那麼專案驗收也就是水到渠成的事情了。
首先我們要明確進入驗收的前提。很多人都認為只要我們完成了合同中規定的內容，完成了需求規格說明中規定的工作，並且按合同試執行了幾個月，應該就可以驗收了。就可以拿著合同或技術協議與客戶談論驗收的相關事宜了。
但實際上客戶往往不同意在此時驗收。他們的判斷往往不是招標書、合同、技術協議、需求規格說明書等文件。其實這些文件無論做得如何細緻，對使用者而言並沒太大的參考價值。客戶關心的是他們的業務是否真地在系統中運作，並且執行良好，並以此作為檢驗專案驗收的標準。當然有的專案也可以通過商務運作，在業務實現不太好的情況下驗收。http://www.mscto.com
1、在專案實施過程中注重里程碑的確定，制定階段性目標 軟體開發網
如果要做好乙個專案，完成專案的驗收條件，主要還是以業務是否可用作為衡量的。不是一定得實現所有使用者的需求（這裡指的是口頭上的需求，如果落實到文字上的還是要實現的），也不是只有將一些所謂的技術難點解決使用者就會同意驗收，而是我們可以完成一定的階段應用業務目標。
軟體開發網
我們從進行需求調研的時候就要主動控制專案的邊界，將乙個乙個業務流根據客戶方的實際情況合理組織實施順序，形成我們專案實施計畫中的里程碑點，明確達到里程碑點的條件，並得到雙方一致正式認可。
沒有雙方高度達成一致的里程碑認可，也就是沒有專案目標約定，沒有目標約定的專案實施計畫一定會經常變更內容、變更初始設定目標，導致計畫不可控制，更談不上驗收。
很多人希望通過詳細的系統需求規格說明書來定義專案要實現的內容和業務目標，這是很有必要的，但需求規格說明書得到認可並非是通過使用者審核就可以的結果，應該想辦法讓使用者一起參與到需求規格說明書的制定過程中來，變成使用者自己推導出來的業務實施目標，未來才不容易變形。 軟體開發網
2、積極主動地與客戶進行溝通
專案中一定要有溝通策略，和高管如何匯報工作進展，取得支援？和中層如何就業務目標不斷確認，逐步清晰？和基層如何就專案應用操作模式達成一致，持續改進？都需要通過溝通反饋完成。 http://www.mscto.com
溝通的作用對於高管是讓他們清楚我們一直按照專案目標前進，每個階段工作進展是否順利，影響專案正常運做原因是什麼，需要哪些資源幫助。和高管溝通比較多的話，第乙個好處是高管經常聽匯報就知道專案進展程度，可以安排反饋檢查，看是否具備我們所說的進展，這樣一旦認可了各個階段目標後，最終要求高管簽字確認也就順理成章了。
給高管匯報技巧就是簡潔明瞭，真實客觀，有理有據分析問題，提出對策建議請其決策即可。
中層往往是專案主要的推動力量和實際執行者，也往往是對具體業務需求最主要的要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且專案驗收與否沒有中層的同意往往也是不太容易做到的。
往往通過前期業務調研只能對企業專案目標有乙個大的，巨集觀的認識，但如何細化並最終落實並非是一步到位的過程。因此在整個專案過程中，雙方專案組要不斷溝通，特別是企業中層溝通，才能逐步認識越來越深刻，最終達成一致。
和基層的溝通主要體現對終端使用者的關懷，定期主動和終端使用者溝通，消除一些怨氣，讓使用者能堅持用下去，這個時候我們往往發現很多使用者真的是非常好相處，儘管軟體還有很多值得改進的地方，但他們一旦認可我們團隊，反而會盡心盡力幫助我們推動專案的進行。
目前我們公司一般要求每個專案經理在專案進行中都要填寫詳盡的專案月報，反映專案的進度，與計畫的偏差，完成的專案內容，投入人力，目前專案存在的問題，以及預計專案下月的進度等等。將進度月報交部門負責人、專案管理中心、總經辦審閱。
軟體開發網
類似地也要制定針對客戶的月報甚至是週報，將相關的資訊反應到客戶方的負責人，及相關高層。可以先發郵件，然後還要**落實收到並口頭簡要匯報，特別是高管層，千萬不要以為發了就等於別人會去看，一定要口頭跟進匯報一次，保證客戶各方面負責人對專案進展做到心中有數。
在專案的過程中，我們也需要注意平時做人的積累，比如要做到講誠信，講原則。主要是三條：1）做不到的事情千萬別隨意承諾；2）承諾的事情一定要努力做到；3）每次做到的事情都進步一點點。按這三條做事，即使在系統的使用過程中總會有這樣或那樣的一些不方便，使用者也會慢慢接受稍微長一點的響應週期，也會用更多積極性眼光看現在的問題，也相信問題一定有人響應，也一定可以得到解決。進而使我們和客戶之間形成一種較為和諧的關係。
3、寫好備忘錄和問題跟蹤記錄
在乙個漫長專案週期中，很多任務作做了也就做了，認可了也就認可了，時間一長也就忘記了很多承諾和約定，到了驗收的時候就可能重新翻出來，這種事情很多人可能都經歷過，明明說可以先不做的內容最終驗收的時候又成了必要條件。
每次備忘錄要口頭交流認可後才列印簽字確定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行，保障專案在每次工作基礎上不斷前進，並用備忘錄約束雙方的行為。
同時我們建議在收集專案出現的各種問題時，採用問題跟蹤記錄表的形式，這樣可以一目了然地顯示出我們曾經收集到的各種問題，目前的解決情況，以及還有什麼問題沒有解決，準備什麼時候解決。這樣客戶和我們都會對目前的情況非常了解，通過不斷地解決出現的問題，來收斂可能出現的問題，當存在的問題越來越少時，也就表示我們的系統已經在接近驗收的標準了。
軟體開發網
4、驗收階段的準備工作及注意事項
做乙個詳細的驗收計畫是非常必要的，可以用來作為驗收階段的工作指導。這就需要與客戶進行詳細的溝通，再次明確驗收前需要完成的工作，盡量避免客戶方在此階段提出過多的更改需求，這是極為重要的。驗收計畫中不光要有需要繼續完成的工作，還需要有乙個相對固定的工期，使雙方都繼續朝著這個方向去努力，防止無限制的拖延。
我們很多的專案碰到的一些常見問題就是軟體開發完之後，很多客戶也不使用，如果我們去催促他們的時候，就經常推脫工作太忙，還有其它的事要做等等，或者也就是應付一下隨便提一兩個小問題。而等我們提出要驗收的時候，他們又總是覺得這也不滿意那也不滿意，總之是怕承擔相應的責任，不願意驗收。
針對這種情況我想主要還是想辦法讓客戶盡量把系統使用起來，只有在使用中才能發現問題，我們也才能解決問題，使系統能更好地執行。如果是基層的人員不願意使用，我們可以走上層路線，使客戶的高層了解專案正常執行的重要性，也使他們意識到專案驗收的重要性，意識到無限制地拖延下去會對**機會的權威、形象和公司的收益造成不好的影響，利用他們的主觀積極性克制拖沓的工作作風。如果專案經理在這方面沒有太多的辦法的時候，可以讓市場人員動用一些商業運作的手段，或者提請公司高層出面與客戶方的高層盡早溝通，明確系統執行的各項工作。
還有一種情況就是客戶無窮盡地提出一些需求，一些主要領導對系統指指點點，隨便一句話，就要進行需求變更，專案的範圍不斷擴大，導致專案試執行一直無法結束。甚至一些客戶追求系統的完美，提出了很多高難度的需求，導致我們需要投入較多的精力去解決。
這種情況，我覺得是一些**主管領導對電子政務認識上存在一定的誤區，認為這麼乙個系統就應該能夠解決所有的問題。其實資訊系統只是**管理工作的一種輔助性手段，資訊化不是一步到位工程，而是一種長期的、不斷改善的系統工程。我們應該想法讓他們結合實際情況，提出他們真正需要解決的問題，而不是依靠他們的長官意志，提出一些不切合實際的、易變的需求。要實現這一點，就需要專案經理安排人員定期到**機關進行資訊化普及培訓以及專案管理知識培訓。同時在合適的情況下，建議在該專案驗收後啟動新的專案來完成一些新的需求。
專案驗收對任何乙個專案管理者都是乙個極大的挑戰，即使已經採取本文提到的幾種手段，也不能保證我們的專案能夠順利驗收，但作為專案的承建方，我們所能做到的就是盡量做好我們所能控制的事情，另外一些很難由我們控制的事情則需要借用一些其它的力量去完成，比如請市場部運用一些商業手段來促成專案的驗收等等。本文中提出的這些建議，是希望能夠起到拋磚引玉的效果，希望各位同仁可以提出更多更好的方法來促進我們的專案如期驗收。
如何做好軟體專案的驗收工作
專案驗收是公司乃至每個專案成員都想要的結果，一旦驗收對公司來說就是，可以收驗收階段的款了，不需要再投入那麼多人力到專案當中，專案終於可以告一段落，大家都可以輕鬆一下了。專案驗收是一系列細緻工作完成到位的結果，而不是某一點的成功或某個人能力就可以促成的事情。乙個專案的驗收，一般是由一系列驗收準備工作組...
ERP 軟體專案驗收流程
引言 軟體測試是為了發現錯誤而執行程式的過程。它不僅是軟體開發階段的有機組成部分，而且在整個軟體工程 即軟體定義 設計和開發過程 中佔據相當大的比重。軟體測試是軟體質量保證的關鍵環節，直接影響著軟體的質量評估。軟體測試不僅要講究策略，更要講究時效性。驗收測試作為軟體測試過程的最後乙個環節，對軟體質量...
如何做好IT軟體實施專案
內容簡介 這個世界上寫給專案經理的書很多，寫給it專案經理的書也不少，但寫給從事管理軟體實施的專案管理書籍並不多。而筆者在從事專案經理工作中感到乙個很苦惱的問題是，很多書其實非常經典，但都有乙個缺點 理論正確，實戰指導作用不足。不是親身親歷的人是很難領悟到那些理論的精髓，而每個剛剛入行又立志成為乙個...