以我原型評審會議舉例
前言：
關鍵在於要搞定兩大陣營：需求陣營、技術陣營。
一、會前
1、產品團隊先內部評審
俗話說，家醜不可外揚。
一般情況，是不會拿著你的2B原型，跟團隊內部小夥伴過一次的。
因為，誰也不想把不好的一面，露骨的展現給身邊人看的一清二楚。
一般人不推薦，等你有足夠的自信之後，不妨一試。
其實，小夥伴們大部分是很樂意參與並幫助你的，除非他們當時比較忙。
我們產品部門之前就試過，效果還蠻好的，可以提前規避不少小問題。
2、兩大陣營先單點逐個擊破
先找業務方評審，再找技術團隊評審，雖然慢了點兒，麻煩些。
但是，可以很大程度能讓你在原型評審大會上，不會被兩大陣營懟得體無完膚，手足無措。
2.1、單點突破——需求陣營
自己初步畫的原型和規則，得先跟業務方單獨過一下，確認是否達到初步預期。
業務方，是告知其該產品他們當初提的需求，如今如何滿足，頁面之間如何跳轉、如何操作。
所以，可多次騷擾他們，小腿兒勤快些，再約他們抽時間聊聊人生，直到在使用者體驗上，他們點頭滿意為止。
2.2、單點突破——技術陣營
技術陣營選手有：專案經理、UI設計師代表、前端開發代表、後臺開發代表、測試工程師代表等
技術，會摳產品的每一個細節，不斷的問你為什麼有這些頁面、流程和規則。
你原型裡有的，他能問的，都會問；沒有的，也會問，誰讓你沒想清楚？
不僅要寫程式碼、設計圖片、測試產品，還要來幫你這個渣渣產品擦屁股。
不是漏了這個規則，就是漏了那個流程，或者是這個頁面，反正就想懟你啦！
溫馨提示：如果你沒有跟技術陣營小夥伴，先小範圍至少原型評審一次，你會死得很慘。
除非，你對自己的業務流程、原型、規則極其自信。那請忽略我的友情提示。
同樣，別害怕被蹂躪，勇敢的面對他們，直到他們在流程、原型、規則上，不懟你為止，此輪小範圍評審才算暫時告一段落。
3、做好必要準備工作
溫馨提示：如果關鍵人物沒空參與或與其他會議發生衝突，咱們可往後延期再約。
但是，必須約到。能拍板的人沒空來參與，你的評審會，開了等於白開。
誰經歷，誰酸爽~~
3.2、會議通知提前一到兩天發
最好一個都不能少，當然特殊情況非關鍵人可提前請假。
3.3、準備好會議所有必備資料
需要分發的資料可以提前列印幾份出來，發給有需要的小夥伴。
3.4、提前與運維同事打好招呼，連線除錯好大會議室投影儀。
這事兒可大可小，如果關鍵時候掉鏈子，投影儀連不上，是很尷尬的一件事喲！
3.5、提前10分鐘到達會議室，並再次提醒專案組成員。
溫馨提醒大家，會議馬上要開始，請移步到會議室參會。
大家都很忙，可能一天要參加N多個會議，特別是關鍵人物。
你不提醒，不少小夥伴或許早已把你的會議忘得一乾二淨，很正常。
二、會中
準備工作做足後，那麼可以正式評審啦喂！快快拿好小板凳，排排坐。
4、告知會議目標
相信很多產品經理都會發現，明明我開會是聊這個需求的評審。
結果，被大家一通瞎幾把亂聊之後，多少人被帶到陰溝裡面去了呢？
開完會，啥結論也沒。好好的一個原型評審會，變成了產品吐槽大雜會。丟~
因此，重點關注會議主題、會議目標，為什麼開，怎麼開，要達到什麼效果？
為了不重蹈覆轍，會議目標必須開會剛開始就向所有人強調。
5、介紹專案背景
等等，別猴急嘛！怎麼也先來個前戲，讓人家有點心理準備吧？
無論有多少人，已經知道此專案的基本情況，依然建議你統一再次為參會人員介紹下為什麼要做這個產品，為誰服務，解決哪些痛點，有什麼價值。
6、對評審會議進行管控。
會議主持人做好控場工作，嚴格遵守會議流程。
先禮後兵，對事不對人。
偏題的話題避免拉長會議時間，浪費大家表情，建議直接打斷拉回主題。
7、心態要好，控制好情緒，別激動。
做產品經理，如果你沒有一顆大心臟，我現在就想勸退你。
見過舌戰群雄嗎？沒錯，你的第一次原型評審大會，將會感受到。
記住，你就是全場最亮的那個zai。
放鬆，坦然面對，親。
8、指定專人做會議紀要。
老鐵，醒醒！一般也就是你自己記錄啦。
當然，如果有個小助理，那就美滋滋咯！
9、認真落實會議決議並嚴格執行，責任到人。
放空炮誰不會啊？關鍵是很多需要落地的東西，必須責任到人。
比如說：如果原型評審沒透過，作為產品經理的你得會後繼續最佳化原型再評審，直到透過為止，才能往下推進工作；如果通過了，設計需要誰出UI圖？多久出？
好多事兒呢，各項工作，都得在會議上逐一落實，各自認領。
別忘記了，你已經單獨跟技術聊過技術規則細節了。
在這種大會上，那麼多非技術人員參與，你聊過多技術實現細節問題，結果是啥，知道不？
玩手機的玩手機，睡覺的睡覺。大會哦，大佬？並不是技術原型評審會，切記。
三、會後
10、將整理好的會議記要，發給專案參會人。
豬哥將平時工作中使用的會議通知、會議紀要模板分享給你。
如果你還需要什麼工作模板，請私撩我咯~
11、與技術團隊溝通產品提測、上線時間。
原型評審透過之後，產品也閒不下來的啦！
拉小會與技術陣營小夥伴溝通：UI圖什麼時候出來？程式碼什麼時候提測？測試什麼時候上灰度環境？什麼時候產品和業務方驗收？等等一堆問題，都需要定個時間節點。
12、給業務方反饋上線時間
大家才剛剛評審完，便拉著你，來那麼一句：什麼時候上線啊？我很急？
13、管控專案進度
專案管理，主要的痛，個人覺得是以下幾點，建議重點關注一二。
13.1、需求變更
又一個老大難問題，需求變更導致的風險，是很麻煩嚴重的。不過，要根據自己的經驗與能力判斷，此次需求方變更需求的影響範圍。
如果影響不大，那能改就改;如果影響較大，那必須上報風險，事前告知需求方並給出合理理由。
如果是影響思維模型中的底層資料架構，那必須報嚴重風險。
13.2、緊急需求
最怕這類人，不講理還霸道，整個專案正常的上線流程又不是不知道，但還要提出我現在就要，一週之內就要這種不懂網際網路專案正常上線流程的無理要求。
誰的事不急，誰的需求不重要？你現在要，我也給不了，小需求我可以快速評估，儘快上線，儘量做到能今天上線絕不拖延到明天。
但是，大需求該怎麼走流程還是得怎麼走。
13.3、專案組臨時換人
專案開發到一半，技術突然離職或者被其他專案借調，導致專案突然報風險，也是很容易讓人措手不及。
如果技術離職，得找人儘快接手咱們的專案。如果技術被借調，咱們產品得去了解具體原因，想解決方案。
最終目的，保證專案正常上線。
總結：
原型評審，是我們產品人，不得不面對並認真做好的一步。任重而道遠，各自加油哦！
推薦閱讀:
豬哥1分鐘(死磕365天，已完成23.84%)
標籤：退伍軍人，反面教材創業者，懂技術懂運營的B端產品人
以我原型評審會議舉例
前言：
關鍵在於要搞定兩大陣營：需求陣營、技術陣營。
一、會前
1、產品團隊先內部評審
俗話說，家醜不可外揚。
一般情況，是不會拿著你的2B原型，跟團隊內部小夥伴過一次的。
因為，誰也不想把不好的一面，露骨的展現給身邊人看的一清二楚。
一般人不推薦，等你有足夠的自信之後，不妨一試。
其實，小夥伴們大部分是很樂意參與並幫助你的，除非他們當時比較忙。
我們產品部門之前就試過，效果還蠻好的，可以提前規避不少小問題。
2、兩大陣營先單點逐個擊破
先找業務方評審，再找技術團隊評審，雖然慢了點兒，麻煩些。
但是，可以很大程度能讓你在原型評審大會上，不會被兩大陣營懟得體無完膚，手足無措。
2.1、單點突破——需求陣營
自己初步畫的原型和規則，得先跟業務方單獨過一下，確認是否達到初步預期。
業務方，是告知其該產品他們當初提的需求，如今如何滿足，頁面之間如何跳轉、如何操作。
所以，可多次騷擾他們，小腿兒勤快些，再約他們抽時間聊聊人生，直到在使用者體驗上，他們點頭滿意為止。
2.2、單點突破——技術陣營
技術陣營選手有：專案經理、UI設計師代表、前端開發代表、後臺開發代表、測試工程師代表等
技術，會摳產品的每一個細節，不斷的問你為什麼有這些頁面、流程和規則。
你原型裡有的，他能問的，都會問；沒有的，也會問，誰讓你沒想清楚？
不僅要寫程式碼、設計圖片、測試產品，還要來幫你這個渣渣產品擦屁股。
不是漏了這個規則，就是漏了那個流程，或者是這個頁面，反正就想懟你啦！
溫馨提示：如果你沒有跟技術陣營小夥伴，先小範圍至少原型評審一次，你會死得很慘。
除非，你對自己的業務流程、原型、規則極其自信。那請忽略我的友情提示。
同樣，別害怕被蹂躪，勇敢的面對他們，直到他們在流程、原型、規則上，不懟你為止，此輪小範圍評審才算暫時告一段落。
3、做好必要準備工作
溫馨提示：如果關鍵人物沒空參與或與其他會議發生衝突，咱們可往後延期再約。
但是，必須約到。能拍板的人沒空來參與，你的評審會，開了等於白開。
誰經歷，誰酸爽~~
3.2、會議通知提前一到兩天發
最好一個都不能少，當然特殊情況非關鍵人可提前請假。
3.3、準備好會議所有必備資料
需要分發的資料可以提前列印幾份出來，發給有需要的小夥伴。
3.4、提前與運維同事打好招呼，連線除錯好大會議室投影儀。
這事兒可大可小，如果關鍵時候掉鏈子，投影儀連不上，是很尷尬的一件事喲！
3.5、提前10分鐘到達會議室，並再次提醒專案組成員。
溫馨提醒大家，會議馬上要開始，請移步到會議室參會。
大家都很忙，可能一天要參加N多個會議，特別是關鍵人物。
你不提醒，不少小夥伴或許早已把你的會議忘得一乾二淨，很正常。
二、會中
準備工作做足後，那麼可以正式評審啦喂！快快拿好小板凳，排排坐。
4、告知會議目標
相信很多產品經理都會發現，明明我開會是聊這個需求的評審。
結果，被大家一通瞎幾把亂聊之後，多少人被帶到陰溝裡面去了呢？
開完會，啥結論也沒。好好的一個原型評審會，變成了產品吐槽大雜會。丟~
因此，重點關注會議主題、會議目標，為什麼開，怎麼開，要達到什麼效果？
為了不重蹈覆轍，會議目標必須開會剛開始就向所有人強調。
5、介紹專案背景
等等，別猴急嘛！怎麼也先來個前戲，讓人家有點心理準備吧？
無論有多少人，已經知道此專案的基本情況，依然建議你統一再次為參會人員介紹下為什麼要做這個產品，為誰服務，解決哪些痛點，有什麼價值。
6、對評審會議進行管控。
會議主持人做好控場工作，嚴格遵守會議流程。
先禮後兵，對事不對人。
偏題的話題避免拉長會議時間，浪費大家表情，建議直接打斷拉回主題。
7、心態要好，控制好情緒，別激動。
做產品經理，如果你沒有一顆大心臟，我現在就想勸退你。
見過舌戰群雄嗎？沒錯，你的第一次原型評審大會，將會感受到。
記住，你就是全場最亮的那個zai。
放鬆，坦然面對，親。
8、指定專人做會議紀要。
老鐵，醒醒！一般也就是你自己記錄啦。
當然，如果有個小助理，那就美滋滋咯！
9、認真落實會議決議並嚴格執行，責任到人。
放空炮誰不會啊？關鍵是很多需要落地的東西，必須責任到人。
比如說：如果原型評審沒透過，作為產品經理的你得會後繼續最佳化原型再評審，直到透過為止，才能往下推進工作；如果通過了，設計需要誰出UI圖？多久出？
好多事兒呢，各項工作，都得在會議上逐一落實，各自認領。
別忘記了，你已經單獨跟技術聊過技術規則細節了。
在這種大會上，那麼多非技術人員參與，你聊過多技術實現細節問題，結果是啥，知道不？
玩手機的玩手機，睡覺的睡覺。大會哦，大佬？並不是技術原型評審會，切記。
三、會後
10、將整理好的會議記要，發給專案參會人。
豬哥將平時工作中使用的會議通知、會議紀要模板分享給你。
如果你還需要什麼工作模板，請私撩我咯~
11、與技術團隊溝通產品提測、上線時間。
原型評審透過之後，產品也閒不下來的啦！
拉小會與技術陣營小夥伴溝通：UI圖什麼時候出來？程式碼什麼時候提測？測試什麼時候上灰度環境？什麼時候產品和業務方驗收？等等一堆問題，都需要定個時間節點。
12、給業務方反饋上線時間
大家才剛剛評審完，便拉著你，來那麼一句：什麼時候上線啊？我很急？
13、管控專案進度
專案管理，主要的痛，個人覺得是以下幾點，建議重點關注一二。
13.1、需求變更
又一個老大難問題，需求變更導致的風險，是很麻煩嚴重的。不過，要根據自己的經驗與能力判斷，此次需求方變更需求的影響範圍。
如果影響不大，那能改就改;如果影響較大，那必須上報風險，事前告知需求方並給出合理理由。
如果是影響思維模型中的底層資料架構，那必須報嚴重風險。
13.2、緊急需求
最怕這類人，不講理還霸道，整個專案正常的上線流程又不是不知道，但還要提出我現在就要，一週之內就要這種不懂網際網路專案正常上線流程的無理要求。
誰的事不急，誰的需求不重要？你現在要，我也給不了，小需求我可以快速評估，儘快上線，儘量做到能今天上線絕不拖延到明天。
但是，大需求該怎麼走流程還是得怎麼走。
13.3、專案組臨時換人
專案開發到一半，技術突然離職或者被其他專案借調，導致專案突然報風險，也是很容易讓人措手不及。
如果技術離職，得找人儘快接手咱們的專案。如果技術被借調，咱們產品得去了解具體原因，想解決方案。
最終目的，保證專案正常上線。
總結：
原型評審，是我們產品人，不得不面對並認真做好的一步。任重而道遠，各自加油哦！
推薦閱讀:
豬哥1分鐘(死磕365天，已完成23.84%)
標籤：退伍軍人，反面教材創業者，懂技術懂運營的B端產品人