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

很多產品經理談到需求評審可能都聞風色變，因為總是被虐的不要不要的，就像荒野獵人里被熊虐的小李子；但是，依然有那么些產品經理對需求評審會情有獨鐘，難得有個機會和各路大俠比試切磋，享受這舌戰群雄的快感。前方高能預警，文章稍長，建議產品新人耐心認真讀完，高手求拍磚或自行閉目，阿門~

什么是需求評審？

需求評審是產品進入正式開發之前非常重要的一環，只有所有人都認為需求已經沒有什么可挑剔了評審才能通過，所以需求評審也是一個“雞蛋里挑骨頭”的過程。產品經理在這場「辯論」過程中，需要不斷有效的展示自己的觀點，以便獲得更多的認可，最終號召大家（樂意）一起往一個產品目標努力奮斗。

為什么要需求評審？

• 讓與會者清晰的了解需求是什么，需求從哪里來，對現有業務有什么影響，預期收益是什么；
• 讓技術及測試對產品方案有詳細的了解，以便后續開發更高效，沒有誰愿意在后續的編寫測試用例及開發階段再去反復溝通確認，畢竟那是非常低效的做法，當然，特殊情況除外；
• 讓與會者清晰的知道自己在整個方案落地過程中處于什么位置，職責是什么，需要做什么，準備什么，提供什么幫助，對各自負責部分的實現難度及排期有一定的心理預期；
• 評估產品方案的技術難度及實現周期，一期實現，還是分期實現，投入產出比怎么樣？畢竟互聯網產品講究小步快跑，快速驗證迭代，怎么樣權衡產品設計（用戶體驗），技術成本以及商業利益是產品經理主要工作之一。

和誰進行需求評審？

一面視需求大小來看，如果僅僅是一個迭代需求，比如增加一個廣告投放類型，那么可能只要前端技術、廣告系統技術、測試（前端測試+廣告系統測試），三五人隨便找個地兒快速就搞定了；如果是一個中大型需求，比如收銀臺改版，那么涉及到的與會者可能就比較多，然而除了技術、架構、測試以外，往往UE/UI經常被產品經理忽略，盡管UE/UI內部可能有自己的評審（視公司不同情況不一樣，有些小公司是不存在設計評審），但技術評估環節往往會涉及到一些交互和設計的實現需要溝通確認；然而，往往這樣的大型項目一次需求評審基本是搞不定的。

一面視公司項目流程來看，大公司和小公司項目流程有時差異比較大，大公司分工細，并行項目多，盡管涉及的干系人較多，但是可能僅僅來那么幾個主要干系人；而小公司因為項目比較聚焦，講究執行力，反而比較容易召集所有干系人參加。

不管哪種情況，產品經理務必保證核心負責人到場，個別干系人可私下再溝通；很多產品經理可能會認為召集評審會議主要是項目經理的工作，產品經理只需要參會把產品方案邏輯說清楚就可以，如果你也是那么認為，那后面的內容就不必繼續往下看了，你倒不如省點時間多去解幾個bug。

什么時間進行需求評審？

根據項目迭代周期來靈活調整，一般是在確定下個版本迭代需求list之后（當然，要保證需求已排期），開發正式開工之前，建議選擇開發開工前3-5天，主要因為：

• 就算一次評審通過，會后也有些細節需要完善補充，溝通確認；
• 中間間隔太久，很可能等到開發的時候，很多技術實現細節會遺忘，因為并行項目較多，這是難免的事兒；
• 運氣不好的話，有可能遇到開發及測試人員調整；
• 很可能需要進行二次甚至三次評審
• 對需求評審有了初步了解之后，把需求評審拆分為評審前、評審中、評審后三個階段，這三個階段產品經理究竟要做些什么。

評審前

1. 保證物料齊全

產品需求文案（PRD）

怎么樣寫PRD，請自行谷歌，如果需要顯得專業一點，那么可以按照標準格式來，而陰陽建議是，產品經理只要能把邏輯表達清楚，細節描述清晰，技術及測試人員都能看的懂，那就夠了，無需局限于到底是用word格式，還是PDF或者axure格式。

UE稿

按照普遍大公司的流程，產品經理在這個環節只需要把產品的邏輯描述清楚以及大致的想法和UE溝通清楚即可，接下來就交給UE；這樣做也沒有什么大問題，畢竟流程在那，但是這樣做可能會有什么狀況發生呢？

UE并不是時刻為某個產品經理待命的，很可能并行其他項目，也就是說，很可能UE排期趕不上需求評審；

產品經理有自己的想法，但僅僅停留在自己腦子里，與UE溝通清楚想法后，可能UE做出來的東西不是產品經理想要的，然后開始二輪三輪的返工，撕B大戰一觸即發，嚴重影響效率；

難道產品經理真的只局限于寫文檔嗎？產品經理可是要能做的了市場、玩得起運營、與交互遨游、與設計創想的呀。

