需求評審會對於產品經理來說就像是家常便飯,需求評審串起來了前期的需求調研和分析,不同利益相關方的博弈,以及後續專案落地實施的計劃,是產品在正式開發之前非常重要的一環。
然後我們就來介紹介紹這個需求評審。
一:需求評審是什麼
二:為什麼要開需求評審
三:開需求評審的時候要注意些什麼
四:需求評審碎碎念
▍一:需求評審是什麼
這個詞聽起來很高階,但是實質上就是開會討論問題,然後開會人員就是與本產品相關的研發人員,專案經理,測試人員,業務方,設計師等等之類。
▍二:為什麼要開需求評審
1.
可以將需求以通俗易懂的語言傳達給相關研發,設計,測試等人員,達成需求理解的一致,讓他們明白為什麼要這麼來做這樣一個東西,它的價值是什麼,它將會成長為什麼樣子,明確接下來的工作應該怎麼樣去展開。
2.
防止在一次迭代中因為沒有任何需求評審,研發完全按照產品需求文件進行開發,導致的理解不一致產生需求偏差。最後做出來的東西不是真正需要的。
3.
讓大家一起來思考,畢竟一個人的思維是有侷限性的,當局者迷,旁觀者清,再有經驗的產品經理也會有思考不全面的時候,這時候就可以藉助需求評審,藉助團隊的力量來完善產品的細節。
▍三:開需求評審的時候需要注意一些什麼
1.
需求評審前
(1
)明確會議目標
也就是我們要準備好我們的講解材料,確認講解形式和講解順序,把控著講解的重點,不餓能偏移。
比如:我們的需求文件一定要能把我們的需求講清楚,(一定要提前把需求文件發到參會人員手中!!!)
我們的講解形式是先整體講完需求,再進行答疑呢?
還是邊講解邊進行答疑呢?
我們的講解順序是什麼樣的,那麼多需求,先講哪一個會更好呢?
本次需求評審會必須要講解清楚的東西是什麼,不能把一些旁支末節都弄完了,但是主要的重點還沒開始,那樣就白白浪費時間了。
(2
)提前預約會議
a。我們要提前確定參會人員
b。和他們溝通好時間,確保每個人都有空的時候
c。預約好會議室,不能都要開始前幾分鐘了,都還不知道要去哪裡
d。提前和參會人員告知會議的時間和地點,不要臨開會了突然通知別人,重要的人員更要單獨通知。
(3
)提前溝通
不要把所有的問題都推到評審會上,這樣的話很浪費時間,應該要提前和重要的相關人員(比如開發,運營,設計師)溝通,解決重要問題
真正高效的會議應該是私下解決重要問題,會議只是走流程,確保所有人都知道,保證需求的一致性。
關注公眾號有更多精彩內容~
2.
需求評審中
大
致的流程一般是這樣:需求背景
-
使用者和需求-
功能模組-
講流程-
原型與互動-
資料指標-
需要誰支援-
預計上線時間
(1
)需求會議有以下四大原則
a.
求同存異,
學會尋找每個人的實際需求的共通點,使我們的會議最後能產出一個結果。
b.
放過細節,
每一個需求會議其實都是對公司資源的很大佔用,我們不能死扣著某個細節不放而大大耽誤了時間,這是不符合資源最大化利用的,會議上只需要討論可行性就行,具體的細節等之後再敲定。
c.
適度休息,
開需求會議使很累的,每個人都是全神貫注的,因為都和自己有著密切的聯絡,一直高強度的開容易引發爭吵,所以需要適度休息,避免吵架。
d.
把控時間,
主持人不要在一件事情上耽擱太久,要儘量在合理的時間內解決問題,不要讓解決問題成為打太極,無限迴圈。
(2
)需求的重要資訊
a.
價值:
為什麼要做這個需求,上線之後的價值是什麼
b.
功能:
為了支援這個價值,需求包含了哪些功能呢
c.
實現:
針對每一個功能,該怎麼去實現
(3
)需求等級評審中概念
a.
功能最佳化
重點在講清楚如何做,往往評審時間較短,不會單獨組會,會跟著其他需求一起評審。
b.
功能拓展
重點在講清楚是什麼,與原有功能的聯絡是什麼,可能要單獨組會
c.
新專案
重點在講清楚為什麼要立這個專案,專案包括哪些模組,模組之間的聯絡是什麼以及每個模組的功能和怎麼實現。
(2
)如何表述
a.
用最直接的方法說明需求價值
量化指標,以數字來切入,
b.
邏輯+
模組
總:專案背景-目標-系統架構-重要流程
分:各個功能
總:總結性發言
(3
)注意事項
a.
因為原型內容相對較多,所以要注意講解模組的節奏,給大家留有一定的思考時間
b.
講解時要注意語速和語調的變化起伏,要讓你的講解有起伏,從聽覺上是一種享受
c.
需求講解,為了讓內容更加豐富化和趣味化,可以以使用者故事的形式去講解,一個個小故事串聯起整個系統
d.
要放平心態,要知道需求的設計不可能使完美無缺的,我們有可能存在邏輯漏洞,我們也有可能在講解使做不到面面俱到,會存在一些隱含的需求未被講解出來等等。
e.
在需求宣講和答疑的時候,需要做的使收集專案組成員的問題,然後補充到自己的原型設計裡面。
3.
需求評審後
(1
)會後跟進
這主要分為三部分:待討論,待完善,以確認
a。待討論:指會上的遺留問題
b。待完善:指會上確認要改的問題,後續自己要完善在文件中
c。已確認:指會上討論出要做和不做的結論的點
(2
)問題修改
及時跟進評審問題,迅速改進
(3
)專案排期
讓產品落地
a.
開發時間評估:
確認開發週期
b.
輸出結果評估:
分配對應的需求所需要的人和天數
c.
專案排期:
確認各個重要的時間節點(開始開發時間,整體提測時間,UAT時間。釋出時間)
(4
)注意事項
如果開評審會議的時候,有參會人員因為某些原因未到達現場,也要將會議紀要和評審結果發給缺席人員,再與其單獨溝通,確保雙方的理解是一致的。
▍四:需求評審碎碎念
需求評審被懟使產品經理多多少少都會遇到的問題,這也是鍛鍊產品經理抗壓的一種方式,不要輕易就失去自己的平常心,被懟證明自己的考慮還不周到,還可以繼續提升。
最後,祝大家都能成為一名優秀的產品經理!!!
往期產品系列乾貨
歡迎你掃碼新增我的個人微信,加入我的電商產品社群,目前已經有5000+同學加入,和大家一起討論電商、供應鏈、出海電商等各方面的話題。