起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識5個問題，搞清楚產品經理驗收，到底是驗什么？收什么？
本篇文章將探討產品經理驗收時存在的幾個問題：是否需要驗收、為何不驗收、驗收與測試的不同及誤區等，幫助大家了解驗收的內容，希望本篇文章能對你有所幫助。
最近，在一個產品溝通群里，產品經理們又炸開了鍋，起因是其中一名產品經理提到自己公司的產品上線之后，功能與業務不符，測試將這個“鍋”甩到產品身上，認為產品沒有做好驗收，而產品認為這本身就是測試的工作。
于是，產品經理們開始在群里瘋狂吐槽各自公司的測試人員，我看到了“一致對外”，但卻沒看到任何人在反省產品經理到底應該如何驗收才能避免這樣的事情再次發生。
一、產品經理到底需不需要驗收
這個問題的答案是肯定的，產品經理一定要做驗收，至于其必要性，我們看一看產品經理不做驗收會產生什么后果就知道了。
1. 產品與設計不符
按產品與設計的偏離情況，可分為3種：
1）不符
這種情況指的是產品與設計有偏離，但無傷大雅，甚至可以不按原設計調整。
比如一個原本應該用紅色級別的 Toast 提示被開發成黃色級別，由于紅色和黃色在系統中均有表示警告的含義，所以這個偏離也不是不可以接受的。
2）一般不符
這種情況指的是產品與設計有較大偏離，可能已經影響到產品的使用。
比如一個原本通過彈窗提示的內容被開發成出現一定時間后自動隱藏的 Toast 提示，這個提示文案是在持續等待一段較長時間后出現（比如上傳大文件，或系統處理較多數據的場景下）。
期間用戶的視線可能離開產品界面，彈窗提示可以在用戶回來后看到執行結果，而自動隱藏的 Toast 提示用戶可能會錯過。
3）嚴重不符
這種情況指的是產品與設計嚴重偏離，已經嚴重影響到產品的使用。
比如設計約束一個手機號只能注冊一個賬號，注冊時，已注冊的手機號不能注冊成功，但開發的時候漏掉這一步，注冊時可以使用同一個手機號注冊多個賬號，導致登錄時系統無法識別具體要登錄哪個賬號而出錯。
2. 產品與業務不符
這種情況未必是因為產品與設計不符造成的，而是可能產品設計本身就與業務不符，產品的存在是為了服務業務。
所以一旦產品出現與業務不符的問題，則每一個問題都可能是致命的。
3. 需求變更
產品設計與業務不符需要通過調整錯誤的需求實現來滿足業務，這必然會帶來需求的變更。
4. 返工
發現錯誤的設計或實現，需要推翻原來的工作成果，重新設計和開發。
5. 進度落后
無論需求變更還是返工，都會使原本規劃好的進度落后。
6. 扯皮推諉
出現問題，大家都覺得不是自己的責任，開始互相甩鍋。
二、產品經理為什么不喜歡做驗收
既然產品經理驗收環節這么重要，為什么產品經理們卻不喜歡做驗收呢？
1. 驗收工作繁瑣且枯燥
產品設計的過程是一個探索和創造的過程，對產品經理而言是一個充滿樂趣的過程，多數產品經理在完成產品設計交付給研發的時候，都會有一種“這是目前我能做出來的最棒的設計”、“不可能有比這更好的設計方案了”的想法。
而驗收就不一樣了，雖然交付的是設計，驗收的是產品，但產品經理會認為自己的設計很清晰，不應該有人會誤解，甚至會有一種“我的設計這么棒，竟然讓我給自己的設計挑毛病”的想法。
2. 理所當然地認為這是測試的工作
有的產品經理會認為，設計交付給開發之后就沒有自己的事了，最多在開發過程中幫開發厘清一些有疑問的地方，后續其他工作則與自己無關。
3. 規劃的版本時間過于緊湊
一般版本的研發時間由研發部門來確定，而研發部門在確定版本時間的時候，只會將測試的時間考慮進去，而不會考慮產品驗收的時間，產品經理驗收時間不夠，驗收沒有效果，久而久之就沒有了驗收的習慣，測試通過就上線了。
三、產品經理驗收和測試的區別
產品上線后出現問題，首當其沖的就是測試，接著就是產品經理，最后就容易演變成兩者的相互“甩鍋”。
究其原因是因為公司或部門對二者在產品驗收和測試環節的職責范圍沒有明確劃分，最終只能由管理者來確定應該承擔責任的人，一般如果管理者是研發負責人，會將責任歸咎于產品經理沒有做好驗收，而作為產品負責人的管理者則會認為是測試人員的測試工作做得不到位。
因此，產品研發兩個部門經常“打架”，這也是其中的原因之一。
關于產品經理驗收和測試人員測試的區別，我大概列了以下幾點，各位可以根據自己項目的實際情況參考一下。
看了以上對比之后，你可能會產生一種想法，覺得產品經理的驗收好像很隨性，沒有明確的標準，沒有量化的工具，甚至沒有明確的目標。
的確，明確產品經理驗收這個環節在業內并沒有形成相對統一的標準和方法，更多靠的是產品經理個人的經驗和在驗收時的敏銳程度。
因此每個產品經理也都形成了一套屬于自己的驗收經驗，一名優秀的產品經理經常能夠發現很多測試都難以發現的問題。
四、產品經理驗收，到底是驗什么？收什么
下面根據本人以往的一些項目經驗，簡單總結一下，產品經理驗收，到底是驗什么？收什么？
1. 驗什么
1）驗業務
產品經理是離業務和需求最近的人，也是接收業務信息和需求信息“失真率”最小的人，驗收的時候，優先要考慮的是產品到底能不能滿足業務，或者對業務目標有沒有幫助，而不能一味考慮產品是否與設計一致。
所以產品經理驗收產品的時候，需要代入業務目標。
一個功能，如果能夠滿足業務目標，但是與設計不一致，在不會影響其他功能或交互的情況下，也是可以被接受的。
因為實現同一個業務目標有時候不一定只有一種設計。
2）驗設計
“不能一味考慮產品是否與設計一致”不代表可以不考慮。
上文說到，產品經理驗收的時候不像測試人員一樣有測試用例，所以產品設計就是最好的驗收標準。
按照設計來驗收是最快的驗收方式，只是在碰到與設計不一致的功能實現時，優先要判斷的是實現與業務是否一致，而不是不管不顧地推翻已經做完的功能，要求重新按照設計來做。
3）驗場景
場景指的是業務場景，這個環節也是產品經理最容易發現測試人員發現不了的問題的環節。
測試人員對業務的了解基本都是通過產品經理的傳遞，測試時，針對的業務場景比較單一，產品經理因為對業務的了解更深刻。
因此在測試時，可以挖掘到更多的業務場景，也更容易發現不同業務場景下的問題。
2. 收什么
1）版本基準
當前版本已經驗收通過，可以封版發布，所謂的版本基準就是最終發布的版本內容，有些人可能會說，那不就是版本規劃嗎？其實不然。
版本規劃指的是計劃要實現的功能，版本基準指的是最終實現的功能，在特定情況下，版本基準等同于版本規劃，但更多的時候，版本基準與版本規劃總是會有一些不同。
因此需要將當前的版本基準記錄下來，否則如果以后按照版本規劃回溯當前版本的時候，會發現實際實現的版本與規劃的版本并不完全一致。
2）問題清單
“我們需要盡量發現問題，嘗試解決一些問題，允許存在一些問題?！边@是驗收版本時的一個核心思想，你不可能解決所有問題，因為問題會不斷出現，所有嘗試為了解決所有問題的行為最終都可能會導致版本延期。
所以要有選擇性地解決一些必須在上線前解決的問題，并允許一些無傷大雅的問題存在，當然，這些問題并不是就此放任，而是需要記錄下來，形成問題清單，在后續的版本中逐步解決。
3）迭代計劃
迭代計劃除了來自業務的發展和變化，同時也來自驗收，驗收過程中記錄的問題以及發現的新的需求，將形成新的迭代計劃，并入到新版本的規劃中。
五、產品經理驗收容易陷入什么誤區
產品經理驗收環節容易陷入這個誤區，這些誤區容易導致驗收不充分。
1. 想當然
產品經理在驗收某些功能的時候，容易陷入一種誤區，覺得自己的設計邏輯是很簡單、很符合直覺，或者這是一個常識性的約束，不會有人理解錯誤，因此就不加以驗收。
比如大家都會認為在使用手機號注冊賬號的時候，如果手機號已注冊，是無法注冊成功的，產品經理認為這是一個常識，哪怕自己沒有在文檔中寫出來，開發應該也會這樣實現，驗收的時候也無需針對此項約束進行過驗收，結果產品出來的時候，同一個手機號可以重復注冊，導致登錄的時候系統出錯。
要避免這個誤區，首先在設計的時候，即使是常識性的約束條件也應該清楚寫進文檔中，并在開發完成后逐項驗收。
同時，要正確理解研發人員的工作方式和工作思維，很多時候是幾個研發同時開發一個業務功能，每個人只負責一個子模塊，從他們的角度，很難在腦海中拼湊出完整業務的形態。
所以只能根據設計和文檔進行開發，設計和文檔中沒有的內容，他們是不會主動添加進去的。
2. 驗收場景不充分
這種就是驗收前沒有什么計劃性，看到哪驗到哪，想到什么驗什么，這種“隨心”的驗收方式很容易忽略掉一些場景。
雖然產品經理驗收不像測試那樣有嚴格的測試用例，但要避免驗收場景不充分的誤區，最好在驗收前先有一份“場景驗收計劃表”。
計劃表主要需要包含驗收的場景、準備的數據、預期驗收結果、實際驗收結果。如果可以，提前準備好數據值，這樣驗收的效率更高，準備數據值的時候，注意需要準備多個，主要需要錯誤的數據值、正確的數據值以及邊界值。
下圖是我針對注冊登錄環節驗收整理的部分場景的驗收計劃表，僅供參考：
3. “羅生門”
開發說修復完了，測試說測試通過了，結果產品一看，全是 bug。
這種主要是到了產品后期準備上線的時候經常遇到的問題，產品發現一個問題，開發就改一個地方，測試就測一個地方，導致其他有問題的地方沒有被發現。
這種情況一般是需要多方去規避，比如公司應該有明確的測試流程和管理制度，研發規劃時間的時候需要冗余足夠的時間，產品經理應該充分闡述清楚業務場景等。
以上便是本文的全部內容，感謝閱讀。
專欄作家
產品錦李，公眾號：產品錦李（ID：IMPM996），人人都是產品經理專欄作家。不務正業的產品經理和他的產品設計。
本文原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
產品需要養成驗收的習慣
之前是自己設計自己測試，后來才有專門的測試人員，但是還是要養成驗收的習慣
產品做的是用戶交付；測試做的是流程功能查驗。
你很難指望測試同學幫你去做用戶交付，你必須親自來。
畢竟你拿的比別人更多。
羨慕你們公司有細分測試專員崗位，6年產品生涯一直身兼測試的人路過。在我看來產品驗收還是比較有必要的，因為需求文檔這種載體始終有個描述的細致度上限，為了最終產出真正符合自己的設計、以及更極致的體驗，還是需要產品設計者親自把關的