編輯導語：對產品經理來說，需求評審是一個必須經歷的過程。只要工作還在進行，需求還在不斷產生，需求評審就要存在。如何高效完成需求評審？這個問題需要在一次次會議中總結經驗，也需要用點“小心思”。

開會是產品經理工作中最常見的事情了，比如需求討論、方案評審、用例評審、項目復盤等等。當你經歷了各種會議，相信你一定有所感觸。

有的會議高效快捷，有的會議卻讓人失望，不僅會議頻頻延時、跑題、還充斥著會而不議、議而不決、決而不行……正確高效的開會是執行能力、表達能力的直觀體現，也是職場人的必修課。如何把會議開好卻不是件容易的事，需要我們花點小心思~

本文以需求評審會為例，通過會前組織、會中討論、會后跟進分別來講解各環節的注意事項。

一、請正視需求評審

當產品經理將需求轉化成PRD文檔輸出后，眼見著就要進入研發階段了，但是在交付前還需要再把把關。需求評審是向相關方講解需求解決方案的過程，也是尋找方案漏洞和獲取多方認可的過程。

評審會議需要完成3個小任務：

1. 描述需求場景：讓相關人員了解需求具體的應用場景，以及需求實現目標和預期獲取到的價值是什么。
2. 講解實現方法：闡明解決方案的功能模塊、實現邏輯、功能操作等內容，需要研發等人員達成共識。
3. 確認工時排期：和下游確認對應工作的具體任務和交付時間。

涉及范圍較廣的需求解決方案一般會經過多輪評審，畢竟經過多次風雨洗禮的方案才會更加“完美”。一稿過的方案除了個人需要準備充分和專業過硬，也需要團隊配合度+1。

當我們了解了需求評審的意義和目的，接下來看看在會議中我們應該怎么做。

二、會前：準備你的武器

相信大家都有組織過會議的經驗，會前準備工作并不復雜，但是隨著會議涉及的部門和人員增多，會前協調工作就顯得十分重要。

事先準備沒有做好，會議基本就垮了……先看個案例，再看下會前準備事項。最近參加過最離譜的會議是ZQ集團召開的跨組織會議，會與方包含ZQ集團軟件部和項目相關的5家供應商公司。

通知參會時主題是“LW工廠倉儲軟件對接會議”，會上溝通的卻是業務實施流程相關內容，完全的文不對題。耗時一天，幾無收獲，造成項目進程暫停和多方資源的浪費。

大家都很忙，所以會議主題、議題、要達成的結果都需要明確并提前告知。以上述例子為戒，受影響的不僅是進度和資源，也會影響組織人員的人品值。

如果人品值的分數過低，影響的不僅是會議組織，其他工作也很難在團隊內開展。

需求評審會議用到的需求文檔、原型等資料需要提前準備并整理完成。會上不能只憑一張嘴，其他讓大家會上自己意會。

人員和時間是會議的基本要素，只有確認好后才能發出會議邀請。

• 與會人員：需求評審的人員一般包含UI、研發（前后端、移動端）、測試、運營，根據需求涉及的范圍，其他相關人員也需要參會。
• 會議時間：隨著人員增多，每個人都有自己的事情，這時時間就較難協調。我們先和核心干系人確認出席時間，再協調其他人員時間。

會議邀請一般會通過郵件和微信進行分別通知。郵件通知正式且便于后續事件追溯，但關注度不夠。所以郵件通知后，會在微信上再次提醒干系人。

1. 郵件會議邀請注意附上會議資料并對重點標注說明，好讓會與人員提前了解信息，如何編寫不在此展開。
2. 會議當天或會議開始前1小時再次微信提醒相關與會人員，避免忙于其他事情導致忘記參會。

會議通知前，產品經理先和核心干系人溝通需求評審的事項（如研發對接人），提前消滅大問題，避免會上出現重大事故。

三、會中：注意控制場面

需求評審的場面往往比較激烈，通常大家都會從各自的角度提出各種問題讓產品經理來解答。那怎么做才能提高會議的效率和質量，讓大家愉快的開個會呢？看過下面的案例，也許就知道該這么做了。

在某次需求評審會上，PM把功能操作邏輯講解十分清楚，但是研發不理解功能的應用場景；系統操作的步驟是否過于復雜反復討論；針對某功能實現方式PM和研發爭論不止；研發非常認真的要對每個字段的限制都要扣明白……

1. 圍繞主題討論

圍繞預設的主題討論是保障會議效率和質量的前提之一。會議中我們要及時識別當前話題是否還在制定的議題中，如果超出范圍，我們需要及時引導回來。針對延伸的話題可以先行記錄，在會后再組織相關人員進行討論。

需求評審一般會跟著PRD的順序進行講解，最忌諱一上來就說功能操作，會讓人莫名其妙。講解順序應當是從概要到詳細，層層推進。

順序參考：需求背景 、方案概述、收益和風險、用戶與需求、產品框架、功能模塊、操作流程、原型交互、數據指標、所需支持、預期上線時間。

會議時間有限，必須有序的推進會議進程，避免單個問題上占用過多的時間。針對討論的問題分清輕重緩急，做到“抓大放小”，在細節上不做過多的爭論。

如果主流程上出現問題，說明產品沒做好準備。此處體現了會前小范圍討論的重要性。討論的場面可能很熱烈，最后必須有確定性的結論，不要光說的熱鬧，最后議而不決（主題外問題先記錄，不做過多討論）。

好記性不如爛筆頭，會議可能長達1~2小時，為了避免會后相關問題的遺漏，一定要及時記錄討論重點。如果來不及寫，錄音是必要的補充措施。會議記錄是針對已確認、待確認、待討論的關鍵內容記錄，同時標記對應事項的跟進人員和執行時間。只有如此才可能避免“決而不行”。

四、會后：跟進跟進跟進

會上聊的再熱鬧，會后沒有執行等于白說。所以會后的跟進是第一要務。要做哪幾件事情呢？先欣賞一個失敗的案例吧……

某次需求評審會，經過會上激烈的討論確認了解決方案調整項若干和待辦事項若干，并且會上指定了對應任務的負責人，然后大家心滿意足的就散會了，之后各忙各的。兩周后再問進度的時候發現進度遠低于預期……

會議討論的事項想要落實，首先要做的是將會議記錄整理并發布。

1. 整理的內容包含具體事項、交付物、跟進人、執行時間、完成時間等信息。明確了這些事情才變得可跟進。
2. 通知的人員不僅是與會人員，未參會的相關干系人也要通知到。

需求評審不論是否通過都會根據結論進行下一步的安排。評審通過就跟進上線的排期和進度；評審未通過就及時調整并約定下次會議時間。跟進進度的方式可以采用日報、周報、站會、約定時間等多種方式進行。但是千萬不要一直催進度，體現了對對方的不信任，容易讓人反感。

會議中涉及需求文檔的修改點，在調整后及時更新和通知相關人。再視實際情況組織會議討論。需要注意一點——會議中一旦確定的事項，除非有顛覆性的影響因素介入，否則不允許修改。否則會議就變得毫無意義。

以上就是組織一場需求評審會需要注意的事項。希望你能開一個高效、愉快的會議~

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議