中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

害怕需求評審的產品經理，該如何跨越這個產品經理的第一關呢？

你害怕需求評審嗎？

我怕過，回想起剛開始做需求評審，仍心有余悸。

就像是一個小孩子，做了一件事，也不知道對錯，周圍有一堆的人旁觀，質疑，指責。常常一句話沒說完，開發就說你這樣設計我很難實現，幾個人嘰嘰喳喳開始吐槽。測試說當出現某種異常的時候，怎么辦，不考慮的嗎？我有時答不上來，越緊張越容易出錯，也就越害怕。

我以為這是我個人原因，本來就害怕當眾講話，更何況是講需求。

直到有一次，一個產品助理問我：我剛轉產品經理，需求評審很緊張，覺得自己很糟糕，感覺你講得很好，有什么方法嗎？

我意識到，需求評審恐怕是大部分產品經理要闖的第一關。

如今，也經歷了幾十上百次的需求評審，已經能夠自如應對了，分享一些技巧給大家，希望能幫助害怕的伙伴們輕松闖過這一關。

平和的心態

為什么要在講技巧前，首先強調心態呢？

我們客觀地分析下，害怕是因為別人在挑刺，而我們希望自己交出的答卷是完美的，當心里預期被現實打臉了，就會很失落。

所以，我們首先要降低自己的心里預期，任何產品經理都有考慮不周的時候，這不是考試，沒有標準答案，也沒有完美。

何況，開發有bug是正常的，測試也有測試用例覆蓋不全的理直氣壯的理由，為什么不準產品經理有錯誤呢？

不要把需求評審看成是一場對產品經理的批判會，也不要覺得這是一個走流程的事情，是別人故意在為難我們，我們在這個會上是有明確任務和目標的：

• 向開發、測試傳達清楚要做的需求，保證大家能配合你實現想要的功能。
• 提前讓大家幫你找出漏洞，減少開發過程可能存在的問題。
• 發現不同角色考慮問題的角度，提高自己的產品設計能力。

我們不妨在需求評審會前多暗示下自己：就算這次評審被批的一無是處，那又怎樣呢，改好了再評一遍就是了。

雖說心態要好，但前期準備也是要做足的，不然被批可不能算是無辜。接下來我用一個積分商城的實例來帶大家走一遍需求評審的流程。

一般來說，大功能的需求評審要經歷2步：

1. 初評：將項目背景，用戶痛點和整體解決方案告訴相關人員，請大家評估方案是否合理。
2. 詳評：將需求細節、重要規則給相關人員講解，讓大家對功能有一個更深入的了解，并解答大家的疑問，讓開發測試能快速上手。

初評技巧

資料準備

既然初評的目的是講清功能目的，看整體方案是否合適，那我們的資料需要包含這幾方面：

這些內容要準備到什么程度呢？

我們來看下積分商城的例子。

項目概要

我們明確積分商城的目的是增強營銷環節，增加客戶粘性，那常見的積分兌換就是電子券和商品，考慮到商品涉及訂單和物流，相對比較復雜，可以先做電子券的兌換，此次需求評審就是針對積分兌換電子券的方案。

流程圖

總業務流程圖

先畫出一個多方角色的完整流程圖，就像是在講述一個完整的故事：商家在后臺創建積分兌換活動，投放到C端積分商城上面，客戶在商城上面找到自己想要兌換的電子券，發起兌換，扣減積分的同時獲得電子券，獲得后可在購物時直接抵扣。

這樣其他相關人員就有一個整體的概念了。這個圖重在理清角色間的使用流程，所以不用畫出創建，兌換時的細節，這2個方面可以另外畫2個分支流程圖來清晰地講述。

分支業務流程圖

比如說積分規則設置的流程圖：活動設置的時候需要考慮兌換價格，總數量，每人兌換上限，上下架等情況。如下面的流程圖就能比較清晰地看出重要的業務規則點。

積分兌換頁面的流程圖也是同理來畫。如果把這2張細節流程圖和整體流程圖畫在一起，會非常復雜，不利于評審時講述，也不利于其他人理解。

可能有人會有這個誤區：流程圖越復雜，產品經理水平越高。其實不是的，產品經理的目的是讓人更容易理解。

結構圖

為什么初評的時候不直接拿著原型圖去講呢？

因為原型圖畫起來比較費時間，萬一方案不合理，改動較大，那豈不是之前畫的原型都需要重畫了嗎？這對于產品經理來說，是性價比非常低的事情。

所以，我們會先理出結構圖來，覆蓋相關的功能點，可能碰到的頁面，頁面里面的關鍵字段和規則。雖然沒有原型圖來的直觀，但大家腦海中對功能的雛形都有了了解，能做出方案的評估，這就達到了我們此次評審的目的了。

比如說這是部分積分商城的結構圖：按照終端-模塊-頁面-字段-規則的層級來梳理。

問題反饋表

這個表主要是用來記錄評審過程中的問題，以及對應給出的解決方案，做到有據可循。相關人員在查看這張表的時候，能夠找到自己提出問題的答案。對于產品經理而言，也便于總結回顧，認知到哪幾個方面還考慮不周，下次能注意陷阱。

怎么講

