高效需求評審:需求評審分為哪幾個階段
產品經理需要發問,需求評審就沒有一次就過的時候嗎?答案是沒有,為什么?
有一則故事:在一個需求評審的現場,參加的人有產品線的產品總監、產品經理、設計負責人、技術總監以及老板,產品經理伴著低保真的交互演示,開始介紹產品的需求、功能和交互。
產品總監說,還有一種情況你沒有考慮到。
技術總監說,這樣做太麻煩了,開發成本很高。
設計負責人說,這個地方的交互你確定是這樣的嗎?
老板說,我們的用戶是不是還有另一種需求,像我自己…
之后,他們又對此爭論了一番,才說服老板突然的想法。這時候產品經理心理五味雜陳,一方面覺得他們有的地方說得確實有改進的空間,另一方面面對領導和上級,有些地方他又沒有辦法很好去公開表達自己的想法。
最后,產品經理只好乖乖地回去一通改,而忘記了最初的需求和思考。
這是大多數產品經理的真實寫照,那么如何進行高效地需求評審?
首先,產品經理需要發問,需求評審就沒有一次就過的時候嗎?
答案是沒有,為什么?
有一點觀點需要明確,影響產品最終走向成功或者失敗的原因有很多,包括真實的需求、良好的用戶體驗、美觀的界面、可預期的開發成本等等。需求評審就是為了發現問題,保證產品能夠一直走在正確的方向。從宏觀上來講,需求評審需要傾聽。
那么從需求評審的外部來看,需求評審又分為哪幾個階段呢?
需求評審分為不同的階段,一般分為內部評審、預評審、正式評審和終評審四個階段。內部評審、預評審、正式評審和終評審的目的不同,參加的人員也有所不同。 同時,每一個階段也并不一定每次都一次通過。
內部評審的主要目的是:產品出了低保真原型之后,先進行內部的評審。即產品經理同事之間的相互評審,尤其是同一產品線有關聯的不同項目,如不同客戶端或者產品邏輯上有聯系。
產品經理同事坐在一起相互提建議、梳理邏輯、找坑,根據需求出發,發現產品邏輯問題。同時內部評審的又一個重要的目的是為了保證在更大范圍的需求評審會議上,產品經理同事之間可以保持立場的一致性。
預評審階段的主要目的是:產品出了低保真原型之后,先小范圍的進行溝通,提前滅掉大問題,從需求開始審視,確保方向正確之后,才能夠進入高保真設計階段,減少后續需求推翻帶來的人力資源浪費。
一般參加的人員有產品自己、產品線的同仁(包括產品總監)、UE和UI設計負責人、技術總監等。人員范圍不宜過大,主要是產品的前半階段的核心人員。
正式評審階段的主要目的是:設計根據完善后的低保真設計出高保真頁面,產品做好高保真交互原型,此時基本上可以還原產品90%的需求和交互場景,代表著產品的最終形態,除了基本的物料和數據交互之外。也就是說對高保真交互原型質量要求比較高,產品的核心人員會在一起看一下高保真的整體效果。
一般參加的人員有產品自己、產品線的同仁(包括產品總監)、UE和UI設計負責人、技術總監等。主要是在高保真環境下瀏覽產品的需求、功能、交互以及界面樣式,強調高保真的整體感受。
終評審階段的主要目的是:根據最終完善的高保真交互原型,產品提供產品說明文檔,提交給研發,讓研發理解需求、統一思想、確認實現方法和數據處理、評估研發周期,最終進入研發階段。
一般參加的人員主要有產品自己、產品線的同仁、相關研發工程師、測試工程師、運營等。涉及的人員主要是產品的后半階段的相關人員。
以上便是需求評審的4個不同階段,依照評審的不同目的來劃分。當然在實際的執行過程中,并不一定是4個階段都需要分別走一遍,可以根據實際情況適當地改變策略。
套路是死的,人是活的,具體看所在公司工作方式。對于初級產品經理來說,尤其要注意不同的需求評審階段的目的。
下一期我們講講需求評審的關鍵流程。
作者:吳翰中,微信公眾號:翰中的產品思考(ID:hanzhongPM)。寧思一時進,莫思一時停。
本文由 @吳翰中 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
產品經理這個站點的文章普遍都是3-4年前的。
下一期呢?
作者鴿了
一般互聯網公司和創業型公司講究的是快,一次評審4次會議,約人約時間比較難。對于互聯網企業,三次足以,第一次,找技術經理和UI設計確認,第二次找拉上部門老大,boss一起碰撞,主架構和主功能和首要開發功能必須確定。第三次和boss、領導確認修改完的東西,就可以進行迭代計劃會了。一般toB不太講究交互,可以先野蠻式的增長再優化。toC的交互可以和設計討論出交互的方案,會議中說明。大家的時間都很寶貴,幾個關鍵:1. sponsor(買單的人)必須點頭確認 2. 主路徑和主功能確認
交互原型這塊略過哈哈哈
哈哈哈哈 看了作者的文章 受益匪淺,作者是如愿找到教育類產品經理的工作了嗎
創業公司這樣搞,怕是熬死了產品也沒出來
強地板的來了
一頓操作猛如虎,一個響指二百五
搶沙發來的……