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

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

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

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

一、請正視需求評審

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

評審會議需要完成3個小任務(wù)：

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

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

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

二、會前：準(zhǔn)備你的武器

相信大家都有組織過會議的經(jīng)驗，會前準(zhǔn)備工作并不復(fù)雜，但是隨著會議涉及的部門和人員增多，會前協(xié)調(diào)工作就顯得十分重要。

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

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

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

如果人品值的分?jǐn)?shù)過低，影響的不僅是會議組織，其他工作也很難在團(tuán)隊內(nèi)開展。

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

人員和時間是會議的基本要素，只有確認(rèn)好后才能發(fā)出會議邀請。

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

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

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

會議通知前，產(chǎn)品經(jīng)理先和核心干系人溝通需求評審的事項（如研發(fā)對接人），提前消滅大問題，避免會上出現(xiàn)重大事故。

三、會中：注意控制場面

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

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

1. 圍繞主題討論

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

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

順序參考：需求背景 、方案概述、收益和風(fēng)險、用戶與需求、產(chǎn)品框架、功能模塊、操作流程、原型交互、數(shù)據(jù)指標(biāo)、所需支持、預(yù)期上線時間。

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

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

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

四、會后：跟進(jìn)跟進(jìn)跟進(jìn)

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

某次需求評審會，經(jīng)過會上激烈的討論確認(rèn)了解決方案調(diào)整項若干和待辦事項若干，并且會上指定了對應(yīng)任務(wù)的負(fù)責(zé)人，然后大家心滿意足的就散會了，之后各忙各的。兩周后再問進(jìn)度的時候發(fā)現(xiàn)進(jìn)度遠(yuǎn)低于預(yù)期……

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

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

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

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

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

本文由 @耳目不染 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議