參考自
要讓相關人員詳細了解需求
知道自己處於什麼位置，要做什麼
評估需求的難度和時長，進行分解和計畫安排
最好是所有干係人
如果不能都到會，也要所有干係負責人到會
如果負責人本人不能到會，需要該負責人的backup到會
前提是開發計畫已經被排期，進入確認階段
在開發計畫開始前3-5天進行評審
分為評審前、評審中、評審後
產品經理必須事先準備好講述需求所需要的物料
主要包括：prd（需求文件）、原型（最好高保真）、ui/ue稿
產品經理在產品需求設計過程中，有必要跟主要的干係人提前溝通
確認可行性，避免閉門造車，有誤區的可以及時更正，不必到最後才發現根本無法實現
也不要凡事都問，容易遭人厭
提前通過郵件等形式吧方案送達相關人手中
盡量爭取提前得到部分反饋，以及時修改
同樣是為了避免問題堆積到最後才發現
本次評審的背景是什麼，為了實現什麼目標
可能要多久，讓大家有個心理準備
我們本次產品是為誰做的、是要做什麼內容、為什麼要這麼做，等等
是進入評審前的介紹，避免與會者聽產品演示時一臉懵
進入正式的需求講解了
在正常講解的過程中，避免急躁求成，要聽取各方意見
有問題出現時，要了解問題關鍵，如果是難以實現，要考慮成本和收益對比
切忌拍腦袋的想法，要用邏輯或資料說服對方，如果還沒有想清楚，可以說會後再捋清楚
如果出現爭執，不要一直處在爭執的狀態，控制情緒，以免浪費評審時間
要留有faq環節
要明確本次評審會的目的，是為了得到問題反饋和排期
要提出時一定要提出，不能畏縮
可能排期不能馬上得到，但會中也要收集到一些資訊，以便會後進一步安排和協調
根據在會中收集到的反饋和問題修改方案，上傳到jira/wiki
會後要做會議紀要，記錄會議的成果備忘，和給老闆匯報用
會中向與會者提出的問題，需要適時去收集反饋，以調整方案和後續安排
如何開測試評審會
一.測試 評審會背景 目前，開發有需求說明會 設計評審會 複審會等各種會議，但多是站在開發的角度，從需求和 層面進行複審和風險規避。在測試環節和測試階段缺少以測試為主體的評審機制和溝通機制，容易造成以下幾方面的問題 1.由於文件的質量良莠不齊，以及書面語言的侷限性，僅從文件獲取資訊，可能會造成資訊不...
需求評審會
大多數從事軟體開發的人士都有這樣的體會，需求分析是乙個軟體成功與否的關鍵。在當今軟體工程領域出現的許多問題，都源於需求的不清晰。正因為如此，我們現在面臨的客戶，我們的專案經理自身，以及我們的管理層已經開始嚴控需求。我們不僅定製了需求提交的流程，還定製了需求說明的格式。但在實際操作過程中，通常是大家先...
需求評審會議如何召開
需求評審會議如何召開 需求評審會的目的，是為了讓相關人員，對產品的需求方案達成共識，讓boss提前知道完成專案所需的資源投入等等 由於相關人員較多，需要討論的問題也較多，所以會前對會議的全面準備，反覆預演練，是乙個產品對於每個需求評審會，都一定要做到的 1.評審會前 會前較為必要的是複雜問題或容易有...