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

發(fā)現(xiàn)問題，刻意練習(xí)

我發(fā)現(xiàn)近幾個月的需求評審中自己出現(xiàn)的3個比較具體的問題，通過一天觀察導(dǎo)師是怎么高效做需求評審，記錄總結(jié)了可以“刻意練習(xí)”的要點。

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

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

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

3個問題分別是：

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

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

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

針對這3個問題，我進(jìn)行了下述要點的刻意練習(xí)。

如何告訴開發(fā)WHY、WHAT、HOW

1. 評審前

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

如果是新增的需求，直接進(jìn)入評審中的3個開題環(huán)節(jié)。

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

2. 評審中

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

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

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

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

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

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

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

在一個需求點的描述中：

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

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

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

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

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

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

2. 從用戶操作路徑描述

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

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

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

雖然需求評審是產(chǎn)品經(jīng)理的“演講會”，但是也難免會存在開發(fā)與產(chǎn)品、開發(fā)與開發(fā)之間會因技術(shù)實現(xiàn)的問題占用較長的時間。除了在前期設(shè)計需求時需要主動和開發(fā)討論技術(shù)實現(xiàn)最優(yōu)方案，在評審會中也需要把握技術(shù)討論的時間。如果不能一下子講清楚或者暫無統(tǒng)一結(jié)論的，先不占用會議時間，會后再和開發(fā)討論。

和開發(fā)討論技術(shù)方案實現(xiàn)，我認(rèn)為千萬不能被開發(fā)用產(chǎn)品“聽不懂”的技術(shù)帶跑。透過現(xiàn)象看本質(zhì)，深究影響這個技術(shù)實現(xiàn)的業(yè)務(wù)問題到底是什么，因為產(chǎn)品不一定懂很多技術(shù)知識，但是一定是了解業(yè)務(wù)的。

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

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

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

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

一個任務(wù)包括：任務(wù)名稱、任務(wù)時間、任務(wù)觸發(fā)入口、任務(wù)展示、任務(wù)狀態(tài)等?？梢詫⑸鲜龅南确诸悾蝿?wù)名稱、時間、入口、展示都是可以通過圖像化形式呈現(xiàn)，任務(wù)狀態(tài)需要有規(guī)則告知什么時候展示什么任務(wù)、當(dāng)用戶完成該任務(wù)時任務(wù)排序是怎么樣的等等。因此可以在描述用戶可以完成什么任務(wù)的時候，對著原型說是合適的;在描述詳細(xì)的任務(wù)排序規(guī)則的時候，對著文本說是合適的。

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