會議後的待辦事項、真的都是屎缺嗎？

我當時當後輩時、有一次聽到前輩主管對我整理出來的資訊回憶起來：「當初會議中是討論到什麼？為什麼要整理這份資料啊？」

針對被指派的Action Items去全力達成、卻評價很差．．．

無效率的會議會隨著你越來越會解決問題成為你致命的弱點

• 知道要解決甚麼問題的角色、通常是擁有需求資訊來源的人，如果是客戶的需求，很多時候是【PM或Sales】擔任這個角色
• 擁有資訊跟解決工具的角色，我會叫他【Information Hub/Provider】，通常會是公司內部的專家
• 最後一位是決策者【Decision Maker】，通常是解決工具跟方法的成本負擔者主管，簡單來說就是他可以決定要不要花這時間、人力、金錢的頭兒。

所謂有效率的會議不是講話快或是會議時間很短而已、而是以上會議三本柱這三種角色都存在，而且資訊傳遞的順序由「知道要解決什麼問題」的人傳給「有解決方法」的人再彙整給「決策者」決議，以上就是符合【Why→How→What】的思考邏輯然後執行下去

當然現實的會議不會那麼輕鬆和樂

巴菲特：「如果你加入撲克牌局二十分鐘還不知道誰是輸家，那麼你就是輸家！」

以下的會議決議跟代辦事項要注意什麼？

• 界定權責：這要負責承擔成本的決策者【Decision Maker】存在且同意，切記不要把工作跟責任指派到一位不在場或是沒決定權的成員身上。如果你的會議中都是沒決定權的人，那就是三本柱沒到齊，本來就不該期待會有行動產生。
• 設計流程：切記權責相符的原則，千萬不要設計出有權無責，讓功能性部門擔任純顧問職的角色。PM還要不斷地回頭去確認這套流程有解決我們原本在討論的問題嗎？還是早就離題了？能自動化起來嗎？導入新流程會衍生新的風險嗎？
• 難以歸屬需平行單位合作的專案：把公司最高的需求抬出來，讓制高點更好一點。可以幫助大家聚焦如何解決問題，而非大家花時間去想各自遇到的困難；聚焦完畢後、這過程中遇到的問題都是需討論怎麼克服，而不是如何放棄。

研發人員轉職PM的心理準備

PM的原罪：功能性部門都可以只針對解決工具跟方法【How】來討論：「以前沒這種經驗耶」、「不是我們負責的喔」。只有PM不能只針對【How】來想事情。

PM的貢獻：PM常是那唯一且最了解要解決什麼問題【Why】的人，有他不斷協助大家聚焦，跟他合作總是覺得得到新資訊跟非常有效率。