需求評審會議對整個項目想影響至關重要，作為產品經理，我們應該本著對項目和研發團隊負責的態度，認真準備，以提高需求評審會議的效率。

準備不充分的需求評審會議，是一個事故現場

主持會議是產品經理的日常工作，尤其是需求評審會議。如果沒有為需求評審會議做充足的準備，會議現場往往會變成“事故現場”。

曾經參加過一個同事的需求評審會議。需求是根據用戶最近4個月的月交易額，分析用戶的經營情況。產品的方案是：將最近4個月的交易額的值線性回歸為一條直線，再根據這條直線分析用戶的交易額趨勢是在增長還是在減少。

研發人員非常不認同這個產品方案，有的甚至表示聽不懂。會議現場爭執不斷，最后需求被拒絕。

為什么一個需求評審會議，會變成事故現場？

一個最重要的原因是：產品經理沒有為會議做充足的準備。

為什么要充分準備需求評審會議？

高效傳遞需求

一場高效的需求評審會議，可以在有限的會議時間內，向研發人員清楚地說明我們要做什么、為什么要做，以及如何做。這不僅要求我們對產品方案有清晰、深度的理解，還要提前預測參會人員的關注點，并找到對應的解決方案。

根據信息傳遞漏斗效應：信息的傳遞過程中，會逐步出現衰減。我們想表達的內容是100%，表達出來的可能只有80%，聽眾聽到的只有60%，但由于各種原因，聽眾真正理解了的信息可能只剩下30%。

要想提高聽眾最后理解到的信息比例，我們就必須要深度理解我們要表達的信息，并找到合適的方式把它們表達出來。

對產品方案有清晰、深度的理解，僅僅靠編寫需求文檔是遠遠不夠的。還需要我們仔細去思考每一個流程、邏輯、細節，提煉其中的關鍵信息，找到最佳的需求表達方式。這就需要我們充分準備。

提高產品方案的合理性

需求評審時，被研發質疑產品方案不合理，是我們大部分產品經理都會遇到的問題。一個產品方案，在沒有與研發溝通前，是否存在的問題，我們可能是無法預知的。

我們在需求評審前，應該與核心研發就產品方案以下4個方面展開詳細的討論：

1. 核心的業務流程：業務最基本的底層流程；
2. 涉及到的功能模塊：需求包含的、以及相關聯的功能模塊；
3. 關鍵邏輯：對整體業務影響很大的重要邏輯；
4. 不確定的細節：產品經理無法確認是否合理的需求細節。

充分吸取核心研發的建議和意見，形成的產品方案，一定會更具有可行性，實現的成本也可能會更低。

當然，提前溝通也沒辦法完全消除研發對產品方案的質疑。但如果我們提前溝通，帶著更合理的產品方案做需求評審，研發的質疑一定會更少。

如何充分準備需求評審會議？

讓核心研發參與方案設計，并達成一致

同一個需求，我們往往能想到多個產品方案。有時候我們自己也不能確定哪一個方案會更好。

此時，我們可以把這幾個方案都跟核心研發講一遍，征求下他們的意見。他們就能從研發成本、復雜性、可擴展性等多個維度對幾個方案進行優缺點分析，最后幫助我們選擇一個最合適的方案。

1. 有些方案很簡單，研發成本很低，但往往只能解決用戶最核心的需求；
2. 有些方案很復雜，能覆蓋的用戶場景更多，但研發成本很高；
3. 有些方案不利于后期擴展，但能快速上線；
4. 有些方案擴展性很強，但做起來很麻煩。

如果我們有自己強烈的選擇傾向，但核心研發并不認同。我們就要非常有耐心地去解釋：選擇這個方案最重要的原因是什么？為什么其他的方案不夠好？從長遠來看這個方案有多大的優勢？

如果能取得核心研發的理解和認同，我們在需求評審時，遇到的阻力就會小很多。即便其他的研發人員不同意，核心研發也會幫助我們說服他們。

核心研發的專業能力，能幫助我們權衡多方面的因素，找到并選擇最合適的一個方案。而他們同時還是研發團隊的權威，能對其他的研發產生很大的影響力。

