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

大家參與過最多的會議，莫過于需求評審會了。作為產品經理，沒有幾個能真正完好地從需求評審中走出。這篇文章，作者就教你如何“完好”地從需求評審走出來，希望能有用。

需求評審是每個產品經理都需要修煉的技能，只要工作還在進行、業務還在繼續、需求還沒消失，那就一定會存在需求評審。

在需求評審會議上，前端、后端、測試、設計、業務負責人甚至你的老板可能都會過來，不同的角色聚在一起，聽產品經理講需求內容。這不是一件容易的事情，因為你需要經得起各個角色對你的產品設計的質疑或挑戰，怎么“完好”的從需求評審走出來，對每一個產品經理來說，都需要去仔細琢磨，也是必須得掌握的基本功。

一、需求評審會前準備

進行需求評審前，有幾個動作是需要做的：

1. 需求評審需要用到的資料，包括但不限于：PRD、原型、流程圖、設計稿、相關資料文檔、需求時間計劃等。
2. 需求評審干系人：確定需要參與會議的人員，例如，業務對接人、前端、后端、測試、設計等。特別是業務對接人，參與會議可以讓業務更了解他們提出的需求是怎么被實現的，提交給到開發其實需要需求描述到什么程度；另一方面，技術也可以通過業務對接人了解到更多業務場景，對需求實現有更深的理解。確保干系人都參與到會議，避免需求評審時相關人員不知情導致需要再次溝通或者需求實現偏移。
3. 需求評審時間地點：因為涉及到的與會人員多，所以需要溝通好會議時間地點，如果是常規迭代，最好是約定一個相對固定的時間，例如每周幾或者每月幾號這樣，讓團隊人員避開會議時間安排其他會議。通知方式根據實際公司情況而定，例如郵件、微信群、企業微信、釘釘、內部通訊工具等。像釘釘、企微這種協同辦公軟件有會議通知提醒功能，能更好的提醒到與會人員。

二、需求評審會中

作為需求評審會的主持人，第一，要清晰明確產品需求講解；第二，要把控整個會議的節奏。

需求評審需要大家達成共識并按照產品設計的實現它，簡單來說就是明確：價值、功能、實現。

• 價值（背景/目的）：為什么要做這個需求，上線之后的價值是什么。
• 功能（涉及產品、端、功能模塊）：為了這個價值，需求包含了哪些功能。
• 實現：針對每一個功能，應該怎么實現。

例如需求為：運營部門需要發布促銷活動在網站上客戶可選擇促銷活動下單。

第一步：產品經理在進行需求評審時，就需要把這個需求的價值（或背景目的）先說明清楚，即本次需求的目的是促使客戶下單，提高銷售效率。

這一步其實很重要，很多時候，技術對產品的不信任在于覺得產品提出的需求可能是偽需求，并非業務關注的，所以有必要在評審會上說明每個需求的來源和價值，證明我們是想清楚了才這樣設計功能的。

第二步：把需求價值同步后，就需要說明功能。

可先講解需求的業務流程，讓參與會議的人知道功能涉及哪些角色、哪些系統、數據流是怎樣的，做的心里有底，這個需求的范圍大小。然后，講解涉及到的單據狀態是怎么流向的。如果是復雜的功能，還需要有相關的表關系圖輔助技術理解。

這一步的重點在于，需要大家對流程先達成共識，如果大家對流程有疑問，需要及時溝通，否則后續說明實現時就會一團亂。

第三步：功能具體是如何實現的。這里可以根據個人習慣進行講解，這里介紹的是我自己的講解習慣，僅供參考。

流程+模塊

說實話，對著PRD或者原型講解，很容易走神，不知道講到哪里了，效果不佳，還容易被技術吐槽。

所以我采用的是流程+模塊的方式進行講解。在上一步，我們已經將流程說明了，也共識了流程，那我接下來的功能實現就是按照流程一步一步講解。

例如：發布促銷活動先進入促銷管理的頁面，進行新建促銷活動。那第一個節點模塊就是促銷管理的入口-》到進入促銷管理模塊中的促銷列表頁-》新增頁面-》編輯頁面-》詳情頁面的順序來講解實現。

• 在講解實現過程中，與會人員會對剛剛的產品設計進行提問，甚至是多個不同角色針對不同方面進行提問。能提問是好事，證明大家是認真聽了并思考了，通常我在講解完模塊實現后都會問一句：有沒有問題？沒有我們繼續。以此來保證大家進度。
• 但我們開會的時間是有限的，就需要判斷哪些問題需要當場解決，哪些問題可會后補充。個人建議，如果存在以下條件的，就應該當場解決，也因干系人都在，這時候解決效率最高：
  1. 關于項目價值目的，為什么要這樣做。例如：促銷活動詳情為什么還需要查看關聯的訂單情況？因為做促銷活動的目的就是反應在最后的下單情況上。
  2. 關于業務流程/邏輯完整性，這個問題不解決，業務進行不下去。例如：業務需要發布了活動才生效還是設置的開始時間到了自動生效。
  3. 影響到其他系統或功能模塊的。
• 而那些不影響主流程功能問題，比如前端細節，交互細節，后端邏輯細節，或者是你還不確定的點，如果會上不能快遞確定解決的，身為會議主持人，應該把控時間節奏，在PRD文檔上標注即可，會后溝通確認。

需求評審會議時長最后把控在1小時內，因為時間長了，我們的精力和注意力都會打折扣，想象一下一群人在會議室超過1個小時，里面的二氧化碳濃度也讓你渾渾噩噩，俗稱缺氧。

需求評審的目的：需求評審不是解決所有的問題，而是在會議時間里解決最重要的問題。檢驗需求的合理性和完整性，降低需求風險，確保項目目標和需求之間的一致性，便于團隊成員理解工作任務。

做到這一步，其實已經可以卸下大半的壓力，離“完好”走出還差最后一步。

第四步：需求時間計劃同步

在完成需求實現說明后，大家最關心的就是什么時候需要完成開發、提交驗收、上線等。因為這關乎工作量的評估和時間的緊迫性。

這時候，如果是新功能或者關鍵功能重構優化，建議技術部門提供技術方案，以此完善整個需求文檔，同時驗證產品設計是否有技術實現的問題。

三、需求評審會后跟進

會議結束后，當我們“完好”走出需求評審會，其實還需要對會議記錄進行整理，更新需求文檔，并通知相關團隊成員，才算真正的結算。

四、總結

通過需求評審，可以對產品需求進行全方位的論證，驗證或更改原有想法，獲取更多的想法，從而完善產品需求。

所以說，雖然在需求評審會上產品經理看似單兵作戰，其實我們跟會議上的人是合作關系，相互補充，為了讓產品需求更合理更明確。切勿有個人情緒，應當對事不對人。