需求評審會，雖然是產品經理的演講會、高光時刻，但是更重要的是怎么讓“與會人員”明白我的需求是什么，達成一致意見或知道會后如何修改。

發現問題，刻意練習

我發現近幾個月的需求評審中自己出現的3個比較具體的問題，通過一天觀察導師是怎么高效做需求評審，記錄總結了可以“刻意練習”的要點。

需要提醒自己的是，“刻意練習”是書《優秀到不能被忽視》中明確刻可以成為更好的自己的一種方法，共有5個步驟。其中我認為首要是先找到自己的“對標對象”，即 找到自己需要提高的不同能力的學習對象。

因此我找到了需求評審可以學習的對象，下一步則是“摧毀和拉伸”， 就是承認自己的失敗;突破自己的舒適范圍。“摧毀”自認為優秀的部分，“拉伸”自己離開舒適圈，刻意練習自己不會的但是適用的東西。

“刻意練習”的5個步驟(摘錄自書《優秀到不能被忽視》)

3個問題分別是：

在寫文檔的時候思考的邏輯點，該怎么告訴開發需要這樣做?

會議過程中，先說什么?后說什么?

展示需求文檔時，什么場景下對著文字說?什么場景下對著原型說?

針對這3個問題，我進行了下述要點的刻意練習。

如何告訴開發WHY、WHAT、HOW

1. 評審前

開發同事雖然是幫助產品完成需求，但是也需要通過為什么做和做什么，來判斷該開發工作是否是新增的，開發量是否很大，排期等。這就涉及到產品在開需求評審前，需要提前查看本期backlog中和這個需求相關的，明確本需求是新增的，還是優化的。

如果是新增的需求，直接進入評審中的3個開題環節。

如果是優化的需求，需要先打開backlog說明“本需求是針對上一期需求做的二期、三期優化，其中在這個需求版本中只做二期優化。二期優化的內容有以下這些，分別是xxxxxx”。因此也涉及到填寫backlog的時候，需要清楚詳細寫明需求的名稱，讓開發一眼明確這個需求是做哪塊兒內容。

2. 評審中

打開需求文檔時需要先說明需求類型、背景或現狀、需求的目的。需求背景或現狀也就是在設計這個需求時，自己思考的點。比如最近在設計抽獎活動，需要新增需求目的是在微信環境下完成活動閉環。

為什么要在微信環境下閉環，因為(背景)：“班主任或銷售的宣發渠道普遍是通過微信，家長在看到宣傳海報后，想直接點擊二維碼參加活動”，說清楚什么人在什么時候做什么事情，得到什么結果或遇到什么問題。

因此這個需求，主要是解決xxx問題，這就是需求目的。說完背景和目的后，再接著說需求重點解決的是什么問題、整個流程是怎么樣的，再一個部分一個部分去描述。

如果評審的需求是比較大、內容比較多和復雜的新項目時，在開始講下一個大模塊前，需要對上一個模塊總結。

比如觀察導師做商城需求評審，是總結剛才模塊的整體流程：“剛才說的基本是從商品列表進來，用戶看到詳情頁，點擊后兌換商品，看到兌換明細。那么接下來到了xxx部分。”

需求描述中，先說什么?后說什么?

需求評審會先說需求背景和目的、功能設計，進入到需求描述。本著高效原則，每個需求點只描述重點和難點。

在一個需求點的描述中：

1. 從上到下，從左到右描述

我認為，針對B端工具，從上到下描述，從左到右描述是比較完整的，既可以當做是使用者查看順序來描述，也可以當做是自己在思考時邏輯過程再走一遍，查漏補缺。

比如，最近在設計微信模板消息推送的后臺工具，屬于B端后臺工具。在需求評審時，可以直接打開流程的原型圖，對著原型頁面從上到下，從左到右描述。

上述圖中，可先從上到下，第一部分是信息篩選：可支持篩選xxx數據，點擊查詢的結果展示在下方的表格數據;

第二部分是表格數據，展示的數據項按原型圖順序排列。再從左到右：表格數據中，前兩項是xxxx，中間這幾項是反饋微信推送的結果，最后操作中可支持以下幾種狀態的不同操作，分別是xxxx。

這樣說下來，自己會感覺很清晰，開發也能明白這個頁面需要做什么，不同狀態下可以做什么操作，剩下的內容可請開發自行查閱需求文檔。

2. 從用戶操作路徑描述

針對C端產品，根據用戶操作路徑來描述，會讓整個流程的聽眾也能把自己當做這個產品的用戶一樣去完整體驗一遍這個需求的閉環。因此根據用戶操作路徑來說會比較完整，需要講清楚每個部分之間的聯系，這個聯系通俗來理解，就是下一個頁面是通過上一個頁面的什么操作的來的。例如用戶在商品詳情頁點擊“去購買”，就跳轉到了訂單確認頁。

考慮到C端產品通常會有后臺系統進行配置，所以在需求評審中通常也涉及到前端頁面和后臺頁面的描述。所以我認為在評審中將前端頁面和后臺頁面對應起來描述會更流暢，還是例如用戶進入商品詳情頁，可看到頁面頂部是5張商品圖輪播，商品圖是在后臺的新增列表中可配置，是怎么樣的上傳規則xxxx。

3. 暫無結論的盡量不占用會議時間

雖然需求評審是產品經理的“演講會”，但是也難免會存在開發與產品、開發與開發之間會因技術實現的問題占用較長的時間。除了在前期設計需求時需要主動和開發討論技術實現最優方案，在評審會中也需要把握技術討論的時間。如果不能一下子講清楚或者暫無統一結論的，先不占用會議時間，會后再和開發討論。

和開發討論技術方案實現，我認為千萬不能被開發用產品“聽不懂”的技術帶跑。透過現象看本質，深究影響這個技術實現的業務問題到底是什么，因為產品不一定懂很多技術知識，但是一定是了解業務的。

什么場景下對著文本說?什么場景下對著原型說?

首先需要明確，文本和原型的區別/效果分別是什么?

在我看來，文本是針對邏輯、格式、規則等一些規范性需求要求的詳細闡述。原型是針對操作界面、流程、展示大概的樣式的圖像化呈現，因此需要根據當下講的內容來匹配對應的展示內容(文本or原型)。

例如，近期設計的抽獎活動，在需求評審時，需要闡述用戶可以通過完成什么任務獲得抽獎卡。

一個任務包括：任務名稱、任務時間、任務觸發入口、任務展示、任務狀態等。可以將上述的先分類，任務名稱、時間、入口、展示都是可以通過圖像化形式呈現，任務狀態需要有規則告知什么時候展示什么任務、當用戶完成該任務時任務排序是怎么樣的等等。因此可以在描述用戶可以完成什么任務的時候，對著原型說是合適的;在描述詳細的任務排序規則的時候，對著文本說是合適的。

上述3個問題是我從入職以來到現在，在需求評審會中最常見的，因此通過觀察導師的需求評審總結了一些提高效率的方法，雖然并不是完全我都能立刻掌握，但仍在“刻意練習”的過程中。如何在需求評審中讓開發能更快、更清晰、更準確明白產品的需求，也是鍛煉產品經理“同理心”(換位思考)的技能。