提高需求文檔的可讀性

如果我們把需求文檔當做一個產品來設計，目標用戶就是研發人員。那么需求文檔的高可讀性，就是用戶體驗的核心指標。

要提高需求文檔的可讀性，我們需要將閱讀效率低下的需求描述方式替換為更清晰易懂的描述方式。

a. 將長段落換成結構化的多個段落

長段落就是一種閱讀效率低下的描述方式。如果我們改用結構化的多個段落，閱讀效率和體驗就會高很多。

一大段長句：由于用戶需要通過結算時間來查詢訂單信息，所以要在列表的最后一列后增加結算時間列并做為查詢條件，結算時間顯示精確到秒。

換成結構化的文字：需求背景：用戶需要通過結算時間來查詢訂單信息；

解決方案：

1. 在列表的最后一列增加“結算時間”列；
2. 結算時間顯示精確到秒；
3. 查詢條件新增“結算時間”，查日期區間。

b. 將復雜流程拆分成主流程和多個子流程

復雜業務往往伴隨著復雜的流程。如果我們在一個流程圖中，將所有的細節都囊括進去，研發理解起來肯定會非常困難。

這時候，我們應該從復雜的詳細流程中，先抽象出多個核心節點，繪制成一個相對簡單的主流程圖。再將每個核心節點的細節展開，分別繪制成多個子流程圖。

在需求講解時，先講主流程。確認大家都理解后，再將核心節點展開，分別講詳細的子流程。

通過這種方式，研發就能形成“總-分”的邏輯結構，理解起來會更輕松、更高效。

c. 補充功能結構圖、信息結構圖、狀態流轉圖

這3種圖并不是需求文檔所必須的。但如果我們的需求文檔中有，需求表達的效率會更高。

前面幾篇文章有詳細介紹，此處就不再贅述他們的優點及繪制方法了。

對需求做優先級排序

對于一個復雜的項目，我們應該列一個需求清單，并用kano模型對每一個需求分析，確認優先級。

在需求評審前，對優先級高的需求做更細致的準備：

1. 按上文的方法，讓需求的可讀性更高；
2. 確認該需求對其他模塊是否有影響，并給出對應的解決方案；
3. 窮舉異常情況，并給出對應解決方案。

提前確認好需求優先級，會讓我們在面臨研發“砍需求”時，更從容、更有底氣。

預測研發可能會提出的問題

需求評審時，研發人員會提出各種各樣的問題。如果我們能在會前就預測研發可能會提出的問題，并有針對性得想好回復方式。在需求評審時，就能游刃有余地應對，快速消除研發人員的疑慮。

研發提出的問題，大多圍繞以下幾個點：

1. 異常邏輯：用戶輸入無效信息要怎么提示？必填項不填要怎么處理？上傳過程重突然斷網怎么辦？
2. 交互設計：這個交互設計似乎不符合iOS交互規范？不用彈窗行不行？一個操作要經過5個頁面，能不能設計的更簡便些？
3. 技術實現復雜度：數據每天凌晨更新一次行不行？一定要做到實時更新嗎？能不能換種更簡單的方案？
4. 目標達成度：你這個方案沒解決XX問題吧？這個方案為什么能提高用戶的付款率？

如果我們完全不為可能的提問做準備，在需求評審會議中，我們很難在短時間內想到一個合適、準確的答案。這不僅不能高效傳遞需求，還會損害研發對產品經理的信任度。

其他準備

還有一些看起來很簡單，但很容易被我們忽略的準備工作：

1. 請研發人員提前瀏覽需求文檔：在需求評審前，就讓開發提前瀏覽，大致了解需求；
2. 提前準備好會議用具：在會議正式開始前，就要進入會議室，調試好投影儀、打開需求文檔，確保參會人員到齊立即就可以開始，而不是浪費大家的時間看我們準備。

總之，時間對每個人來說，都是很寶貴的。我們應該使用各種方法，提升需求評審會議效率。

總結

需求評審會議對整個項目想影響至關重要，作為產品經理，我們應該本著對項目和研發團隊負責的態度，認真準備，以提高需求評審會議的效率。

本文由 @誓博 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。