本篇文章將探討產(chǎn)品經(jīng)理驗收時存在的幾個問題：是否需要驗收、為何不驗收、驗收與測試的不同及誤區(qū)等，幫助大家了解驗收的內(nèi)容，希望本篇文章能對你有所幫助。

最近，在一個產(chǎn)品溝通群里，產(chǎn)品經(jīng)理們又炸開了鍋，起因是其中一名產(chǎn)品經(jīng)理提到自己公司的產(chǎn)品上線之后，功能與業(yè)務不符，測試將這個“鍋”甩到產(chǎn)品身上，認為產(chǎn)品沒有做好驗收，而產(chǎn)品認為這本身就是測試的工作。

于是，產(chǎn)品經(jīng)理們開始在群里瘋狂吐槽各自公司的測試人員，我看到了“一致對外”，但卻沒看到任何人在反省產(chǎn)品經(jīng)理到底應該如何驗收才能避免這樣的事情再次發(fā)生。

一、產(chǎn)品經(jīng)理到底需不需要驗收

這個問題的答案是肯定的，產(chǎn)品經(jīng)理一定要做驗收，至于其必要性，我們看一看產(chǎn)品經(jīng)理不做驗收會產(chǎn)生什么后果就知道了。

1. 產(chǎn)品與設計不符

按產(chǎn)品與設計的偏離情況，可分為3種：

1）不符

這種情況指的是產(chǎn)品與設計有偏離，但無傷大雅，甚至可以不按原設計調(diào)整。

比如一個原本應該用紅色級別的 Toast 提示被開發(fā)成黃色級別，由于紅色和黃色在系統(tǒng)中均有表示警告的含義，所以這個偏離也不是不可以接受的。

2）一般不符

這種情況指的是產(chǎn)品與設計有較大偏離，可能已經(jīng)影響到產(chǎn)品的使用。

比如一個原本通過彈窗提示的內(nèi)容被開發(fā)成出現(xiàn)一定時間后自動隱藏的 Toast 提示，這個提示文案是在持續(xù)等待一段較長時間后出現(xiàn)（比如上傳大文件，或系統(tǒng)處理較多數(shù)據(jù)的場景下）。

期間用戶的視線可能離開產(chǎn)品界面，彈窗提示可以在用戶回來后看到執(zhí)行結果，而自動隱藏的 Toast 提示用戶可能會錯過。

3）嚴重不符

這種情況指的是產(chǎn)品與設計嚴重偏離，已經(jīng)嚴重影響到產(chǎn)品的使用。

比如設計約束一個手機號只能注冊一個賬號，注冊時，已注冊的手機號不能注冊成功，但開發(fā)的時候漏掉這一步，注冊時可以使用同一個手機號注冊多個賬號，導致登錄時系統(tǒng)無法識別具體要登錄哪個賬號而出錯。

2. 產(chǎn)品與業(yè)務不符

這種情況未必是因為產(chǎn)品與設計不符造成的，而是可能產(chǎn)品設計本身就與業(yè)務不符，產(chǎn)品的存在是為了服務業(yè)務。

所以一旦產(chǎn)品出現(xiàn)與業(yè)務不符的問題，則每一個問題都可能是致命的。

3. 需求變更

產(chǎn)品設計與業(yè)務不符需要通過調(diào)整錯誤的需求實現(xiàn)來滿足業(yè)務，這必然會帶來需求的變更。

4. 返工

發(fā)現(xiàn)錯誤的設計或?qū)崿F(xiàn)，需要推翻原來的工作成果，重新設計和開發(fā)。

5. 進度落后

無論需求變更還是返工，都會使原本規(guī)劃好的進度落后。

6. 扯皮推諉

出現(xiàn)問題，大家都覺得不是自己的責任，開始互相甩鍋。

二、產(chǎn)品經(jīng)理為什么不喜歡做驗收

既然產(chǎn)品經(jīng)理驗收環(huán)節(jié)這么重要，為什么產(chǎn)品經(jīng)理們卻不喜歡做驗收呢？

1. 驗收工作繁瑣且枯燥

產(chǎn)品設計的過程是一個探索和創(chuàng)造的過程，對產(chǎn)品經(jīng)理而言是一個充滿樂趣的過程，多數(shù)產(chǎn)品經(jīng)理在完成產(chǎn)品設計交付給研發(fā)的時候，都會有一種“這是目前我能做出來的最棒的設計”、“不可能有比這更好的設計方案了”的想法。

而驗收就不一樣了，雖然交付的是設計，驗收的是產(chǎn)品，但產(chǎn)品經(jīng)理會認為自己的設計很清晰，不應該有人會誤解，甚至會有一種“我的設計這么棒，竟然讓我給自己的設計挑毛病”的想法。

