如何組織一場成功的需求評審?
在需求評審中被diss幾乎是每個(gè)產(chǎn)品經(jīng)理都會遇到的問題,要想在評審的時(shí)候被diss得越來越少,產(chǎn)品經(jīng)理必須做好充分的提前準(zhǔn)備工作。
需求評審對于產(chǎn)品經(jīng)理可以說是家常便飯,這是很多產(chǎn)品經(jīng)理都非常害怕去做的一個(gè)會議。因?yàn)楹芏鄷r(shí)候產(chǎn)品經(jīng)理在需求評審會上,是一個(gè)被集體攻擊的一個(gè)的對象,處在一個(gè)非常弱勢的位置。
我自己也組織過或參加過不少需求評審會,我覺得出現(xiàn)這種情況的最主要原因就是需求評審做得不好,做得不好就會被質(zhì)疑,然后連帶著你的專業(yè)能力也會被質(zhì)疑。
所以做好需求評審對于一個(gè)產(chǎn)品經(jīng)理的專業(yè)程度以及參與評審的人的印象是非常重要的,下面我想分享一下作為產(chǎn)品經(jīng)理,應(yīng)該怎么樣去組織一場成功的需求評審。
一、什么是需求評審?
總的來說,需求評審就是一個(gè)統(tǒng)一目標(biāo),明確需求,確定實(shí)現(xiàn)過程的會議。在需求會議上,產(chǎn)品經(jīng)理需要跟大家明確需要解決的痛點(diǎn)問題,有哪些功能以及對應(yīng)的計(jì)劃,然后大家在會議上挑刺,討論,甚至是撕逼,最終全體成員達(dá)成一致意見后開始開干。所以,通常一些項(xiàng)目需求都是要經(jīng)過幾次評審會才能完成的。
二、為什么非得做需求評審?
- 讓大家都清楚需求的背景和目標(biāo);
- 統(tǒng)一需求實(shí)現(xiàn)的過程,方案以及相關(guān)功能點(diǎn);
- 讓參與成員清楚知道各種的任務(wù)以及完成時(shí)間;
- 確認(rèn)研發(fā)和測試工時(shí),產(chǎn)品經(jīng)理按照需求上線時(shí)間判斷是否再進(jìn)行任務(wù)拆分,增加資源。
三、需求評審的參會人員有哪些?
在需求評審中,選擇合適的參會人其實(shí)很重要,我們絕不能為了讓所有人都有參與感而把能想到的人都邀請了,但是其實(shí)很多人去參加完了整個(gè)會議發(fā)現(xiàn)自己并沒有對應(yīng)任務(wù)。
主要邀請的參會人是根據(jù)我們在輸出需求方案的過程中是否涉及到相關(guān)任務(wù)決定的,一般一場需求評審會都會邀請以上的人員參加,再根據(jù)項(xiàng)目需要還有可能需要邀請前端,UI,UE等。
四、如何組織一場成功的需求評審
1. 組織需求評審前的準(zhǔn)備工作
- 首先,確認(rèn)需求文檔、原型都已經(jīng)完成;
- 提前找核心人員溝通需求主流程,提前消除大問題;
- 至少提前一天跟參會人員確認(rèn)會議時(shí)間,確認(rèn)后提前定好會議室并發(fā)出會議邀請;
- 確認(rèn)會議時(shí)間后,提前給參會人員發(fā)PRD和原型,讓大家可提交了解需求;
- 做好會議規(guī)劃,精準(zhǔn)管理開會時(shí)間,如果是大型的需求或者項(xiàng)目,建議在評審會前先預(yù)演一遍評審流程。
2. 需求評審現(xiàn)場關(guān)鍵流程及注意點(diǎn)
需求評審其實(shí)就是對PRD的評審,而PRD的文檔規(guī)格其實(shí)就是你在做需求評審時(shí)的關(guān)鍵流程,一般我會遵從以下的流程:
(1)需求背景
在需求評審開始的時(shí)候,我們首先一定是要介紹需求背景,說明業(yè)務(wù)現(xiàn)狀及存在的問題,明確本次評審的新功能/產(chǎn)品需求解決的問題是什么,讓團(tuán)隊(duì)成員們都知道我們?yōu)槭裁匆鲞@個(gè)產(chǎn)品。
只有讓大家對產(chǎn)品需要解決的用戶痛點(diǎn)問題保持一致,我們才能開始后續(xù)具體功能的評審,也能避免往后更多的爭論不休。
(2)用戶與需求
根據(jù)“用戶-場景-需求”的邏輯,闡述此產(chǎn)品主要面對的用戶/用戶角色,并且描述清楚不同用戶對應(yīng)的職責(zé)或者使用場景,通過場景說明列舉需求。
因?yàn)椴煌氖褂脠鼍肮δ芡际谴笥胁煌?,描述清楚場景才能讓參與評審的人更深入地理解用戶的需求。
(3)需求收益
接下來,我們需要跟大家說明一下需求能給公司/用戶帶來的主要收益,讓大家清楚知道這個(gè)需求的價(jià)值是什么。
(4)產(chǎn)品功能模塊
這個(gè)部分是需求評審中的重中之重,是我們重點(diǎn)需要評審的內(nèi)容,涉及到功能、邏輯、原型交互等內(nèi)容,一般在評審中,我會這樣去處理:
- 首先,簡單介紹本次PRD涉及的需求以及模塊功能說明,可以用思維導(dǎo)圖或者列表,目的就是讓參會人先有一個(gè)整體的簡單的了解。
- 根據(jù)不同的功能模塊按子用例維度進(jìn)行評審,先在每個(gè)子用例中說明觸發(fā)條件、要素定義、權(quán)限要求等等;
- 然后,建議針對每個(gè)子用例畫出流程圖,我一直認(rèn)為流程圖在需求評審中是特別重要的,因?yàn)樗軌蜃寘藛T特別是開發(fā)對我們所需做的功能有一個(gè)清晰的認(rèn)識;
- 在介紹完流程圖后,我們需要再詳細(xì)地說明一下業(yè)務(wù)規(guī)則,包括但不限于本功能是可以使用已有的哪個(gè)產(chǎn)品功能還是需要完全重新開發(fā)
- 如果你的需求涉及到原型交互的話,在需求評審的時(shí)候也是需要有相關(guān)說明的,我的習(xí)慣是在介紹完成業(yè)務(wù)規(guī)則后,在大家知道我們的方案要求后,再給大家介紹我們對應(yīng)的原型交互是怎么樣的
(5)衡量需求成功的數(shù)據(jù)指標(biāo)
在介紹完我們所有的功能模塊后,我們需要告訴大家我們這個(gè)需求的成功指標(biāo)以及相關(guān)的計(jì)算公式,取值邏輯,數(shù)據(jù)取值是否需要重新埋點(diǎn)
(6)需要配合部門的哪些支持
如果需求是需要配合部門的支持的,我們應(yīng)該把需要支持的清單列舉一下并說明具體需要什么樣的支持,當(dāng)然這些在產(chǎn)品功能模塊評審的時(shí)候也是要具體說明的,這里只是我們做的一個(gè)總結(jié)
(7)預(yù)計(jì)上線時(shí)間
一般參與評審的需求業(yè)務(wù)/項(xiàng)目都會要求一個(gè)預(yù)計(jì)上線的時(shí)間,我們需要組織開發(fā),測試預(yù)估一下需求工時(shí)。然后,跟據(jù)預(yù)估的工時(shí)判斷一下能否在預(yù)計(jì)上線的時(shí)間準(zhǔn)時(shí)上線。如果工時(shí)比我們計(jì)劃的要長,那這個(gè)就是一個(gè)風(fēng)險(xiǎn),我們就需要跟項(xiàng)目經(jīng)理一起商量風(fēng)險(xiǎn)應(yīng)對方案了。
(8)注意點(diǎn)
1)一定要做好會議計(jì)劃,管理好開會時(shí)間,不然你的需求評審會效率可能會非常低;
2)不要一上來就講功能,這會讓你在整個(gè)評審會的過程中不停地去解答參會人員的基礎(chǔ)問題,浪費(fèi)評審時(shí)間;
3)抓大放小,不要在細(xì)節(jié)上面過多討論,如果是沒有辦法統(tǒng)一大家的決定的,可以統(tǒng)一一下大家做決定的思考方式;
4)講需求的時(shí)候要注意節(jié)奏跟條理性,不能只是一個(gè)走馬觀花的評審流程,在評審的過程中,產(chǎn)品更不能亂;
5)因?yàn)閰⑴c評審的人都有不同的關(guān)注點(diǎn),那評審的過程肯定是會存在爭論點(diǎn)的,一些重要的爭論點(diǎn)一定要記錄下來。
3. 需求評審后跟進(jìn)
1)給所有的參會人員發(fā)一份會議紀(jì)要,紀(jì)要內(nèi)容包括:
- 已經(jīng)達(dá)成一致的會議結(jié)果,如:分工,預(yù)計(jì)上線時(shí)間等;
- 會議上已經(jīng)確認(rèn)了的修改點(diǎn)以及修改后的方案說明;
- 會議上遺留的爭論點(diǎn)/問題,每個(gè)問題責(zé)任方,解決deadline等
2)發(fā)出更新后的需求文檔,并且更新到公司內(nèi)部系統(tǒng)的產(chǎn)品資源中
3)如果需求文檔需要修改的地方比較多,建議再約一次需求評審會,重點(diǎn)評審修改后部分
五、總結(jié)
需求評審會只是作為產(chǎn)品的一個(gè)日常的工作,我們常說“凡事預(yù)則立,不預(yù)則廢”,在需求評審工作中,當(dāng)你有一套自己的方法,當(dāng)你經(jīng)歷了一次又一次的需求評審后,你會發(fā)現(xiàn)它鍛煉了你的組織能力、表達(dá)能力、邏輯能力、說明力以及執(zhí)行力等等。
所以,別慌,把控好需求評審,讓大家跟著你的節(jié)奏走!
本文由 @Vita 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
- 目前還沒評論,等你發(fā)揮!