需求評審會保命指南(答應我要做到好嗎)
筆者對評審會也有僧僧的恐懼,灰常怕怕!!畢竟小白,會議室坐滿了大佬,很怕自己表現得差差!!!最怕對面扔一波問題腦子就短路,滿屏彈幕就是:??納尼??這….asoqehg$^##555555,然後out,最慘的就是被情緒牽著鼻子走,痛定思痛碼字總結乾貨。
一、會前的干係人溝通 跟項目需求方充分溝通:功能實現的場景、想要達到的目標(數據量化)、 方案是否能夠滿足需求方的應用場景,業務干係人從功能必要性說服開發人員說服開發人員二、充分準備、避免緊張 需求自查(開發可能會提出的問題?ps:我也不知道哇…但我可以學…)
組內評審(複查遺漏的問題)
三、需求評審三大件1.(Excel)功能清單:功能描述(每一個對應功能寫清楚一級功能、二級功能、三級功能….)-----主要用於說明資料庫表 模塊一|功能屬性、使用流程、信息、後台邏輯 模塊二|
..
.
模塊n
2.流程圖------封閉、節點清晰(明確流程關係)3.原型圖-------幫助UI理解界面實現效果(圖片格式、排列順序、文本框限長、默認值等)四、組織會議(提前先線上或者當面溝通,說明需求背景,給出調研或者數據分析文檔(拿數據說話!這很重要!)提前一天發出會議邀請)
1.協調時間 這個問題很無解….都是大佬怎麼協調時間…所以還是掌握主動權先暫後奏定個可協調的時間區間!再溝通調整~
(話術:我們準備在xxx時間評估xxx,你參加一下或者你安排人參加一下吧)2.郵件寫清楚會議議題《x功能的第一次評審》3.定好議程每個功能明確需求和達成時間deadline4.參與人員(某協作方無法參與的情況下,可要求指派別的同事代為參與)5.準備會議材料:功能清單、流程圖、原型圖
Word轉成pdf、原型圖轉成網頁版、Excel凍結首行、路程圖轉化為pdf文件命名有講究:項目名-功能名-作者-時間-版本-檢索關鍵詞
6.參會前強調參會人員提前閱讀以上材料,可以提醒對方提前準備意見(這條可以保命)
五、會議進行
參考*羅伯特議事規則
*金字塔原理表達順序:重要的事、概括性的事
表達需求順序:背景、結論、操作方法 話術:歡迎大家來到….功能的需求評審會,今天主要是為了解決x的需求,主要是解決
1…..2……3…..問題,會議想要得出的結論是評審意見or項目計劃。 我們要討論的問題點是1……2……3…..我的設計思路、設計框架是怎麼樣的, (講問題)因為有怎樣的問題,(講清楚目標)我們需要……我的功能使用步驟: 用戶創建賬號 與角色做關聯 需要具備某許可權..
>完美END注意事項:1.有根據有邏輯回應對方提出的具體質疑,對事不對人2.防止會議主題走偏、防止人身攻擊、防止糾纏細節(非框架性的問題不要過多討論)
3.注意記錄會議記錄(結論性的東西)
記錄這些東西:某個想法->得出的意見,注意模塊討論完之後復盤總結一遍決議討論的結果 記錄後形成文檔
六、會議後1.發出會議紀要 (時間、地點、參會人員、缺席人員、議題、議程、決議、待解決的問題)2.郵件發出(記得抄送參會人的leader)
推薦閱讀:
※快速提升軟體開發指標產品經理要做好版本規劃
※連線題:遊戲中心怎麼做社交?
※PRD文檔究竟該怎麼寫,你寫的有可能是錯的
※發掘用戶真實需求,產品經理如何提升產品的可用性