2. 理所當然地認為這是測試的工作

有的產(chǎn)品經(jīng)理會認為，設計交付給開發(fā)之后就沒有自己的事了，最多在開發(fā)過程中幫開發(fā)厘清一些有疑問的地方，后續(xù)其他工作則與自己無關。

3. 規(guī)劃的版本時間過于緊湊

一般版本的研發(fā)時間由研發(fā)部門來確定，而研發(fā)部門在確定版本時間的時候，只會將測試的時間考慮進去，而不會考慮產(chǎn)品驗收的時間，產(chǎn)品經(jīng)理驗收時間不夠，驗收沒有效果，久而久之就沒有了驗收的習慣，測試通過就上線了。

三、產(chǎn)品經(jīng)理驗收和測試的區(qū)別

產(chǎn)品上線后出現(xiàn)問題，首當其沖的就是測試，接著就是產(chǎn)品經(jīng)理，最后就容易演變成兩者的相互“甩鍋”。

究其原因是因為公司或部門對二者在產(chǎn)品驗收和測試環(huán)節(jié)的職責范圍沒有明確劃分，最終只能由管理者來確定應該承擔責任的人，一般如果管理者是研發(fā)負責人，會將責任歸咎于產(chǎn)品經(jīng)理沒有做好驗收，而作為產(chǎn)品負責人的管理者則會認為是測試人員的測試工作做得不到位。

因此，產(chǎn)品研發(fā)兩個部門經(jīng)?！按蚣堋?，這也是其中的原因之一。

關于產(chǎn)品經(jīng)理驗收和測試人員測試的區(qū)別，我大概列了以下幾點，各位可以根據(jù)自己項目的實際情況參考一下。

看了以上對比之后，你可能會產(chǎn)生一種想法，覺得產(chǎn)品經(jīng)理的驗收好像很隨性，沒有明確的標準，沒有量化的工具，甚至沒有明確的目標。

的確，明確產(chǎn)品經(jīng)理驗收這個環(huán)節(jié)在業(yè)內(nèi)并沒有形成相對統(tǒng)一的標準和方法，更多靠的是產(chǎn)品經(jīng)理個人的經(jīng)驗和在驗收時的敏銳程度。

因此每個產(chǎn)品經(jīng)理也都形成了一套屬于自己的驗收經(jīng)驗，一名優(yōu)秀的產(chǎn)品經(jīng)理經(jīng)常能夠發(fā)現(xiàn)很多測試都難以發(fā)現(xiàn)的問題。

四、產(chǎn)品經(jīng)理驗收，到底是驗什么？收什么

下面根據(jù)本人以往的一些項目經(jīng)驗，簡單總結一下，產(chǎn)品經(jīng)理驗收，到底是驗什么？收什么？

1. 驗什么

1）驗業(yè)務

產(chǎn)品經(jīng)理是離業(yè)務和需求最近的人，也是接收業(yè)務信息和需求信息“失真率”最小的人，驗收的時候，優(yōu)先要考慮的是產(chǎn)品到底能不能滿足業(yè)務，或者對業(yè)務目標有沒有幫助，而不能一味考慮產(chǎn)品是否與設計一致。

所以產(chǎn)品經(jīng)理驗收產(chǎn)品的時候，需要代入業(yè)務目標。

一個功能，如果能夠滿足業(yè)務目標，但是與設計不一致，在不會影響其他功能或交互的情況下，也是可以被接受的。

因為實現(xiàn)同一個業(yè)務目標有時候不一定只有一種設計。

2）驗設計

“不能一味考慮產(chǎn)品是否與設計一致”不代表可以不考慮。

上文說到，產(chǎn)品經(jīng)理驗收的時候不像測試人員一樣有測試用例，所以產(chǎn)品設計就是最好的驗收標準。

按照設計來驗收是最快的驗收方式，只是在碰到與設計不一致的功能實現(xiàn)時，優(yōu)先要判斷的是實現(xiàn)與業(yè)務是否一致，而不是不管不顧地推翻已經(jīng)做完的功能，要求重新按照設計來做。

3）驗場景

場景指的是業(yè)務場景，這個環(huán)節(jié)也是產(chǎn)品經(jīng)理最容易發(fā)現(xiàn)測試人員發(fā)現(xiàn)不了的問題的環(huán)節(jié)。

測試人員對業(yè)務的了解基本都是通過產(chǎn)品經(jīng)理的傳遞，測試時，針對的業(yè)務場景比較單一，產(chǎn)品經(jīng)理因為對業(yè)務的了解更深刻。

因此在測試時，可以挖掘到更多的業(yè)務場景，也更容易發(fā)現(xiàn)不同業(yè)務場景下的問題。

2. 收什么

1）版本基準

