浅谈软件项目验收(转)
談到驗收,相信很多實施同事都是一個頭兩個大,覺得項目最麻煩的工作莫過于此,盡量模糊化,規避正式的驗收。
客戶場景A:
我們要推廣的是8個公司,不是8個項目,你們都還沒做完,怎么就能驗收了呢?
客戶場景B:
我們試點上線以后又提出了一些優化需求,你們給我們處理完了,再給你們試點驗收吧?
客戶場景C:
這個驗收報告不能只是我簽字啊,還有我們試點項目的用戶和集團相關業務部門的老總都要簽字的,讓他們也看看評估下吧。
客戶場景D:
工作流你們前期調研了嗎,文檔都沒有啊,流程都沒有穩定固化下來,怎么就能驗收了呢?
客戶場景E:
沒錯,你們的工作是做完了,可是我們現在通過系統什么都還看不到,不好跟老板交代啊,怎么給你們驗收呢?
大家在看到上面幾個場景的時候是不是有種似曾相識的感覺?作為實施人員,我們是否需要好好的思考一下,為什么客戶驗收難?找到問題的原因后,才能在后續的工作中有效的改進規避,不再陷入項目驗收的泥沼。
1、項目目標及范圍不清晰:
項目一啟動就急忙開展了業務調研工作,對于項目的目標與范圍未能與客戶做清晰界定。實施過程中也沒有進行確認,導致后期雙方理解差異,產生爭議。這也是很多同事不關注不重視實施任務書的結果,直接模板套用,前期風險評估不足,任務書也就失去了其意義。
2、驗收標準明確時間過晚,對于客戶需求未建立有效評估處理機制:
有些項目到了試點上線之后甚至正式驗收之前,才與客戶明確驗收標準。殊不知驗收標準與客戶確認的時間越晚,對自身越加不利。很多工作都做完了,客戶的想法肯定是你要把我的所有需求和問題都解決了,才能給你驗收。上線之后冒出來的應用優化需求就作為了驗收標準談判的籌碼,尤其是在前期沒有跟客戶明確建立問題評估處理機制的前提下,大部分情況下,我們都只能被動接受客戶的要求。
3、驗收責任不明確:
有了驗收標準,可是找誰驗收不明確,要么就是找客戶項目經理,要么和項目相關的就全是責任人。前面在驗收標準里面只界定了驗收的范圍及方式方法,但對于驗收責任人沒有清晰界定,就容易出現正式驗收時相互推諉扯皮的情況。在藍圖方案階段,與客戶明確驗收標準時必須明確各類驗收工作的責任人,尤其是二次開發需求驗收,一定是本著誰提出誰驗收的原則。責權對等,一定程度上也可以規避減少部分優化需求。
4、項目成果文檔不齊備:
一個項目做下來,文檔沒幾份,很多工作都是通過口頭確認,到了驗收的時候口說無憑,驗收工作的推進自然也就不靠譜了。其實讓客戶養成實施過程工作文檔確認簽署的習慣,你的正式驗收也就成功了一大半,因為很多工作都已經階段性確認驗收過了,到最后的正式驗收只是一個水到渠成的工作。
5、客戶未看到應用價值,不滿意:
最關鍵的一點,售前階段是給客戶畫餅、提升期望值的階段。可是如果到了實施階段,如果客戶發現前期傳遞的價值什么都沒有兌現的話,肯定心里是不爽的,還會給你驗收嗎?當然,這里要說的不是要實施人員完全去兌現售前階段傳遞的價值藍圖。一方面信息化系統的成功實施,一定不是實施方單方面可以實現的,一定是IT+管理的結合,系統成功落地,客戶自身也是需要管理配套的。在這一點上,我們要做的就是勇于向客戶提出管理改善建議及應用落地保障要求。另一方面在實施階段我們解決的核心業務問題,展現核心應用價值,向客戶灌輸隨著系統深入應用及管理提升,價值分階段兌現的觀點,也可以給后續服務的應用提升埋下伏筆。在這一點上,我們要關注的是系統的應用價值展現與輸出,不能光有數據錄入,沒有輸出,那么客戶就會把系統定位成一個基礎數據錄入應用系統,而非一個管理平臺。
一家之言,歡迎大家拍磚,也希望實施同事對于驗收問題能有更加深入的思考與認識,并有效改進過程方法,以促進各自項目驗收順利推進。
總結
以上是生活随笔為你收集整理的浅谈软件项目验收(转)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 软件项目验收测试报告-软件项目验收流程
- 下一篇: 项目管理常用文档表格模板一