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