需求評審前、中、后三階段,都該做好哪些準備?
編輯導語:需求評審目的是讓項目的參與者能夠快速理解產品的意圖,認可采用的方案。那作為產品經理,需要注意哪些事情,才能讓一個需求評審能夠高效的完成呢?本文作者來為您解答這個疑問。
首先,可以回憶一下我們評審過程中遇到的一些問題:
- “這個做了有什么用?”
- “有沒有認真想過?”
- “唉,你這個做了,之前的XX是不是就沒用了”
- “這個做不了”
- “有和業務方確認過嗎?”
- “你這個需求這么大,一下子評的完嗎?”
- “我靠,你是不是傻,哪有這么設計的?”
- “你是產品經理,你的數據呢?”
不管是新手上路,還是老司機開車,在需求評審過程中,相信都碰到過上面的情況。為了讓效率更高,目標明確,我們可以在評審前、評審中和評審后做相應的準備:
一、評審前——做好產品基本功
1. 如果是商業產品需求
請和你的業務方認真推演產品要解決的問題。注意要摳出業務方要解決的問題,而不是問業務方“你要不要這個功能?”
作為產品經理,你要相信自己的產品設計能力,業務方提供的產品方案可以作為參考,不能作為指南。
2. 如果是工具類的產品或者體驗層面的優化
請認真分析各個方案背后的用戶心理變化,同時準備好相關數據佐證你的假設,評審上可能用得到。仔細推敲產品方案,是否有考慮過還有其他的方式可以解決問題,不同的方案優缺點各是什么。
提前找到此項目對應的技術負責人,認真的和他們溝通你的方案和想法,技術的小伙伴們不是被動的執行者,讓他們參與到你的前期設計中來。
請去掉“我是產品經理,我比你懂市場,我比你懂交互,我比你懂人性”的帽子,很多技術小伙伴真的比你懂。
準備好一份邏輯清晰的需求文檔,形式不局限,核心是要表達清楚你的意圖。
3. 如果評審經常出現表達混亂,說的意思別人不容易懂
你可以再辛苦點,準備好一份評審大綱。
仔細review你的需求文檔,是否各個細節都考慮到了,尤其是異常的情況,和其他系統有依賴影響的情況。不然測試的同學會把你問的啞口無言
二、評審中——注意表達,注意情緒,控制好節奏
1. 參與評審的技術,他們的關注點可能各不相同
有的擅長剖析你的需求動機業務目標(大部分的技術leader會關心)、有的擅長追求細節(比如測試同學)、有的喜歡帶偏話題(在你評審的時候,可能他們會提一個其他的話題)、也有的喜歡用“教導你”的口吻“教你”做怎么產品,還有各種各樣
2. 需求開始,講清楚業務背景,確保大家理解的前提下再帶入你的方案
然后記得要闡述為什么要用這套方案,而不是其他方案。這兩件事情需要在開始就說的很清楚,講完后可以停頓讓大家提業務背景和方案的問題。這里要掐斷那些喜歡問交互細節,邏輯細節的問題。
這一步驟的重點是要說清楚發生了什么問題,為什么這么干而不是那么干——這樣不至于在后續的環節里,又有人提回來質疑你的需求背景
3. 復雜的問題,用流程圖再結合“總分總”的方式
可以先說明白整理步驟,先做什么,再做什么,最后做什么。然后再按步驟細評各個環節的細節,都評完后再闡述一下總的流程。
4. 注意話題不要被帶偏
在過程中,出現某個同學說“唉,之前有個XX也是類似的問題,還沒解決”。這個時候作為產品經理,應及時掐住話題源頭,可以說這個問題待會私下討論。
5. 新人可以求助會議上稍微資深的技術大大來控制節奏
“這個問題好像和本次評審無關,李大大我們會后再聊這個,你看怎么樣?”——李大大可能是個技術總監。
6. 你也會遇到喜歡爆粗口的技術
“這有個**啊!”
“你是不是**??!”
我們要控制好自己的情緒,因為這個粗口的背后,他們想表達的意是:“這樣設計是不是不對”?只是加了一個感嘆詞嘛。
聽他們把背后的原因說出來,不建議用“為什么沒用???”“這樣挺好的啊”“你才**”來正面回應他們的感嘆詞,這會讓氣氛更尷尬,后面的評審更難進行。
可以問“是有什么問題嗎?”,“方案哪里不合理?”
7. “這個不好做”、“實現不了的”
遇到技術們這樣的回應時,絕大情況下是背后有一個巨大的開發量。
不建議直接駁斥“這個還這么麻煩?。俊薄昂芎唵蔚陌?,這樣搞搞就行了啊”。
我們需先權衡是否值得這樣的投入?如果的確是一個很重要的業務卡口,可以表達清楚這件事的嚴重性,就算開發復雜,需要較多的時間也可以接受。
8. 做好會議紀要
以便會后討論和修改
三、評審后——保持持續跟進,反復review
評審結束不代表就等著上線了,接下來要做的是持續的關注。需要不斷的review,確保該表達的細節都有表達。
需求更新,請維護好更新的記錄,在什么時間點更新的,請通知相關的開發測試設計同學,不要藏著掖著。
跟進開發計劃和進度,準備二期的內容
最后,你得讓技術感受到你是要做好產品的,不是完成任務的(自行體會)。
作者:歸歸類,微信公眾號:gglei666
本文由 @歸歸類 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
產品為公….
嘿,大佬,你好鴨,我是一個產品小萌新,我想問個問題,當自己設計的需求確定,在評審后開發跑來和自己說這里這里需要改,哪里哪里能不能這樣做的時候,我們產品應該怎么辦?
嘿嘿beta,你好,我看過這篇文章很多次,給我了我一下工作上的思路,作為一個新人,常常對寫出好的需求文檔頭疼,要是可以分享一下需求文檔的結構、注意點就好了
補充幾個 1.沒見過你這么奇葩的設計 2.你們不要憑空想象,多參考別人的 3.你說這樣我們就這樣做,根據你的來(這個真是狠啊,我完全無招)
3的話,就淡定的說聲“謝謝”,哈哈哈哈
哈哈哈,我常遇到的就是3
經常遇到3.。。
相當有用,經常被撕逼
開心~
很實用……
開心~
最近遇到這樣的一個客戶,客戶那邊派了一個交接人和我對接,然后我完全按照那個人的意思以及合同上面的規定完成了初審功能設計,結果功能評定的時候,我發現他們領導和那個交接人的想法有一半是不同,因此聆聽他們領導在會上說的需求時我感到特無語。。。目前已經找到了解決方法,既不想多做超出合同范圍內的工程,也不想弄得東西是真正的客戶不需要的
深有同感,特別是大公司客戶,除了對接人的領導意見不同,還可能遇到領導的領導又有不同意見的情況,或者也有可能對方內部斗爭,跟這個產品做得怎么樣根本沒有關系……