需求評審會不想被懟?你需要這8招
需求評審會議對整個項目想影響至關重要,但通常會議總會成為各方的“撕逼”大戰。產品經理該如何提高需求評審會議的效率,避免被懟呢?文章作者分享了相關經驗,希望對你有用。
產品經理在工作的過程中,最怕的就是評審,記得原來做技術的時候,每次產品妹妹抱著筆記本進入會議室,我們就有一種羊入狼群的感覺,每個工程師都躍躍欲試準備好怒懟產品,貫徹以一次評審通過為恥,以氣哭產品妹妹為榮的評審精神……后來轉型做了產品,發現真是天道輪回,互聯網行業永遠不缺杠精,自己的PRD設計的接近于高保真,需求帶著十二萬分的誠意,依然被懟的體無完膚。
隨著斗爭的不斷深入,我也痛定思痛慢慢總結除了一些如何產品PRD評審的生存指南,嘗試與技術團隊融洽的開PRD評審會。
01 突出你的業務主場
業務知識是產品經理的強項,而技術是弱項,哪怕你是一個技術職位轉崗的產品經理,也不要用自己過去的技術背景來挑戰當下的開發團隊,這樣做無異于自掘墳墓,試想設計一款套餐產品的報價功能時,如果你非要用SKU和價格屬性的方式描述你需求,那最后大概率會演變成大家對SKU顆粒度探討的技術細節問題上。
既然做了產品經理,就要突出自己業務知識的強項,畢竟業務是你的主場,而技術永遠是你的客場,所以在PRD評審會上一定要利用好你的主場優勢,評審過程中盡量多用業務語言來描述你的產品,如果技術人員對某些關鍵詞有疑問,再耐心解答。
02 用價值來描述你的訴求
業內有句話叫“產品動動嘴,開發跑斷腿”,在開發人員眼中,產品簡直就是自己天天加班,找不到女朋友的罪魁禍首,每次評審會開發同學只會關注這個評審之后自己的工作量是否會增加,而不會關心產品的更新能給他們帶來什么價值。
所以在PRD評審時,一定要給開發人員講清楚這個功能的價值,如果按時開發出來,對公司和產品幫助,畢竟產品做得好,能帶來更多受益,開發人員才有工資拿,哪怕加加班趕趕工自然也就沒話可說。
03 讓業務人員參與你的評審
B端產品最復雜的就是業務邏輯,而技術人員最欠缺的就是對業務邏輯與業務價值的理解,所以在評審的時候,最好加上業務需求方的人,最好是直接負責人,并與其建立攻守同盟,利用業務優勢和價值目的擋住技術人員一波又一波的問題,當然前提是評審前你確認你做的東西的確是業務方想要的,不然只能是讓自己多了一個對手。
04 給出實體間的關系
產品經理需要對你的需求進行一些技術化的改進,針對細化的業務邏輯,將實體拆出來,雖然說需要一點技術背景,但也不用真正像技術人員一樣去設計模型,只需要定義出實體之間的n對m的邏輯關系,有了這個實體關系圖,技術人員就會很輕松的設計出合理的數據庫模型,對你的感激之心也會大增。
05 用戶故事的方式來表達需求
我們原來在迭代的時候,都是會將PRD拆分成若干的用戶故事,用角色+場景+操作+權限+目的(價值)的方式來描述要開發的功能,UI和測試看完需求之后也大體能知道自己改怎么設計交互和測試用例,對你的好感度上升50%,評審會上可保持中立;同時開發人員根據你的描述也能預估一下技術難度和工作量,在心底默默的給你點贊。
06 給出完整的字典信息
每個PRD上都要給出可選項的字典值域以及是否必選、是否可多選等元信息,首先這個東東是只有產品知道的,你現在不給后面也還是要給的,屆時給就會落一句“早干嗎去了,非等我找你要才給”之類的埋怨話,而且頻繁發消息問你,也會埋下雙方日后難以溝通的苦果之種,哪怕是再簡單的可選項也要給出值域,例如性別選項框,如果值域你空著不寫,不排除有些開發沒事找事的問你,人妖用戶填什么?
07 PRD要考慮技術的體驗感
最后就是輸出PRD,將PRD當成一個產品,而技術人員就是你的用戶,如何提升你用戶的體驗感呢?我的做法是將PRD的排版按“頁面說明”、“業務邏輯”,“數據字典”分開,充分考慮技術人員的閱讀習慣,減少他們肉眼去掃重要信息的時間。
而且,不同角色的開發人員,對信息獲取也是不同的,就這樣一個小小的改進曾經讓我在產品復盤會上收到過兩個正字的好評,全是“prd寫的很清楚,思路清晰”,同技術人員的關系也提升不少,說白你如果在開發PRD的時候設身處地的為技術,UI,測試同學著想,他們也不會難為你。
08 及時的封板以及引入正規的需求變更流程
雖然說做互聯網產品要擁抱變化,但擁抱多了心態或多或少也會扭曲,所以及時的封板讓技術人員有一個相對的穩定的版本進行開發,不要成天體現吊膽的擔憂需求一直在變,隨意的變化也讓技術感覺自己的付出變得沒有任何價值,任人踐踏,所以即便是有變化,通過優先級與正規的需求變更評審委員會的權威性,讓技術人員感受到需求變更的儀式感。
最后
PS:遇到杠精則見招拆招
評審會上難免會有杠精,有時候人一旦陷入疑人偷斧的狹義思維境地,無論聽見什么聲音,都會認為是一種噪音,想盡辦法也要跟你抬杠到底,一般我們遇到這種問題大家的選擇往往都是回避,希望會后私下解決,但是這樣做無異于示弱和逃避,讓對手一而再再而三的在評審會上懟你,這時候不如學著用太極的思路解決問題。打太極中如果對方正面攻擊你,一般不會直接用手去檔,那樣只能是兩敗俱傷,應當是讓拳頭順著你的手臂向下化解力量,而與此同時另一只手攻擊對方暴露的后背。
評審會上也是如此,如果遇到杠精跟你杠需求,千萬不要正面對攻,不如試著順著對方的思路去延伸,在延伸的過程中找到破綻,再用你的業務深度優勢直接否定這個論證,讓對方以后也不敢再輕易的挑釁。
作為產品經理完成一次圓滿的PRD并不會得到掌聲,只不過少了一些埋怨和質疑,但這就是我們的日常工作啊,當你在會議室送走開發人員靜靜合上筆記本的時候,就是下一場評審戰役的開始。
本文由 @志齊 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
講的非常好啊,加油樓主,多輸出干貨
謝謝鼓勵,一直在摸索中前行
感謝分享
謝謝啦
雖然內容非??斩?、讀起來不知所云,3萬閱讀量只有3個點贊,但還是感謝作者能夠貢獻杰出的反面教材!
看到評論,又看到這么殺馬特的名字,馬上第一時間虛心拜訪你的空間,但是發現果然高手都是深藏不露,非常感謝你的直言,雖然有些刻薄,但是想到也許你正經歷某些生活或事業的不順,或許我的文章能讓你有一絲發泄的快感也算是我微弱的不起眼的一點幫助,朋友,無論如何哪怕是一抹生命之光飄過頭頂,也要當做是你人生事業寒冬中的一點希望,有希望就有前途,加油,如果需要幫助,歡迎留言。
想讓你評價一下我的 ??
活捉一只杠精
他一定是技術部派來的
哈哈哈
立馬虛心訪問空間 發現杠精都深藏不露