頭痛的產(chǎn)品驗(yàn)收到底該怎么做？！

這是Kevin的第 882 篇原創(chuàng)，

持續(xù)日更，做產(chǎn)品經(jīng)理的創(chuàng)業(yè)斜杠青年。

近期帶著團(tuán)隊(duì)再推動PMTalk產(chǎn)品的迭代和新版本上線。

圍繞著自家的小程序、和PC、還有客戶端app3個(gè)形態(tài)下不斷做調(diào)試和優(yōu)化。如果你關(guān)注使用過PMTALk，就應(yīng)該可以感受到我們在近年也在發(fā)生了較大的變化。

對于小團(tuán)隊(duì)或創(chuàng)業(yè)項(xiàng)目的產(chǎn)品，產(chǎn)品驗(yàn)收即可以減少資源和時(shí)間的浪費(fèi)，還能快速投入到下個(gè)環(huán)節(jié)工作。

我如何在團(tuán)隊(duì)里做產(chǎn)品驗(yàn)收的？分享下我的經(jīng)驗(yàn)。

1.搞清楚驗(yàn)收和測試的區(qū)別

這個(gè)部分實(shí)際上就把很多小團(tuán)隊(duì)搞暈了。

由于沒有測試人員、或?qū)I(yè)的驗(yàn)收流程，導(dǎo)致產(chǎn)品的驗(yàn)收和測試全部混在一起。每次都是開發(fā)結(jié)束了后才進(jìn)行測手驗(yàn)收。

其實(shí)驗(yàn)收和測試是2個(gè)完全不同的內(nèi)容。

1.測試的工作

軟件測試是使用人工或自動的手段來運(yùn)行或測定某個(gè)軟件系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。 

測試是依照產(chǎn)品經(jīng)理的需求文檔或測試用例進(jìn)行還原，即使需求文檔是錯(cuò)誤的，包括沒有描述到的邏輯問題，測試的工作要么是跳過不測試，要么是根據(jù)錯(cuò)誤的需求來描述。

需求開始邁入U(xiǎn)I設(shè)計(jì)前，需求評審中會拉上測試，搞清楚了需求的背景、目的以及需求大體范圍后，測試會基于需求文檔輸出測試用例。產(chǎn)品經(jīng)理則要求通讀測試用例進(jìn)行把控用例的描述是否準(zhǔn)確，同時(shí)有無遺漏需求。

▲  某測試用例 

比如上圖是測試用例的描述，針對功能下的操作前置條件、后置條件、基本操作流程進(jìn)行描述。

一個(gè)功能需求會涉及到上百條測試用例，需要測試人員提前撰寫和產(chǎn)品經(jīng)理評估。

2.產(chǎn)品驗(yàn)收

產(chǎn)品驗(yàn)收和測試的目的完全不同，但產(chǎn)品驗(yàn)收產(chǎn)生的過程會和測試相重復(fù)，但產(chǎn)品驗(yàn)收的目的只有一個(gè)

當(dāng)前產(chǎn)品版本能不能上線、能不能正式發(fā)布。在小公司里沒有審核流程的說明，產(chǎn)品經(jīng)理和業(yè)務(wù)負(fù)責(zé)人、或者老板同意就可以發(fā)版本。

產(chǎn)品驗(yàn)收階段會發(fā)現(xiàn)很多問題，比如功能的設(shè)計(jì)缺陷、邏輯錯(cuò)誤，甚至是最致命的功能無效、無法解決需求問題。

我們PMTalk會整理出驗(yàn)收表，如下包含了序號、問題、截圖、優(yōu)化描述、解決狀態(tài)。

解決狀態(tài)由開發(fā)進(jìn)行標(biāo)記和同步。其他部分則是產(chǎn)品經(jīng)理填寫

▲  驗(yàn)收文檔 

以序號來定位優(yōu)化問題，屬于BUG的就歸納為當(dāng)前版本，屬于優(yōu)化的就歸屬到下一個(gè)版本。

