5個問題,搞清楚產品經理驗收,到底是驗什么?收什么?

4 評論 12084 瀏覽 124 收藏 16 分鐘
🔗 技术知识、行业知识、业务知识等,都是B端产品经理需要了解和掌握的领域相关的知识,有助于进行产品方案设计和评估

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

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

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

一、產品經理到底需不需要驗收

這個問題的答案是肯定的,產品經理一定要做驗收,至于其必要性,我們看一看產品經理不做驗收會產生什么后果就知道了。

1. 產品與設計不符

按產品與設計的偏離情況,可分為3種:

1)不符

這種情況指的是產品與設計有偏離,但無傷大雅,甚至可以不按原設計調整。

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

5個問題,搞清楚產品經理驗收,到底是驗什么?收什么?

2)一般不符

這種情況指的是產品與設計有較大偏離,可能已經影響到產品的使用。

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

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

5個問題,搞清楚產品經理驗收,到底是驗什么?收什么?

3)嚴重不符

這種情況指的是產品與設計嚴重偏離,已經嚴重影響到產品的使用。

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

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

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

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

3. 需求變更

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

4. 返工

發(fā)現(xiàn)錯誤的設計或實現(xiàn),需要推翻原來的工作成果,重新設計和開發(fā)。

5. 進度落后

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

6. 扯皮推諉

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

二、產品經理為什么不喜歡做驗收

既然產品經理驗收環(huán)節(jié)這么重要,為什么產品經理們卻不喜歡做驗收呢?

1. 驗收工作繁瑣且枯燥

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

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

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

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

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

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

三、產品經理驗收和測試的區(qū)別

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

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

因此,產品研發(fā)兩個部門經常“打架”,這也是其中的原因之一。

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

5個問題,搞清楚產品經理驗收,到底是驗什么?收什么?

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

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

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

四、產品經理驗收,到底是驗什么?收什么

下面根據本人以往的一些項目經驗,簡單總結一下,產品經理驗收,到底是驗什么?收什么?

1. 驗什么

1)驗業(yè)務

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

所以產品經理驗收產品的時候,需要代入業(yè)務目標。

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

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

2)驗設計

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

上文說到,產品經理驗收的時候不像測試人員一樣有測試用例,所以產品設計就是最好的驗收標準。

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

3)驗場景

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

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

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

2. 收什么

1)版本基準

當前版本已經驗收通過,可以封版發(fā)布,所謂的版本基準就是最終發(fā)布的版本內容,有些人可能會說,那不就是版本規(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ī)劃中。

五、產品經理驗收容易陷入什么誤區(qū)

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

1. 想當然

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

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

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

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

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

2. 驗收場景不充分

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

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

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

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

5個問題,搞清楚產品經理驗收,到底是驗什么?收什么?

3. “羅生門”

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

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

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

以上便是本文的全部內容,感謝閱讀。

專欄作家

產品錦李,公眾號:產品錦李(ID:IMPM996),人人都是產品經理專欄作家。不務正業(yè)的產品經理和他的產品設計。

本文原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協(xié)議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 產品需要養(yǎng)成驗收的習慣

    來自廣東 回復
  2. 之前是自己設計自己測試,后來才有專門的測試人員,但是還是要養(yǎng)成驗收的習慣

    來自北京 回復
  3. 產品做的是用戶交付;測試做的是流程功能查驗。
    你很難指望測試同學幫你去做用戶交付,你必須親自來。
    畢竟你拿的比別人更多。

    來自廣東 回復
  4. 羨慕你們公司有細分測試專員崗位,6年產品生涯一直身兼測試的人路過。在我看來產品驗收還是比較有必要的,因為需求文檔這種載體始終有個描述的細致度上限,為了最終產出真正符合自己的設計、以及更極致的體驗,還是需要產品設計者親自把關的

    來自廣東 回復
专题
11600人已学习12篇文章
金融产品的流程与常见策略规则类型是从事相关行业人员需要了解的重要内容。本专题的文章分享了消费金融APP流程详解。
专题
19253人已学习13篇文章
本专题的文章分享了从不同维度拆解一款产品或者功能,有利于提升我们对于产品和功能的思考能力。
专题
13181人已学习12篇文章
随着互联网的不断发展,如今获客渠道及方式也有很多。本专题的文章分享了获客渠道及方法。
专题
36129人已学习19篇文章
新媒体运营,多的是你不知道的事!
专题
12754人已学习14篇文章
良好的交互规范可以很好的帮助企业、团队提高产出,保证用户体验。本专题的文章分享了交互规范指南。
专题
15506人已学习12篇文章
用户增长是一个复杂体系,涉及产品、运营、市场、技术等多个环节的相互配合,本专题的文章分享了用户增长方法论。