大家參與過最多的會議，莫過于需求評審會了。作為產(chǎn)品經(jīng)理，沒有幾個能真正完好地從需求評審中走出。這篇文章，作者就教你如何“完好”地從需求評審走出來，希望能有用。

需求評審是每個產(chǎn)品經(jīng)理都需要修煉的技能，只要工作還在進行、業(yè)務還在繼續(xù)、需求還沒消失，那就一定會存在需求評審。

在需求評審會議上，前端、后端、測試、設(shè)計、業(yè)務負責人甚至你的老板可能都會過來，不同的角色聚在一起，聽產(chǎn)品經(jīng)理講需求內(nèi)容。這不是一件容易的事情，因為你需要經(jīng)得起各個角色對你的產(chǎn)品設(shè)計的質(zhì)疑或挑戰(zhàn)，怎么“完好”的從需求評審走出來，對每一個產(chǎn)品經(jīng)理來說，都需要去仔細琢磨，也是必須得掌握的基本功。

一、需求評審會前準備

進行需求評審前，有幾個動作是需要做的：

1. 需求評審需要用到的資料，包括但不限于：PRD、原型、流程圖、設(shè)計稿、相關(guān)資料文檔、需求時間計劃等。
2. 需求評審干系人：確定需要參與會議的人員，例如，業(yè)務對接人、前端、后端、測試、設(shè)計等。特別是業(yè)務對接人，參與會議可以讓業(yè)務更了解他們提出的需求是怎么被實現(xiàn)的，提交給到開發(fā)其實需要需求描述到什么程度；另一方面，技術(shù)也可以通過業(yè)務對接人了解到更多業(yè)務場景，對需求實現(xiàn)有更深的理解。確保干系人都參與到會議，避免需求評審時相關(guān)人員不知情導致需要再次溝通或者需求實現(xiàn)偏移。
3. 需求評審時間地點：因為涉及到的與會人員多，所以需要溝通好會議時間地點，如果是常規(guī)迭代，最好是約定一個相對固定的時間，例如每周幾或者每月幾號這樣，讓團隊人員避開會議時間安排其他會議。通知方式根據(jù)實際公司情況而定，例如郵件、微信群、企業(yè)微信、釘釘、內(nèi)部通訊工具等。像釘釘、企微這種協(xié)同辦公軟件有會議通知提醒功能，能更好的提醒到與會人員。

二、需求評審會中

作為需求評審會的主持人，第一，要清晰明確產(chǎn)品需求講解；第二，要把控整個會議的節(jié)奏。

需求評審需要大家達成共識并按照產(chǎn)品設(shè)計的實現(xiàn)它，簡單來說就是明確：價值、功能、實現(xiàn)。

• 價值（背景/目的）：為什么要做這個需求，上線之后的價值是什么。
• 功能（涉及產(chǎn)品、端、功能模塊）：為了這個價值，需求包含了哪些功能。
• 實現(xiàn)：針對每一個功能，應該怎么實現(xiàn)。

例如需求為：運營部門需要發(fā)布促銷活動在網(wǎng)站上客戶可選擇促銷活動下單。

第一步：產(chǎn)品經(jīng)理在進行需求評審時，就需要把這個需求的價值（或背景目的）先說明清楚，即本次需求的目的是促使客戶下單，提高銷售效率。

這一步其實很重要，很多時候，技術(shù)對產(chǎn)品的不信任在于覺得產(chǎn)品提出的需求可能是偽需求，并非業(yè)務關(guān)注的，所以有必要在評審會上說明每個需求的來源和價值，證明我們是想清楚了才這樣設(shè)計功能的。

第二步：把需求價值同步后，就需要說明功能。

可先講解需求的業(yè)務流程，讓參與會議的人知道功能涉及哪些角色、哪些系統(tǒng)、數(shù)據(jù)流是怎樣的，做的心里有底，這個需求的范圍大小。然后，講解涉及到的單據(jù)狀態(tài)是怎么流向的。如果是復雜的功能，還需要有相關(guān)的表關(guān)系圖輔助技術(shù)理解。