▲  BUG池 

在BUG文檔里下面字段如下

解決狀態(tài)：

當(dāng)前BUG是否解決，是關(guān)鍵再次驗(yàn)收的標(biāo)準(zhǔn)。

優(yōu)先級：

根據(jù)緊急和重要程度來建設(shè)4個(gè)優(yōu)先級，分別是P1、P2、P3、P4

模塊：

BUG的功能定位，在哪一個(gè)位置上

平臺：

如果涉及到多個(gè)產(chǎn)品端和系統(tǒng)的介入，則需要定位出BUG在那個(gè)平臺或系統(tǒng)上。如有調(diào)用科大訊飛語音能力，由于沒有充值賬戶導(dǎo)致客戶端的語音識別能力受阻，就是第三方平臺能力欠費(fèi)導(dǎo)致。

問題描述：

主要描述邏輯問題、UI問題、文案問題，給出正確的對應(yīng)描述。如果涉及到復(fù)雜邏輯和復(fù)雜效果，則需要當(dāng)面評審溝通。

提出人：

標(biāo)記出問題的提出人，可能是業(yè)務(wù)、也可能是運(yùn)營、還有可能是產(chǎn)品經(jīng)理。總之定位出問題的直接提出者，注意不是責(zé)任人。因?yàn)楹芏鄷r(shí)候責(zé)任人不是提出 

問題類型：

問題的類型根據(jù)驗(yàn)收的環(huán)節(jié)不同，有非常大的區(qū)別。比如UI還原不正確的，屬于Ui問題、與需求描述不一致的屬于功能缺陷、常見的問題比如點(diǎn)擊沒有反應(yīng)、跳轉(zhuǎn)錯(cuò)誤則屬于BUG。

但很多時(shí)候如果團(tuán)隊(duì)比較小，都可以統(tǒng)稱為BUG，唯獨(dú)需要優(yōu)化的單獨(dú)羅列出來即可。

3.上線驗(yàn)收最難的是進(jìn)度與狀態(tài)更新

幾乎每個(gè)公司都會出現(xiàn)這樣的問題

就是產(chǎn)品上線前驗(yàn)收發(fā)現(xiàn)的問題，更新進(jìn)度不及時(shí)就會導(dǎo)致重復(fù)測試以及資源浪費(fèi)。

所以非常推薦各位產(chǎn)品經(jīng)理使用禪道、TB這樣的協(xié)同項(xiàng)目管理工具。及時(shí)更新BUG的狀態(tài)和數(shù)量，盯緊對應(yīng)問題的開發(fā)、UI執(zhí)行人，注意不是負(fù)責(zé)人是第一執(zhí)行人。

當(dāng)然項(xiàng)目和系統(tǒng)還是要依靠人力管理，好的研發(fā)管理制度可以明顯減少BUG解決時(shí)間，而扮演這個(gè)角色的人幾乎都是產(chǎn)品經(jīng)理為主。

如果全部丟給項(xiàng)目經(jīng)理或研發(fā)負(fù)責(zé)人來管，其實(shí)也是不是一個(gè)合格的產(chǎn)品經(jīng)理。

今天的分享就在這。

今日Bonus：加我好友 pmtalk001，觀看我的朋友圈，每天5條，帶你了解快速提升產(chǎn)品運(yùn)營進(jìn)階。

??點(diǎn)擊閱讀原文，加入打卡訓(xùn)練營，每天體驗(yàn)1款A(yù)PP

每天體驗(yàn)1款app知識星球

加入后365天，每天體驗(yàn)一款A(yù)PP。提升產(chǎn)品設(shè)計(jì)能力，同時(shí)有1500份體驗(yàn)報(bào)告幫助你找到競品。

平均1天1塊錢，掃碼購買即可加入

連續(xù)體驗(yàn)90款應(yīng)用，通過后原路退回