需求評審會議對整個項目想影響至關(guān)重要，但通常會議總會成為各方的“撕逼”大戰(zhàn)。產(chǎn)品經(jīng)理該如何提高需求評審會議的效率，避免被懟呢？文章作者分享了相關(guān)經(jīng)驗，希望對你有用。

產(chǎn)品經(jīng)理在工作的過程中，最怕的就是評審，記得原來做技術(shù)的時候，每次產(chǎn)品妹妹抱著筆記本進(jìn)入會議室，我們就有一種羊入狼群的感覺，每個工程師都躍躍欲試準(zhǔn)備好怒懟產(chǎn)品，貫徹以一次評審?fù)ㄟ^為恥，以氣哭產(chǎn)品妹妹為榮的評審精神……后來轉(zhuǎn)型做了產(chǎn)品，發(fā)現(xiàn)真是天道輪回，互聯(lián)網(wǎng)行業(yè)永遠(yuǎn)不缺杠精，自己的PRD設(shè)計的接近于高保真，需求帶著十二萬分的誠意，依然被懟的體無完膚。

隨著斗爭的不斷深入，我也痛定思痛慢慢總結(jié)除了一些如何產(chǎn)品PRD評審的生存指南，嘗試與技術(shù)團(tuán)隊融洽的開PRD評審會。

01 突出你的業(yè)務(wù)主場

業(yè)務(wù)知識是產(chǎn)品經(jīng)理的強(qiáng)項，而技術(shù)是弱項，哪怕你是一個技術(shù)職位轉(zhuǎn)崗的產(chǎn)品經(jīng)理，也不要用自己過去的技術(shù)背景來挑戰(zhàn)當(dāng)下的開發(fā)團(tuán)隊，這樣做無異于自掘墳?zāi)梗囅朐O(shè)計一款套餐產(chǎn)品的報價功能時，如果你非要用SKU和價格屬性的方式描述你需求，那最后大概率會演變成大家對SKU顆粒度探討的技術(shù)細(xì)節(jié)問題上。

既然做了產(chǎn)品經(jīng)理，就要突出自己業(yè)務(wù)知識的強(qiáng)項，畢竟業(yè)務(wù)是你的主場，而技術(shù)永遠(yuǎn)是你的客場，所以在PRD評審會上一定要利用好你的主場優(yōu)勢，評審過程中盡量多用業(yè)務(wù)語言來描述你的產(chǎn)品，如果技術(shù)人員對某些關(guān)鍵詞有疑問，再耐心解答。

02 用價值來描述你的訴求

業(yè)內(nèi)有句話叫“產(chǎn)品動動嘴，開發(fā)跑斷腿”，在開發(fā)人員眼中，產(chǎn)品簡直就是自己天天加班，找不到女朋友的罪魁禍?zhǔn)?，每次評審會開發(fā)同學(xué)只會關(guān)注這個評審之后自己的工作量是否會增加，而不會關(guān)心產(chǎn)品的更新能給他們帶來什么價值。

所以在PRD評審時，一定要給開發(fā)人員講清楚這個功能的價值，如果按時開發(fā)出來，對公司和產(chǎn)品幫助，畢竟產(chǎn)品做得好，能帶來更多受益，開發(fā)人員才有工資拿，哪怕加加班趕趕工自然也就沒話可說。

03 讓業(yè)務(wù)人員參與你的評審

B端產(chǎn)品最復(fù)雜的就是業(yè)務(wù)邏輯，而技術(shù)人員最欠缺的就是對業(yè)務(wù)邏輯與業(yè)務(wù)價值的理解，所以在評審的時候，最好加上業(yè)務(wù)需求方的人，最好是直接負(fù)責(zé)人，并與其建立攻守同盟，利用業(yè)務(wù)優(yōu)勢和價值目的擋住技術(shù)人員一波又一波的問題，當(dāng)然前提是評審前你確認(rèn)你做的東西的確是業(yè)務(wù)方想要的，不然只能是讓自己多了一個對手。

04 給出實(shí)體間的關(guān)系

產(chǎn)品經(jīng)理需要對你的需求進(jìn)行一些技術(shù)化的改進(jìn)，針對細(xì)化的業(yè)務(wù)邏輯，將實(shí)體拆出來，雖然說需要一點(diǎn)技術(shù)背景，但也不用真正像技術(shù)人員一樣去設(shè)計模型，只需要定義出實(shí)體之間的n對m的邏輯關(guān)系，有了這個實(shí)體關(guān)系圖，技術(shù)人員就會很輕松的設(shè)計出合理的數(shù)據(jù)庫模型，對你的感激之心也會大增。

