-
1 # 走在城市路上
-
2 # 職場火鍋
如果你是行政部(會議的主辦部門)的負責人,組織高效會議,是你的本職工作,建議多看看辦公室主任之類的專業書籍。
如果你是其他部門(非會議主辦部門)的負責人,負責組織一次高效會議,或者組織一次專業會議(如高峰論壇、客戶答謝會)等等。建議,向行政部學習經驗,向公關公司學習經驗,或者委託公關公司承辦特大型會議。
如果你是參加會議,並且有發言之類的。建議做好充分的發言準備,事前聯絡,把控時間,必要的“走臺”,有條件去試試吧。
具體來講:第一,要起草會議籌備方案,建議列出一張會議籌備執行分工表。時間、事項、任務、標準、人員、檢查五個落實。
第二:明確會議主題,議程,程式,主持人,發言順序、時間要求。下發預備通知。最好把會議要求寫明白。重要的人物,要電話或當面確認,或彙報清楚。
第三:會場的會務安排。不要有掉鏈子的情況,做好預案,做好備用電源和備用投影的裝置。
第四:會前在通知一遍,重要事項和人物,要當面或電話確認。如有調整,做好調整方案。
第五:協助主持人把控會議秩序,尤其是時間節奏的把控。
第六:會中做好會議的記錄和新聞訊息的編撰,會後第一時間出簡訊,發出新聞通稿。
第七:會議紀要,最好立即撰寫,請會議主辦者(領導)簽發。
第八:會後的督察督辦
-
3 # 刻意練習產品思維
以我原型評審會議舉例
前言:
關鍵在於要搞定兩大陣營:需求陣營、技術陣營。
一、會前
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端產品人
-
4 # 夢希筆談
一、確定會議名稱。規範的會議名稱一般由三部分組成:一是會議範圍,二是會議內容,三是會議性質。其中會議性質包括“現場會”“啟動會”“工作會”“座談會”“研討會”等。
二、初定會議步驟
會議步驟包括會議的議程、程式、日程等。
三、草擬會議通知
會議通知一般包括會議的名稱、開會的目的和主要內容、會期、會議地點和食宿地點、與會人員、報到的日期和地點、需要攜帶的材料和數量及材料的列印規格、個人支付的費用、主辦單位、聯絡人和聯絡電話等要素。
四、會議經費預算
會議經費預算開支的專案一般包括與會人員的食宿費、會場的租用費、會標的製作費、會務組和工作人員的房費、膠捲購買和沖洗費用等。
五、辦理會議報批
重要的會議必須報請領導審批。
六、下發會議通知
會議通知務必經過處室領導稽核,主管領導簽發。
七、準備會議材料
會議材料主要有三種:一是會議檔案,包括下發的正式檔案、檔案討論稿或徵求意見的檔案;二是講話材料,包括領導講話材料、書面交流材料和會議發言材料;三是會議主持詞。在這裡筆者重點談談如何準備會議主持詞,它又叫程式稿,透過主持人在會議期間的講話來體現會議的程式。
八、選擇佈置會場
開會要藉助於一定的場所。會場條件的好壞、舒適程度的高低,對與會人員的心理會起到不可忽視的作用,直接影響到會議的效果。
九、明確人員分工
會議的會務人員可分三個小組,一是秘書組;二是材料組;三是接待組。
十、會前全面檢查
會前的全面檢查是進一步落實會議準備工作的重要環節。聽取會議所有籌備人員的口頭彙報,到現場實地檢查,進一步採取補救措施。
回覆列表
會議的規格不同,需要準備的事項不同。就公司召開部門協調會而言,一般要準備如下:一是明確需協調問題,有的放矢;二是提前將議題和要求通知參會部門,有備而來;三是會前1-2天再溫馨提醒,督促落實。然後按時開會,接下來,會議是否高效,就看主持者了!