這一步的重點在于，需要大家對流程先達成共識，如果大家對流程有疑問，需要及時溝通，否則后續(xù)說明實現(xiàn)時就會一團亂。

第三步：功能具體是如何實現(xiàn)的。這里可以根據(jù)個人習慣進行講解，這里介紹的是我自己的講解習慣，僅供參考。

流程+模塊

說實話，對著PRD或者原型講解，很容易走神，不知道講到哪里了，效果不佳，還容易被技術(shù)吐槽。

所以我采用的是流程+模塊的方式進行講解。在上一步，我們已經(jīng)將流程說明了，也共識了流程，那我接下來的功能實現(xiàn)就是按照流程一步一步講解。

例如：發(fā)布促銷活動先進入促銷管理的頁面，進行新建促銷活動。那第一個節(jié)點模塊就是促銷管理的入口-》到進入促銷管理模塊中的促銷列表頁-》新增頁面-》編輯頁面-》詳情頁面的順序來講解實現(xiàn)。

• 在講解實現(xiàn)過程中，與會人員會對剛剛的產(chǎn)品設(shè)計進行提問，甚至是多個不同角色針對不同方面進行提問。能提問是好事，證明大家是認真聽了并思考了，通常我在講解完模塊實現(xiàn)后都會問一句：有沒有問題？沒有我們繼續(xù)。以此來保證大家進度。
• 但我們開會的時間是有限的，就需要判斷哪些問題需要當場解決，哪些問題可會后補充。個人建議，如果存在以下條件的，就應該當場解決，也因干系人都在，這時候解決效率最高：
  1. 關(guān)于項目價值目的，為什么要這樣做。例如：促銷活動詳情為什么還需要查看關(guān)聯(lián)的訂單情況？因為做促銷活動的目的就是反應在最后的下單情況上。
  2. 關(guān)于業(yè)務流程/邏輯完整性，這個問題不解決，業(yè)務進行不下去。例如：業(yè)務需要發(fā)布了活動才生效還是設(shè)置的開始時間到了自動生效。
  3. 影響到其他系統(tǒng)或功能模塊的。
• 而那些不影響主流程功能問題，比如前端細節(jié)，交互細節(jié)，后端邏輯細節(jié)，或者是你還不確定的點，如果會上不能快遞確定解決的，身為會議主持人，應該把控時間節(jié)奏，在PRD文檔上標注即可，會后溝通確認。

需求評審會議時長最后把控在1小時內(nèi)，因為時間長了，我們的精力和注意力都會打折扣，想象一下一群人在會議室超過1個小時，里面的二氧化碳濃度也讓你渾渾噩噩，俗稱缺氧。

需求評審的目的：需求評審不是解決所有的問題，而是在會議時間里解決最重要的問題。檢驗需求的合理性和完整性，降低需求風險，確保項目目標和需求之間的一致性，便于團隊成員理解工作任務。

做到這一步，其實已經(jīng)可以卸下大半的壓力，離“完好”走出還差最后一步。

第四步：需求時間計劃同步

在完成需求實現(xiàn)說明后，大家最關(guān)心的就是什么時候需要完成開發(fā)、提交驗收、上線等。因為這關(guān)乎工作量的評估和時間的緊迫性。

這時候，如果是新功能或者關(guān)鍵功能重構(gòu)優(yōu)化，建議技術(shù)部門提供技術(shù)方案，以此完善整個需求文檔，同時驗證產(chǎn)品設(shè)計是否有技術(shù)實現(xiàn)的問題。

三、需求評審會后跟進

會議結(jié)束后，當我們“完好”走出需求評審會，其實還需要對會議記錄進行整理，更新需求文檔，并通知相關(guān)團隊成員，才算真正的結(jié)算。

四、總結(jié)

通過需求評審，可以對產(chǎn)品需求進行全方位的論證，驗證或更改原有想法，獲取更多的想法，從而完善產(chǎn)品需求。

所以說，雖然在需求評審會上產(chǎn)品經(jīng)理看似單兵作戰(zhàn)，其實我們跟會議上的人是合作關(guān)系，相互補充，為了讓產(chǎn)品需求更合理更明確。切勿有個人情緒，應當對事不對人。