需求評審會怎麼做？

大概看到這個標題很多PM小夥伴情緒有些小波動，是的需求評審會聽上去挺高大上，但對許多小夥伴來說簡直就是噩夢，在行業內他還有個“優雅”的叫法“撕逼大會”，每個從會議室堅強走出來的小夥伴都有一部血淚史，廢話不多說，今天我們來聊下如何能讓自己昂首挺胸的從會議室走出來。

為什麼要開需求評審會？

一、 讓團隊中所有人知道我們這個需求的背景和目的

無論什麼職位都需要一個歸屬感，而不是一個接收任務和完成任務的工具，讓團隊中每個人都瞭解一件事情的來龍去脈更有利於這件事上的落實和達成共識。

二、評估設計、開發、測試的週期，便於做決策

我們做需求評審會時要帶上前文說過的業務流程圖、頁面流程圖、互動原型圖，和團隊的每個負責成員評估週期，如果評估結果時間超出預算時間，例如我們要配合運營在520當天上線一個活動，但以目前的人力無法按時上線，那麼通過評估我們做出決策在當前情況下要和領導申請更多的資源。

三、讓參與者明確工作內容和交付時間

這個就是在我們幾次需求評審修訂後最終定方案，團隊中的每個人員都清楚接下來每個人的工作內容和需要階段性的產出交付物。

怎麼做需求評審會？

主要分三個階段要做好對應的工作：評審會前、評審會中、和評審會結束後。

一、評審會前的準備工作

• 四份文件準備
  四份文件包括：“需求文件”“業務流程圖”“頁面流程圖”“互動原型圖”，先檢查自己這四份文件是否還存在問題，並與相關的人員提前確認文件，這裡主要指研發人員，當然技術出身的產品經理就不用了，我曾和一些朋友聊過這件事情，有些公司跟技術經理確認的，這個看具體情況，確認的目的是為了提前掃清障礙，避免自己的文件中有大的邏輯問題和開發無法實現的功能導致會議無法進行下去，確認之後修改就可以把文件打包發給相關人員了。
• 提前預約時間
  參與需求評審會的人一般有以下一些人：領導、設計、研發、測試、運營。一般評審會前2-3天發邀請，這裡特別說下為什麼一定要拉著領導，有時候做專案資源是不足的，比如缺人你自己和領導說領導可能不一定給批，拉著領導讓領導有個數，後面爭取資源比較容易些。

二、評審會時注意事項

• 邏輯清晰
  這點還是需要鍛鍊的，首先要準備充足，有個大概的提綱第一點講什麼、第二點講什麼......之後沒什麼訣竅幹多了就好了，哈哈
• 講故事
  這個就是功能用故事的方法去講，讓講功能變的有趣點，比如某個使用者在什麼場景下有什麼痛點我們這個功能可以解決這個問題，這樣來敘述功能，不然你講著講著很起勁下面不是玩手機就是玩手機。
• 不要太抓細節
  這個主要互動原型圖出現的比較多，比如像某個按鈕放在哪裡不合適的問題，這個可以會後去完善不要花過多時間去討論這樣的問題，主要考慮大的問題。
• 做記錄
  敲黑板這裡是重點，一定要找個同事幫你記錄下來爭論的點，因為自己要進行講解所以要找個同事幫忙記錄，這個一定要做，不然後面再去想或者找別人去討論很麻煩。

三、評審會結束

• 發會議記錄
  評審會後要發會議記錄和團隊成員確認有爭議的問題。
• 整理問題，出解決方案
  評審會很少有一次過的，對於第一評審後的問題要整理並出新的解決方案，小的問題發出確認即可，大的問題還要約第二次評審，一般第二次評審就可以不用約領導了，畢竟領導也忙，哈哈。
• 重新整理需求文件，存檔
  對於要解決的問題需要在對應的文件上進行更新，如果方案確定要對所有的文件進行存檔備案。
• 排期
  最後一次評審會確定就要排期，這個可以跟相關部門的負責人溝通，比如技術經理，需要多久時間什麼時候可以上線。
  對於要不要寫這篇文章我也想了很久，大家應該都經歷過需求評審會議，這裡面沒什麼技術含量，但是如果需求評審會做的好對於產品經理樹立威信很有幫助，需求評審會各種被挑問題，大家就會對你的能力質疑，做的好的話後面的溝通都會很順利，大家也會很信任你，提升的竅門嗎？注意細節多練習，哈哈我還是比較信奉那句話的通往成功最大的捷徑就是踏實走好每一步。