需求評審會怎麼做？

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

為什麼要開需求評審會？

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

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

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

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

三、讓參與者明确工作内容和傳遞時間

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

怎麼做需求評審會？

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

一、評審會前的準備工作

• 四份文檔準備

  四份文檔包括：“需求文檔”“業務流程圖”“頁面流程圖”“互動原型圖”，先檢查自己這四份文檔是否還存在問題，并與相關的人員提前确認文檔，這裡主要指研發人員，當然技術出身的産品經理就不用了，我曾和一些朋友聊過這件事情，有些公司跟技術經理确認的，這個看具體情況，确認的目的是為了提前掃清障礙，避免自己的文檔中有大的邏輯問題和開發無法實作的功能導緻會議無法進行下去，确認之後修改就可以把文檔打包發給相關人員了。

• 提前預約時間

  參與需求評審會的人一般有以下一些人：上司、設計、研發、測試、營運。一般評審會前2-3天發邀請，這裡特别說下為什麼一定要拉着上司，有時候做項目資源是不足的，比如缺人你自己和上司說上司可能不一定給批，拉着上司讓上司有個數，後面争取資源比較容易些。

二、評審會時注意事項

• 邏輯清晰

  這點還是需要鍛煉的，首先要準備充足，有個大概的提綱第一點講什麼、第二點講什麼......之後沒什麼訣竅幹多了就好了，哈哈

• 講故事

  這個就是功能用故事的方法去講，讓講功能變的有趣點，比如某個使用者在什麼場景下有什麼痛點我們這個功能可以解決這個問題，這樣來叙述功能，不然你講着講着很起勁下面不是玩手機就是玩手機。

• 不要太抓細節

  這個主要互動原型圖出現的比較多，比如像某個按鈕放在哪裡不合适的問題，這個可以會後去完善不要花過多時間去讨論這樣的問題，主要考慮大的問題。

• 做記錄

  敲黑闆這裡是重點，一定要找個同僚幫你記錄下來争論的點，因為自己要進行講解是以要找個同僚幫忙記錄，這個一定要做，不然後面再去想或者找别人去讨論很麻煩。

三、評審會結束

• 發會議記錄

  評審會後要發會議記錄和團隊成員确認有争議的問題。

• 整理問題，出解決方案

  評審會很少有一次過的，對于第一評審後的問題要整理并出新的解決方案，小的問題發出确認即可，大的問題還要約第二次評審，一般第二次評審就可以不用約上司了，畢竟上司也忙，哈哈。

• 重新整理需求文檔，存檔

  對于要解決的問題需要在對應的文檔上進行更新，如果方案确定要對所有的文檔進行存檔備案。

• 排期

  最後一次評審會确定就要排期，這個可以跟相關部門的負責人溝通，比如技術經理，需要多久時間什麼時候可以上線。

  對于要不要寫這篇文章我也想了很久，大家應該都經曆過需求評審會議，這裡面沒什麼技術含量，但是如果需求評審會做的好對于産品經理樹立威信很有幫助，需求評審會各種被挑問題，大家就會對你的能力質疑，做的好的話後面的溝通都會很順利，大家也會很信任你，提升的竅門嗎？注意細節多練習，哈哈我還是比較信奉那句話的通往成功最大的捷徑就是踏實走好每一步。