就按照項目概要-總流程圖-分支流程圖-結構圖的順序來講，從背景到功能，從整體到局部，帶領大家來了解即將要做的事情。

詳評技巧

資料準備

經過了初評的方案確認，就可以開始準備原型圖了，詳評時給出的是一份完整的PRD文檔了，主要包含這幾個方面的內容：

我們可以看到，除了初評包含的內容，還加入了全局說明和原型圖。

全局說明

全局說明主要是針對重要規則、通用規則和一些交互規范的說明。

為什么要把他們單獨拎出來呢？

為了引起大家的高度重視。

就重要規則而言，流程圖和結構圖里面很難寫全面，而原型圖里面散落各頁，容易顧此失彼，整個功能的實現，都是在這些規則的前提下，后面每一頁原型的規則能不能與之相沖突。

通用性規則就不必說了，特別是交互規范，就是為了后面不要重復書寫，節省時間。

比如積分商城的某個全局說明：

原型圖

除了交互規范，前面的步驟都要由產品經理來完成，至于原型圖，有條件的情況下可以交由交互來完成。

原型圖上會包含頁面布局，業務規則標注，交互規則標注，比如說這是積分規則設置的原型圖：

怎么講

既然初評的時候已經講過了項目背景，流程圖和結構圖，那是不是詳評的時候不要講了，直接一頁頁過原型？

不是的。

還是要按照項目概要-總流程圖-分支流程圖-結構圖-全局重要規則-原型圖的順序來講。原因是：

• 聽的人未必是同一撥。初評的時候去的是前后端負責人，設計也不會參加，但詳評的時候有關系的開發都會去，設計也會去。而他們其實之前并不了解需求。
• 就算是同一撥人，隔了幾天去聽，難免就忘了，為了避免講述過程中提出一些很基礎的問題，不妨先做個回顧。
• 初評時肯定是有一些疑問的，先把調整后的完整方案講述一遍，大家先達成基本的共識，后面評審也會更順利一點。

講原型圖的時候要注意這幾點技巧：

• 講業務規則，不要講交互規則。有的產品經理會把規則從頭到尾地念一遍，以為講的很細致，殊不知大家已經過于疲倦，聽不進去了。交互規則對前端有用，但對后端來說，用處不大，沒有必要占用所有人的時間來講，可以私下溝通。
• 講重點業務規則，不要沒有側重。有一些常規的業務規則，比如說限制字段長度，數值范圍，這種即便是講了也記不住，開發的時候看下文檔就行，不需要講解。但像設置積分兌換規則時，選取的電子券不能是運費券，贈品券，這種規則需要重點強調。
• 前后臺聯動來講。比如說講完設置積分規則的頁面，緊接著講C端兌換的頁面，大家就知道設置項對C端的影響在哪里。不要把積分兌換統計，積分訂單等都講完了再去講C端兌換頁面，大家對應不起來前后的字段和規則，會覺得很懵。

應變技巧

評審過程中難免會遇到提問，當然別人的提問不一定是你的設計不合理。

有時是因為別人沒有理解為什么要這么做。這種情況下，最好的方式就是從用戶實際場景出發，來講述你這么設計的理由和依據。

有時是別人提出了一個更好的解決方式，確實毫無疑問的比你的方式更加合理，那就記下來，會后優化需求。

有時確實是令我們害怕的情況發生了，別人赤裸裸的指出了邏輯漏洞，我們在沒有想清楚之前，不要去回答，記錄下問題，會后想清楚，或者和開發溝通后再給出解決方案。切勿在會上花費過長的時間去爭論，甚至偏離主題。

記住這句萬能的話：你說的我記下來了，我會后再考慮一下，給出答復，到時會以郵件形式通知大家，時間有限，會上先不討論了，我們繼續吧。

提高技巧

經驗越來越多以后，我們會前可以試想一下，不同角色的人可能會提出什么樣的問題，我們要怎么回答。這也是給自己查漏補缺的機會。

比如說開發，非常關注這個功能能不能實現，更確切的說，是容易地實現。如果我們把兌換規則設置放在電子券模塊，開發會覺得這兩者耦合太大，不利于后期的維護，更希望做成一個獨立的活動設置模塊。那我們就可以往這方面去考慮。

測試更關心反例，我們需要去排查，每一步可能會遇到什么異常情況，遇到了要怎樣去處理：提示什么？以什么樣的形式去提示？提示后怎么辦？比如說兌換電子券的時候，數量不足了，提示該電子券已搶光，并推薦他兌換其他的電子券。

總結

細細想來，跟著初評、詳評，這樣一步步地準備、評審，也沒有什么可怕的。

需求評審會是產品經理主導的會議，需要由產品經理來掌控節奏，遇到一時解決不了的問題，會后去考慮，會上先把自己的產品方案傳達清楚。這樣就不會發生混亂、多人指責、吐槽的場景了。

恭喜你，過了這一關，就可以送口氣了，開發過程中的問題都是逐個浮出水面，各個擊破的，不會有這么大的精神壓力了。

作者：司馬特小隊，丁香園高級產品經理。微信公眾號：司馬特小分隊

本文由 @司馬特小隊 原創發布于人人都是產品經理，未經許可，禁止轉載。

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