會議後的待辦事項、真的都是屎缺嗎？
相信各位PM們剛加入任何新的組織時，都要渡過一段跟在資深PM後頭去開會的日子，貼心一點的前輩會指導自己開會的眉角，但大部分時間就是進去做會議記錄跟執行會議結論的角色。
而會議結論中常常是去宣導、去調查資料、去整理資訊這類的後勤工作才會交代給後輩。甚至在步調更快的公司裡，表現上手的後輩很快就要直接面對客戶去解決客戶的問題了，所以從後勤到前線的分界點其實是很模糊的。
因為會議的本質就是解決問題，而不是拿來教育訓練的，所以想利用會議來成長卻適應不良是可預期的，而且前輩也是每天被會議疲勞轟炸到無暇他顧啊。
既然有關會議的「學習跟教學」，我自己走得坑坑巴巴、我就時常在想：如何讓PM迅速了解會議的本質跟上手呢？畢竟PM會議超~級~多~的~
我當時當後輩時、有一次聽到前輩主管對我整理出來的資訊回憶起來：「當初會議中是討論到什麼？為什麼要整理這份資料啊？」
針對被指派的Action Items去全力達成、卻評價很差．．． 老闆覺得會議中已經講很清楚了、但你做出來的成果卻沒有讓他很清楚。
這類事情我前陣子才發生過一次喔、大老闆無奈地在電話中說：「我不是會議中講得很清楚了嗎？」
其實我發現主要問題是「不敢問」，問也不應該亂問，最最重要的就是問要解決甚麼問題【Why】。
當我們不清楚要解決甚麼問題跟如何在可控風險下有效率處理【How】，就造成很多資料整理類的工作並沒有緊扣著要解決的問題，淪為「知道很好」【Just Nice to Know】的資訊，沒辦法幫助達成需求、解決問題。
無效率的會議會隨著你越來越會解決問題成為你致命的弱點 隨著處理問題的經驗越來越豐富，你有一天一定會成為一位獨當一面的PM，那代表你會成為因為有必須解決的問題而召開會議的人，這時候你面臨到的問題是「我該邀誰來開會呢？」
我會建議邀請來會議的成員要重視的是角色別而不僅是部門別（雖然大致上他們很難區分），我稱他們為會議三本柱：
- 知道要解決甚麼問題的角色、通常是擁有需求資訊來源的人，如果是客戶的需求，很多時候是【PM或Sales】擔任這個角色
- 擁有資訊跟解決工具的角色，我會叫他【Information Hub/Provider】，通常會是公司內部的專家
- 最後一位是決策者【Decision Maker】，通常是解決工具跟方法的成本負擔者主管，簡單來說就是他可以決定要不要花這時間、人力、金錢的頭兒。
不管是內部會議或是外部會議，只要缺少其中一位角色，基本上就可以預期這場會議屬於資訊交流〈聊天？〉的屬性，應該無法得出可落實的行動。
比較困難的是跟客戶的會議中，實質上的Decision Maker有時候要花點心思才能找到，千萬不要先入為主地覺得對方職稱最高的主管一定就是跟自己業務範圍相關的決策者。
所謂有效率的會議不是講話快或是會議時間很短而已、而是以上會議三本柱這三種角色都存在，而且資訊傳遞的順序由「知道要解決什麼問題」的人傳給「有解決方法」的人再彙整給「決策者」決議，以上就是符合【Why→How→What】的思考邏輯然後執行下去
當然現實的會議不會那麼輕鬆和樂 巴菲特：「如果你加入撲克牌局二十分鐘還不知道誰是輸家，那麼你就是輸家！」
會議很難「學習跟教學」，會議裡的人物角色有時更會隨著發言的過程產生變動〈PM也可能暫時變成Information Hub〉，所以過程中你要很仔細聆聽每個人的發言，這也是為何難教學的地方，前輩很難在我們身邊像球評一樣分析這個射門有多精彩！都是靠個人的天賦跟特質成長著。
有些事先準備功課會讓你更好上手會議的理解，進去每場會議前就要知道這場會議即將討論要解決的問題跟每位參與成員的背後需求是什麼？身為PM要合理的處理那些「知道很好」【Just Nice to Know】的資訊收集要求，不然你的會議代辦事項上就會有很多屎缺！
專業的PM必須在過程中藉由不斷地問對問題，協助每位參加會議的人聚焦在要解決的問題上，我看過很多一流的PM開會，那種感動至今都很深深刻印在腦中，這也是我為何想寫下這篇文章的理由。
會議中總是會產生新的要做的事，即便根據我們以上的原則去落實，已經盡量減少無用的行動了，但有新的事要做就代表壓力會上升，這方面的壓力對很多PM來說是相當難承受的，因為他必須使出渾身解數去讓好事發生；他必須說服專家們、他必須排序每人背後的需求、他必須助攻自己夥伴、他甚至必須拔出背後的箭往前走．．．
以下的會議決議跟代辦事項要注意什麼？ - 界定權責：這要負責承擔成本的決策者【Decision Maker】存在且同意，切記不要把工作跟責任指派到一位不在場或是沒決定權的成員身上。如果你的會議中都是沒決定權的人，那就是三本柱沒到齊，本來就不該期待會有行動產生。
- 設計流程：切記權責相符的原則，千萬不要設計出有權無責，讓功能性部門擔任純顧問職的角色。PM還要不斷地回頭去確認這套流程有解決我們原本在討論的問題嗎？還是早就離題了？能自動化起來嗎？導入新流程會衍生新的風險嗎？
- 難以歸屬需平行單位合作的專案：把公司最高的需求抬出來，讓制高點更好一點。可以幫助大家聚焦如何解決問題，而非大家花時間去想各自遇到的困難；聚焦完畢後、這過程中遇到的問題都是需討論怎麼克服，而不是如何放棄。
研發人員轉職PM的心理準備 PM的原罪：功能性部門都可以只針對解決工具跟方法【How】來討論：「以前沒這種經驗耶」、「不是我們負責的喔」。只有PM不能只針對【How】來想事情。
PM的貢獻：PM常是那唯一且最了解要解決什麼問題【Why】的人，有他不斷協助大家聚焦，跟他合作總是覺得得到新資訊跟非常有效率。
這與許多研發人員跟專家過去習慣擔任的角色完全不同，但優點是許多研發同仁邏輯很不錯，在會議中更能協助聚焦的工作，不會隨著討論而發散。只要心理準備準備好了，我相信不管過去是什麼職務的同仁都可以很輕鬆勝任PM這個角色的。
商科PM是擁有十餘年以上經驗的IC設計業PM主管，如果覺得我的文章有一點點幫助，請記得按下追蹤跟「免費」連擊下方【5個讚】喔。 《免費註冊一般公民，推薦人請填tomatochuan喔，好人一生平安呀！》。 如果願意每月贊助150元，鼓勵更多的創作，歡迎用此連結加入Likecoin讚賞公民。 這裡的文章跟資料主要是為了以下需求所設計、歡迎追蹤跟轉發（請務必標示出處） - 經常會遇到學弟妹詢問面試技巧 - 準備公司新進人員的內部教育訓練 - 面對組織內中階主管的晉升培育計畫
隨著處理問題的經驗越來越豐富，你有一天一定會成為一位獨當一面的PM，那代表你會成為因為有必須解決的問題而召開會議的人，這時候你面臨到的問題是「我該邀誰來開會呢？」
我會建議邀請來會議的成員要重視的是角色別而不僅是部門別（雖然大致上他們很難區分），我稱他們為會議三本柱：
- 知道要解決甚麼問題的角色、通常是擁有需求資訊來源的人，如果是客戶的需求，很多時候是【PM或Sales】擔任這個角色
- 擁有資訊跟解決工具的角色，我會叫他【Information Hub/Provider】，通常會是公司內部的專家
- 最後一位是決策者【Decision Maker】，通常是解決工具跟方法的成本負擔者主管，簡單來說就是他可以決定要不要花這時間、人力、金錢的頭兒。
不管是內部會議或是外部會議，只要缺少其中一位角色，基本上就可以預期這場會議屬於資訊交流〈聊天？〉的屬性，應該無法得出可落實的行動。
比較困難的是跟客戶的會議中，實質上的Decision Maker有時候要花點心思才能找到，千萬不要先入為主地覺得對方職稱最高的主管一定就是跟自己業務範圍相關的決策者。
所謂有效率的會議不是講話快或是會議時間很短而已、而是以上會議三本柱這三種角色都存在，而且資訊傳遞的順序由「知道要解決什麼問題」的人傳給「有解決方法」的人再彙整給「決策者」決議，以上就是符合【Why→How→What】的思考邏輯然後執行下去
當然現實的會議不會那麼輕鬆和樂 巴菲特：「如果你加入撲克牌局二十分鐘還不知道誰是輸家，那麼你就是輸家！」
會議很難「學習跟教學」，會議裡的人物角色有時更會隨著發言的過程產生變動〈PM也可能暫時變成Information Hub〉，所以過程中你要很仔細聆聽每個人的發言，這也是為何難教學的地方，前輩很難在我們身邊像球評一樣分析這個射門有多精彩！都是靠個人的天賦跟特質成長著。
有些事先準備功課會讓你更好上手會議的理解，進去每場會議前就要知道這場會議即將討論要解決的問題跟每位參與成員的背後需求是什麼？身為PM要合理的處理那些「知道很好」【Just Nice to Know】的資訊收集要求，不然你的會議代辦事項上就會有很多屎缺！
專業的PM必須在過程中藉由不斷地問對問題，協助每位參加會議的人聚焦在要解決的問題上，我看過很多一流的PM開會，那種感動至今都很深深刻印在腦中，這也是我為何想寫下這篇文章的理由。
會議中總是會產生新的要做的事，即便根據我們以上的原則去落實，已經盡量減少無用的行動了，但有新的事要做就代表壓力會上升，這方面的壓力對很多PM來說是相當難承受的，因為他必須使出渾身解數去讓好事發生；他必須說服專家們、他必須排序每人背後的需求、他必須助攻自己夥伴、他甚至必須拔出背後的箭往前走．．．
以下的會議決議跟代辦事項要注意什麼？ - 界定權責：這要負責承擔成本的決策者【Decision Maker】存在且同意，切記不要把工作跟責任指派到一位不在場或是沒決定權的成員身上。如果你的會議中都是沒決定權的人，那就是三本柱沒到齊，本來就不該期待會有行動產生。
- 設計流程：切記權責相符的原則，千萬不要設計出有權無責，讓功能性部門擔任純顧問職的角色。PM還要不斷地回頭去確認這套流程有解決我們原本在討論的問題嗎？還是早就離題了？能自動化起來嗎？導入新流程會衍生新的風險嗎？
- 難以歸屬需平行單位合作的專案：把公司最高的需求抬出來，讓制高點更好一點。可以幫助大家聚焦如何解決問題，而非大家花時間去想各自遇到的困難；聚焦完畢後、這過程中遇到的問題都是需討論怎麼克服，而不是如何放棄。
研發人員轉職PM的心理準備 PM的原罪：功能性部門都可以只針對解決工具跟方法【How】來討論：「以前沒這種經驗耶」、「不是我們負責的喔」。只有PM不能只針對【How】來想事情。
PM的貢獻：PM常是那唯一且最了解要解決什麼問題【Why】的人，有他不斷協助大家聚焦，跟他合作總是覺得得到新資訊跟非常有效率。
這與許多研發人員跟專家過去習慣擔任的角色完全不同，但優點是許多研發同仁邏輯很不錯，在會議中更能協助聚焦的工作，不會隨著討論而發散。只要心理準備準備好了，我相信不管過去是什麼職務的同仁都可以很輕鬆勝任PM這個角色的。
商科PM是擁有十餘年以上經驗的IC設計業PM主管，如果覺得我的文章有一點點幫助，請記得按下追蹤跟「免費」連擊下方【5個讚】喔。 《免費註冊一般公民，推薦人請填tomatochuan喔，好人一生平安呀！》。 如果願意每月贊助150元，鼓勵更多的創作，歡迎用此連結加入Likecoin讚賞公民。 這裡的文章跟資料主要是為了以下需求所設計、歡迎追蹤跟轉發（請務必標示出處） - 經常會遇到學弟妹詢問面試技巧 - 準備公司新進人員的內部教育訓練 - 面對組織內中階主管的晉升培育計畫
- 界定權責：這要負責承擔成本的決策者【Decision Maker】存在且同意，切記不要把工作跟責任指派到一位不在場或是沒決定權的成員身上。如果你的會議中都是沒決定權的人，那就是三本柱沒到齊，本來就不該期待會有行動產生。
- 設計流程：切記權責相符的原則，千萬不要設計出有權無責，讓功能性部門擔任純顧問職的角色。PM還要不斷地回頭去確認這套流程有解決我們原本在討論的問題嗎？還是早就離題了？能自動化起來嗎？導入新流程會衍生新的風險嗎？
- 難以歸屬需平行單位合作的專案：把公司最高的需求抬出來，讓制高點更好一點。可以幫助大家聚焦如何解決問題，而非大家花時間去想各自遇到的困難；聚焦完畢後、這過程中遇到的問題都是需討論怎麼克服，而不是如何放棄。
研發人員轉職PM的心理準備 PM的原罪：功能性部門都可以只針對解決工具跟方法【How】來討論：「以前沒這種經驗耶」、「不是我們負責的喔」。只有PM不能只針對【How】來想事情。
PM的貢獻：PM常是那唯一且最了解要解決什麼問題【Why】的人，有他不斷協助大家聚焦，跟他合作總是覺得得到新資訊跟非常有效率。
這與許多研發人員跟專家過去習慣擔任的角色完全不同，但優點是許多研發同仁邏輯很不錯，在會議中更能協助聚焦的工作，不會隨著討論而發散。只要心理準備準備好了，我相信不管過去是什麼職務的同仁都可以很輕鬆勝任PM這個角色的。
商科PM是擁有十餘年以上經驗的IC設計業PM主管，如果覺得我的文章有一點點幫助，請記得按下追蹤跟「免費」連擊下方【5個讚】喔。 《免費註冊一般公民，推薦人請填tomatochuan喔，好人一生平安呀！》。 如果願意每月贊助150元，鼓勵更多的創作，歡迎用此連結加入Likecoin讚賞公民。 這裡的文章跟資料主要是為了以下需求所設計、歡迎追蹤跟轉發（請務必標示出處） - 經常會遇到學弟妹詢問面試技巧 - 準備公司新進人員的內部教育訓練 - 面對組織內中階主管的晉升培育計畫
分享至
成為作者繼續創作的動力吧！
© 2024 vocus All rights reserved.