05 用戶故事的方式來表達(dá)需求

我們原來在迭代的時候，都是會將PRD拆分成若干的用戶故事，用角色+場景+操作+權(quán)限+目的（價值）的方式來描述要開發(fā)的功能，UI和測試看完需求之后也大體能知道自己改怎么設(shè)計交互和測試用例，對你的好感度上升50%，評審會上可保持中立；同時開發(fā)人員根據(jù)你的描述也能預(yù)估一下技術(shù)難度和工作量，在心底默默的給你點(diǎn)贊。

06 給出完整的字典信息

每個PRD上都要給出可選項的字典值域以及是否必選、是否可多選等元信息，首先這個東東是只有產(chǎn)品知道的，你現(xiàn)在不給后面也還是要給的，屆時給就會落一句“早干嗎去了，非等我找你要才給”之類的埋怨話，而且頻繁發(fā)消息問你，也會埋下雙方日后難以溝通的苦果之種，哪怕是再簡單的可選項也要給出值域，例如性別選項框，如果值域你空著不寫，不排除有些開發(fā)沒事找事的問你，人妖用戶填什么？

07 PRD要考慮技術(shù)的體驗感

最后就是輸出PRD，將PRD當(dāng)成一個產(chǎn)品，而技術(shù)人員就是你的用戶，如何提升你用戶的體驗感呢？我的做法是將PRD的排版按“頁面說明”、“業(yè)務(wù)邏輯”，“數(shù)據(jù)字典”分開，充分考慮技術(shù)人員的閱讀習(xí)慣，減少他們?nèi)庋廴咧匾畔⒌臅r間。

而且，不同角色的開發(fā)人員，對信息獲取也是不同的，就這樣一個小小的改進(jìn)曾經(jīng)讓我在產(chǎn)品復(fù)盤會上收到過兩個正字的好評，全是“prd寫的很清楚，思路清晰”，同技術(shù)人員的關(guān)系也提升不少，說白你如果在開發(fā)PRD的時候設(shè)身處地的為技術(shù)，UI，測試同學(xué)著想，他們也不會難為你。

08 及時的封板以及引入正規(guī)的需求變更流程

雖然說做互聯(lián)網(wǎng)產(chǎn)品要擁抱變化，但擁抱多了心態(tài)或多或少也會扭曲，所以及時的封板讓技術(shù)人員有一個相對的穩(wěn)定的版本進(jìn)行開發(fā)，不要成天體現(xiàn)吊膽的擔(dān)憂需求一直在變，隨意的變化也讓技術(shù)感覺自己的付出變得沒有任何價值，任人踐踏，所以即便是有變化，通過優(yōu)先級與正規(guī)的需求變更評審委員會的權(quán)威性，讓技術(shù)人員感受到需求變更的儀式感。

最后

PS：遇到杠精則見招拆招

評審會上難免會有杠精，有時候人一旦陷入疑人偷斧的狹義思維境地，無論聽見什么聲音，都會認(rèn)為是一種噪音，想盡辦法也要跟你抬杠到底，一般我們遇到這種問題大家的選擇往往都是回避，希望會后私下解決，但是這樣做無異于示弱和逃避，讓對手一而再再而三的在評審會上懟你，這時候不如學(xué)著用太極的思路解決問題。打太極中如果對方正面攻擊你，一般不會直接用手去檔，那樣只能是兩敗俱傷，應(yīng)當(dāng)是讓拳頭順著你的手臂向下化解力量，而與此同時另一只手攻擊對方暴露的后背。

評審會上也是如此，如果遇到杠精跟你杠需求，千萬不要正面對攻，不如試著順著對方的思路去延伸，在延伸的過程中找到破綻，再用你的業(yè)務(wù)深度優(yōu)勢直接否定這個論證，讓對方以后也不敢再輕易的挑釁。

作為產(chǎn)品經(jīng)理完成一次圓滿的PRD并不會得到掌聲，只不過少了一些埋怨和質(zhì)疑，但這就是我們的日常工作啊，當(dāng)你在會議室送走開發(fā)人員靜靜合上筆記本的時候，就是下一場評審戰(zhàn)役的開始。

本文由 @志齊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

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