當前版本已經(jīng)驗收通過，可以封版發(fā)布，所謂的版本基準就是最終發(fā)布的版本內(nèi)容，有些人可能會說，那不就是版本規(guī)劃嗎？其實不然。

版本規(guī)劃指的是計劃要實現(xiàn)的功能，版本基準指的是最終實現(xiàn)的功能，在特定情況下，版本基準等同于版本規(guī)劃，但更多的時候，版本基準與版本規(guī)劃總是會有一些不同。

因此需要將當前的版本基準記錄下來，否則如果以后按照版本規(guī)劃回溯當前版本的時候，會發(fā)現(xiàn)實際實現(xiàn)的版本與規(guī)劃的版本并不完全一致。

2）問題清單

“我們需要盡量發(fā)現(xiàn)問題，嘗試解決一些問題，允許存在一些問題?！边@是驗收版本時的一個核心思想，你不可能解決所有問題，因為問題會不斷出現(xiàn)，所有嘗試為了解決所有問題的行為最終都可能會導致版本延期。

所以要有選擇性地解決一些必須在上線前解決的問題，并允許一些無傷大雅的問題存在，當然，這些問題并不是就此放任，而是需要記錄下來，形成問題清單，在后續(xù)的版本中逐步解決。

3）迭代計劃

迭代計劃除了來自業(yè)務的發(fā)展和變化，同時也來自驗收，驗收過程中記錄的問題以及發(fā)現(xiàn)的新的需求，將形成新的迭代計劃，并入到新版本的規(guī)劃中。

五、產(chǎn)品經(jīng)理驗收容易陷入什么誤區(qū)

產(chǎn)品經(jīng)理驗收環(huán)節(jié)容易陷入這個誤區(qū)，這些誤區(qū)容易導致驗收不充分。

1. 想當然

產(chǎn)品經(jīng)理在驗收某些功能的時候，容易陷入一種誤區(qū)，覺得自己的設計邏輯是很簡單、很符合直覺，或者這是一個常識性的約束，不會有人理解錯誤，因此就不加以驗收。

比如大家都會認為在使用手機號注冊賬號的時候，如果手機號已注冊，是無法注冊成功的，產(chǎn)品經(jīng)理認為這是一個常識，哪怕自己沒有在文檔中寫出來，開發(fā)應該也會這樣實現(xiàn)，驗收的時候也無需針對此項約束進行過驗收，結果產(chǎn)品出來的時候，同一個手機號可以重復注冊，導致登錄的時候系統(tǒng)出錯。

要避免這個誤區(qū)，首先在設計的時候，即使是常識性的約束條件也應該清楚寫進文檔中，并在開發(fā)完成后逐項驗收。

同時，要正確理解研發(fā)人員的工作方式和工作思維，很多時候是幾個研發(fā)同時開發(fā)一個業(yè)務功能，每個人只負責一個子模塊，從他們的角度，很難在腦海中拼湊出完整業(yè)務的形態(tài)。

所以只能根據(jù)設計和文檔進行開發(fā)，設計和文檔中沒有的內(nèi)容，他們是不會主動添加進去的。

2. 驗收場景不充分

這種就是驗收前沒有什么計劃性，看到哪驗到哪，想到什么驗什么，這種“隨心”的驗收方式很容易忽略掉一些場景。

雖然產(chǎn)品經(jīng)理驗收不像測試那樣有嚴格的測試用例，但要避免驗收場景不充分的誤區(qū)，最好在驗收前先有一份“場景驗收計劃表”。

計劃表主要需要包含驗收的場景、準備的數(shù)據(jù)、預期驗收結果、實際驗收結果。如果可以，提前準備好數(shù)據(jù)值，這樣驗收的效率更高，準備數(shù)據(jù)值的時候，注意需要準備多個，主要需要錯誤的數(shù)據(jù)值、正確的數(shù)據(jù)值以及邊界值。

下圖是我針對注冊登錄環(huán)節(jié)驗收整理的部分場景的驗收計劃表，僅供參考：

3. “羅生門”

開發(fā)說修復完了，測試說測試通過了，結果產(chǎn)品一看，全是 bug。

這種主要是到了產(chǎn)品后期準備上線的時候經(jīng)常遇到的問題，產(chǎn)品發(fā)現(xiàn)一個問題，開發(fā)就改一個地方，測試就測一個地方，導致其他有問題的地方?jīng)]有被發(fā)現(xiàn)。

這種情況一般是需要多方去規(guī)避，比如公司應該有明確的測試流程和管理制度，研發(fā)規(guī)劃時間的時候需要冗余足夠的時間，產(chǎn)品經(jīng)理應該充分闡述清楚業(yè)務場景等。

以上便是本文的全部內(nèi)容，感謝閱讀。