項目驗收就好像你自己打的那套卷子交給老師評分一樣，自己檢查一點錯都沒有，或者知道哪裡有一些錯，但是結果還是需要交由老師評判。在還沒有到交卷時間時，我們需要將自己的卷子修改到自己認為到最好的狀態下進行交付。
一、為什麼要做項目驗收呢？
每個人做卷子時都希望能夠拿到高分，但是怎麼拿到高分呢？
其實可以很簡單，那就是在做卷子的時候對於我們的卷子檢查再三。
而項目驗收就是我們做的檢查，所以項目驗收是針對當前項目交付前做的最終檢查，如果合格就是可以交付的，如果不合格那就沒辦法交付。
二、項目驗收的流程是什麼？
其實項目驗收也是按照一定流程進行的，一般的項目在驗收時都會經過程序員自測、冒煙測試、測試完成、UI驗證、產品驗收這幾個普遍的流程之後才能夠確認驗收，進行項目的交付。
1. 程序員自測
程序員自測其實就是：程序員去測試自己所寫模塊，是否與產品對該模塊所提的需求完全匹配。
程序員進行自測，是對自己所寫模塊的進一步檢查。這樣可以使對該模塊的邏輯更加明確，同時加深對於該模塊的記憶，並且可以最大程度確保每個模塊程序書寫的正確性。
2. 冒煙測試
冒煙測試是：對已經完成的全部模塊進行流程性的檢測，確認目前完成的系統是否可以確保按照產品的全部邏輯跑完基本流程。
冒煙測試主要是增加目前對產品流程的熟悉度，讓測試人員可以進行詳細的測試的準備工作，也是該系統是否可以進入詳細測試的一個重要依據。
同時，也會驗證出在此流程下是否有一些設計缺陷需要產品進行彌補。
3. 測試完成
測試完成是對於整體的測試環節來說的，他是測試人員對於系統整體進行測試的一個結論，這個結論是已確認目前系統的功能、性能在測試環節已經完全符合產品提出的需求。
進行測試的主要原因是：對當前系統的全部流程的一個迴歸，和對該系統是否存在缺陷性問題。
測試完成的確認是因為確認之後就該系統就可以進行下一項目的交付，來進行更深一步的優化。
4. UI 驗證
UI 驗證是由UI設計師來驗證當前的系統UI是否能夠達到預期的效果。
UI驗證是當前頁面UI還原度的一個重要證據。
UI驗證是檢測當前頁面能否做到UI圖級別的視覺效果，以及開發人員是否按照UI設計師的界面需求進行實現的一個重要準則。
5. 產品驗收
產品驗收是產品經理在項目交付前，進行最後需求與程序開發是否統一的過程。
產品經理進行驗收是對整體系統流程的一個把關，也是對當前系統一次總的檢查，在驗收過程中，需要綜合UI驗證，以及測試時的一個結果，來確認在產品經理在驗收後是否可以交付該系統。
三、項目驗收中遇到問題了呢？
項目驗收本來就是一個需要承擔責任和成長的階段，當項目驗收成功後，你會覺得整個世界都是晴朗的。
但是你在驗收過程中，一旦發現出現問題，那有可能就會有原地爆炸的風險吧。
所以，當遇到了問題我們該怎麼解決呢？
1. 已構建的程序與之前的規則不相符
當我們開發的小夥伴已經完成了開發，但是你發現與產品確認需求時的規則並不一致，這時也許會覺得天嚕啦，我要怎麼辦？
產品的規則其實確實是開發小夥伴需要遵從的準則，不過還是會經常出現，開發完成的規則與確認需求時的規則不相符的情況，這是什麼原因呢？
有一部分原因就是：當時沒有溝通清楚出現了這個原因；
還有一部分原因產品的規則之前不完善，所以開發直接按照自己覺得完善並且合理的規則進行書寫了。
事出有因，但也不是沒有改正的方法。
1）沒有溝通清楚，且目前做的系統比之前產品規劃的要完善，那就不需要修改，直接把當前規則補充到細則上。
2）沒有溝通清楚，但是目前系統做的並不盡人意，根據交付時間酌情修改——
- 如果時間太緊急，如果按照原有規則可能無法按期交付，那就酌情進行規則細則修改，在不影響工期的情況下進行修改；
- 如果時間充裕，那就跟開發確認清楚該規則，明確到最小的細則，並且及時跟進，確保該規則是在正常情況下修改的。
由於產品的規則沒有細化並明確，導致開發按照自己意願進行功能設計，結果出現部分與產品之前不相符的。
如果時間允許，可以在經過溝通後進行相應規則調整。當然不能僅僅調整代碼，規則也可以進行相應調整，在不影響產品原有設計規則的基礎上與當期的代碼進行適配，將時間成本降至最低。
4）由於產品的規則沒有細化明確，開發按照自己意願進行功能設計與之前的規則沒有太大偏差。
這個時候你應該感謝開發，與你所想的沒有南轅北轍。需要的就是在此基礎上進行更加明確的規則細化就可以了。
2. UI 還原度與驗收時間有衝突
當我們 UI 同學辛苦設計的頁面，並沒有被前端小夥伴整體還原出來，估計 UI 同學會被憋出內傷呢。這個情況下又該怎麼解呢？
這個根據現實情況來就好，告訴 UI 同學，你這個項目的 UI 還原度是多少，直接讓 UI 同學去分析是否通過 UI 驗收就好。但是，如果時間節點有衝突時，可以告知UI 同學適當降低還原度。
四、驗收後出現問題了呢？
這個項目被驗收了，但是沒驗收多久，突然就告訴你我們覺得這裡不對，我們覺得那裡需要改。這個跟我們一開始說的不一致，突然發現有 bug，好像覺得自己要宕機了呢。
1. 需求方想要新增需求
需求方在驗收之前覺得很符合自己的定位，但是在驗收之後的使用過程中突然覺得，這裡如果在新增一個功能就更完美了。於是就說，我覺得這個跟我之前想的不太一樣，需要加上這個功能就好了。
在項目已經被驗收成功的情況下，所有的新增功能都是屬於新的需求，既然是新的需求，那就需要拿出簽字的需求方案。
只有提出了需求方案並且經過了簽字才可以進行規劃，同時規劃還是需要將這個需求規劃到下一期中，因為目前已經完成驗收。
其實簡單來說，就是：所有在驗收後，提出的需求都是需要提交方案，並且規劃到下一期的。
2. 需求方發現 bug
在系統的使用過程中突然發現，某個地方有 bug 了。
有 bug了就去修改就好了，這就是我們開發團隊的維護情況了，有 bug 其實不可怕，畢竟我們在交付的時候並沒有出現問題。
其實在系統的使用過程中出現問題是不可避免的，所以在出現問題後及時修正才是最好的解決辦法。
五、怎麼確認驗收結果呢？
驗收結果是最激動人心的動心，但是我們需要怎麼去確認這個結果就是我們想要的結果呢？
其實驗收結果可以從外包和自家產品兩個方向。
1）外包驗收
甲方爸爸跟你說我覺得這個產品很好的，那這次驗收基本成功了；
如果甲方爸爸跟你說，這裡也許還能再優化一下，那就需要記下優化的點，繼續進行優化就好了，那這次驗收基本就不能算成功了。
2）自家產品驗收
自家產品其實主要就是滿足當前需求方的需求，經過檢測沒有出現 bug，那之後再進行輸出性迭代，就基本可以了。
所以，小夥伴們，你們現在的項目驗收了沒啊，我現在的項目差不多快驗收了呢！
PMP備考學習資料需要的同學私信找我，內含pmp備考資料 EPC工程管理資料 各種模板表格與5GB質量管理資料等等！
閱讀更多 一起學PMP項目管理 的文章
