頭痛的產品驗收到底該怎麼作？

近期帶着團隊再推進PMTalk產品的迭代和新版本上線。

圍繞着自家的小程序、和PC、還有客戶端app3個形態下不斷作調試和優化。若是你關注使用過PMTALk，就應該能夠感覺到咱們在近年也在發生了較大的變化。

對於小團隊或創業項目的產品，產品驗收便可以減小資源和時間的浪費，還能快速投入到下個環節工做。

我如何在團隊裏作產品驗收的？分享下個人經驗。

1.搞清楚驗收和測試的區別

這個部分實際上就把不少小團隊搞暈了。

因爲沒有測試人員、或專業的驗收流程，致使產品的驗收和測試所有混在一塊兒。每次都是開發結束了後才進行測手驗收。

其實驗收和測試是2個徹底不一樣的內容。

1.測試的工做

軟件測試是使用人工或自動的手段來運行或測定某個軟件系統的過程，其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異。

測試是依照產品經理的需求文檔或測試用例進行還原，即便需求文檔是錯誤的，包括沒有描述到的邏輯問題，測試的工做要麼是跳過不測試，要麼是根據錯誤的需求來描述。

需求開始邁入UI設計前，需求評審中會拉上測試，搞清楚了需求的背景、目的以及需求大致範圍後，測試會基於需求文檔輸出測試用例。產品經理則要求通讀測試用例進行把控用例的描述是否準確，同時有無遺漏需求。

▲某測試用例

好比上圖是測試用例的描述，針對功能下的操做前置條件、後置條件、基本操做流程進行描述。

一個功能需求會涉及到上百條測試用例，須要測試人員提早撰寫和產品經理評估。

2.產品驗收

產品驗收和測試的目的徹底不一樣，但產品驗收產生的過程會和測試相重複，但產品驗收的目的只有一個

當前產品版本能不能上線、能不能正式發佈。在小公司裏沒有審覈流程的說明，產品經理和業務負責人、或者老闆贊成就能夠發版本。

產品驗收階段會發現不少問題，好比功能的設計缺陷、邏輯錯誤，甚至是最致命的功能無效、沒法解決需求問題。

咱們PMTalk會整理出驗收表，以下包含了序號、問題、截圖、優化描述、解決狀態。

解決狀態由開發進行標記和同步。其餘部分則是產品經理填寫

▲驗收文檔

以序號來定位優化問題，屬於BUG的就概括爲當前版本，屬於優化的就歸屬到下一個版本。

▲BUG池

在BUG文檔裏下面字段以下

解決狀態：

當前BUG是否解決，是關鍵再次驗收的標準。

優先級：

根據緊急和重要程度來建設4個優先級，分別是P一、P二、P三、P4

模塊：

BUG的功能定位，在哪個位置上

平臺：

若是涉及到多個產品端和系統的介入，則須要定位出BUG在那個平臺或系統上。若有調用科大訊飛語音能力，因爲沒有充值帳戶致使客戶端的語音識別能力受阻，就是第三方平臺能力欠費致使。

問題描述：

主要描述邏輯問題、UI問題、文案問題，給出正確的對應描述。若是涉及到複雜邏輯和複雜效果，則須要當面評審溝通。

提出人：

標記出問題的提出人，多是業務、也多是運營、還有多是產品經理。總之定位出問題的直接提出者，注意不是責任人。由於不少時候責任人不是提出

問題類型：

問題的類型根據驗收的環節不一樣，有很是大的區別。好比UI還原不正確的，屬於Ui問題、與需求描述不一致的屬於功能缺陷、常見的問題好比點擊沒有反應、跳轉錯誤則屬於BUG。

但不少時候若是團隊比較小，均可以統稱爲BUG，惟獨須要優化的單獨羅列出來便可。

3.上線驗收最難的是進度與狀態更新

幾乎每一個公司都會出現這樣的問題

就是產品上線前驗收發現的問題，更新進度不及時就會致使重複測試以及資源浪費。

因此很是推薦各位產品經理使用禪道、TB這樣的協同項目管理工具。及時更新BUG的狀態和數量，盯緊對應問題的開發、UI執行人，注意不是負責人是第一執行人。

固然項目和系統仍是要依靠人力管理，好的研發管理制度能夠明顯減小BUG解決時間，而扮演這個角色的人幾乎都是產品經理爲主。

若是所有丟給項目經理或研發負責人來管，其實也是否是一個合格的產品經理。

今天的分享就在這。