所以，產品經理應該養成好的習慣，特別是當產品經理還處于初期階段的時候，自己畫原型（請畫高保真原型），自己寫交互，一開始能寫到什么程度是什么程度，但是請盡自己最大的努力做到最好，保持與交互之間的溝通；產品經理切勿把這些所有工作都推給交互，更不要等用戶說產品的交互一坨屎的時候把責任撇的一干二凈；不要給自己找借口說沒有時間，時間就像胸部，擠擠一定會有的。

再試想另一個場景，當產品經理一手拿著線框圖，一手拿著高保真原型（其他內容一致的情況下）去和老大聊需求過方案，請相信高保真原型方案肯定更加容易戳中對方G點并通過，同理，需求評審也一樣。不信？你試試！

UI稿

需求評審時不一定要UI稿，因為很可能需求會變更調整，但是，心里應該要有大致的風格預期，因為產品想透露出什么樣的氣質只有產品經理最清楚，這也是前面提到要做高保真原型的好處之一，鍛煉自己的配色能力；如果有條件，待UI稿輸出后，可以召集執行技術一起再看下UI流程圖（即把UI稿貼到交互流程圖上，嗯，陰陽以前就是那么做的….）

2. 提前小范圍溝通

普遍的產品經理都有一個奇怪的心里，即總是默默的準備產品方案，不愿意去和別人溝通交流，要么覺得丟人沒自信，被人家挑戰之后覺得很沒面子，自尊心受打擊，要么就是覺得自己很牛B，不需要別人幫助，自己做的就是最好的（好吧，這叫做閉門造車）。

當然，也不提倡凡事都找別人溝通，大聊特聊，每天沉醉于自己多么能侃；產品經理務必要有獨立思考的能力，可以在適當的時候與技術溝通溝通方案可行性，聊聊實現難度，方案靠不靠譜，有沒有什么歷史原因以防踩坑；可以和交互聊聊怎么樣才能讓用戶在使用產品的時候不用思考，不用等待，不用懷疑，找到最優交互路徑；可以和設計師聊聊針對這個模塊可能用什么色系會更好，針對不同的地區是不是對顏色有禁忌，聊聊最近流行什么等等；不懂沒關系，抱著誠懇的心態去請教學習，不但可以增長知識，還可以搞好人際關系，又不要花錢，何樂而不為呢。

另外，不要抱著所有事情都堆積至需求評審去溝通解決，已確定的前置需求可提前向相關部門提出來，因為每個部門都可能并行很多項目，沒有人會特意為了你的需求再去配合你的排期（你以為你是誰…找罵）；可以私下主動提前與干系人溝通方案，就方案多磨合幾次，起碼可以讓后續參加需求評審的干系人有個印象，需求評審通過率也會大大提高。

3. 提前把方案發出來

在需求評審的前1-2天可以把產品內部確認好的方案以郵件的形式發出來（可與會議邀請一并發送），請與會者提前查看產品方案并做好問題備注，如果可以，請與會者提前將問題反饋下來，產品經理可提前補充完善，以便后續需求評審高效完成；至于怎么樣使得與會者提前查看方案并反饋問題，一方面與流程制定有關系，一方面就要看產品經理的溝通功力了，不管是請吃飯遞手紙再陪睡。

同樣注意的是，很多產品經理習慣把沒有經過產品內部確認的方案發出來（基本都會有產品內部需求評審，或者一對一確認方案“產品經理VS產品leader”），但是如果方案沒通過的話產品經理在技術大大那的信任積分將直線下降，就算可通過，最好也先在產品內部先溝通確認，多打磨打磨產品細節。

4. 其他事項

召集與會者以及會議室預定；很多與會者可能沒法前來參加需求評審（原因請自行補腦），那么產品經理務必保證核心人員到場，如果核心人員也無法前來，那么請核心人員指定一位backup；產品經理會認為召集會議以及會議室預定都是項目經理的事兒，但陰陽建議產品經理還是多多自己去安排，多的不說，起碼可以多認識幾個人，多刷幾次臉，后續大家還要一起愉快的玩耍呢不是。

提前到達會議室；產品經理可以提前一刻鐘左右去到會議室，檢查檢查演示設備是否支持及齊全，千萬別等到會議開始后才發現這個沒有那個沒法用，白白耽誤了評審時間。

一言以蔽之：產品經理不要讓自己成為「這件事」的瓶頸。

評審中

經過一番折騰，終于到了激動人心的時刻——需求評審，準備好讓口水沫子來的更猛烈些吧…..

1. 明確會議背景及目的

很多產品經理參加需求評審的時候不管不顧直接進入產品方案的演示，這樣很可能會造成一小部分的與會者一頭霧水，因為有些與會者很可能是原與會者的backup，既然是會議還是可以按照標準的流程來，起碼會議的前幾分鐘可以熱絡一下氣氛，以免大家都冷冰冰的坐在哪。

正式進入方案評審之前，可以先說明本次評審的背景是什么，需要完成哪些事兒，希望達成的目的是什么，評審會分幾個環節，每個環節大致的時間需要多久等等，讓與會者對評審會有一定的心理預期。其實這部分工作可提前在邀請郵件中就體現出來，待正式開始需求評審之前，稍微提一下即可，那樣則可以把更多的時間預留給后面的環節。

2. 切勿立馬進入方案細節

同上，很多產品經理在產品方案演示的環節直接就進入了方案細節，比如這個功能要怎么樣實現，為什么要那樣做，那個交互怎么樣等等，試問，前戲都沒做好，直接開干，對方會爽嗎？產品經理在演示方案的時候可使用6W2H原則（具體請自行谷歌），在詳細介紹產品方案的時候可遵循產品設計的五個層級分析法，即戰略層、范圍層、結構層、框架層、表現層（具體請自行谷歌）

3. 掌控節奏，切勿爭（si）論（B）

產品經理正確的堅持自己的想法很重要，當然前提是“正確的”堅持，經常遇到技術問幾個問題，產品經理不但不思考被提出來的問題，反而固持己見，爭的面紅耳赤，口口聲聲說“我覺得問題啊，用戶一定會那樣的，這樣挺好啊”，此時產品經理在技術面前就是一笨蛋，信任直接受到10000點傷害；正確的姿勢應該是產品經理把問題拆解，要么用嚴謹的邏輯或者數據說服技術，要么就是虛心向技術請教，站在對方的角度去思考這個問題，是不是自己沒有想清楚，不要求及時回答，可以暫時回復對方“這個問題我的確沒有考慮清楚，會后再去思考全面，如果有不懂的地方可能到時還需要請教你，待問題明確后也會同步信息給大家”。

爭論不但無法解決任何問題，還浪費會議時間；人的有效集中精力時間大概在45分鐘左右，所以需求評審會盡量控制在60分鐘以內，當然很多時候都事與愿違，那么產品經理應該盡可能的把前期準備工作做好，不要指望所有事情都在評審會上解決，如果超過60分鐘都解決不了的問題，那么請及時打住，因為在往后也不會有什么實質性的結論，可以考慮私下在小范圍溝通，或者組織二輪評審；

預留FAQ環節，針對FAQ視產品經理掌控能力而論，可以講到哪哪有問題立馬提出來并回答，也可以是先完整介紹某個模塊或者功能后，再請與會者統一提問并解答，以免中間被打斷，導致效率打折。

4. 需要別人給予什么幫助或者反饋

回到前面所說的為什么要開需求評審，當然是要解決某些問題的，所以不要忘記需求評審的目的是什么，該出手時就出手，比如某個功能的實現成本、技術評審排期、指定負責人、UE/UI排期等等，當然這部分工作更多的可能是項目來安排，并且有些排期是沒有辦法及時給出答復的，但是產品經理作為產品的主導者必須知曉該部分信息，以便后續更高效率的協調資源。

5. 其他

關于需求評審會主持人

有些公司是項目來擔當這個角色，有些公司是產品經理來詮釋這個角色，如果不想需求評審會搞得像葬禮一樣嚴肅，這個時候項目經理與產品經理更應該是相互配合的，一唱一和，不但可以更好的掌控會議節奏，還可以調節整個會議的氛圍，千萬不要局限于一定要誰誰誰來，沒意義。

不管是誰來擔當主持人，一定要掌握好會議節奏以及控制好討論氛圍，很多時候與會者提幾個問題，聊著聊著就聊到別的地方去了，越聊越遠，白白浪費時間，所以只要與本次會議無關的話題盡量避免，更不要展開討論，必須及時打住拉回到主題上。

可以提前演練幾遍

需求評審毋庸置疑是一件很鍛煉人的事情，鍛煉溝通能力、掌控力、演講能力、表達敘事的能力等等，所以為了做到更好，學會用做產品的思路去準備需求評審會，產品經理有理由在會議之前先演練幾遍，重復幾次之后，會發現你的溝通能力及敘事能力將大幅度提升。

另外，在整個評審過程，請仔細傾聽每位與會者的問題及反饋，做好備忘，能及時解決的，當下解決即可，不能及時回復的，會后再處理。在該環節末尾，產品經理可以把備忘好的問題整理并復述一遍，以免問題遺漏，起碼在與會者看來，產品經理對每個人的反饋都是非常重視的。

評審后

很多產品經理認為評審后就沒啥事兒了，只要把問題及解決方案補全即可，然而這往往不夠。

• 整理遺留問題，找相關同學溝通解決
• 完善方案，更新產品文檔，上傳至jira/wiki
• 發送會議紀要（不要爭論是項目來做還是產品來做），同步以上信息
• 后續工作計劃，明確責任人及反饋排期

整個過程下來，貌似都是產品經理在嘿咻嘿咻的干活，誰說不是呢，啟蒙老大曾經告訴陰陽“所有錯都是產品經理的錯”，誰說不是呢，但是反過來想，誰說不是產品經理收獲最大呢。

最后，偷偷告訴你個小秘訣，想要需求評審會更高效，開會之前把凳子全部搬走藏好….（噓，千萬別說是我帶壞你~）

作者@陰陽（微信公眾號：pmyinyang），互聯網產品經理，熱愛產品，好奇一切新生事物

本文由 @陰陽 原創發布于人人都是產品經理?，未經許可，禁止轉載。