【PM筆記】 Retro啟示 — 給成員間最有力的回饋,而非太過浮濫的感謝(文末線上工具推薦)

更新於 發佈於 閱讀時間約 4 分鐘
Retro= Retrospective (回顧會議),大部分正在運行Scrum team的成員,每兩週/每月都會利用這場會議,回顧這些日子以來遇到的困境,提出可行的解決方案,針對在這個Sprint中,與他人合作時發生的開心、不開心的事件來回饋。許多members也常在retro 說出因受到他人幫助的感謝、但若這場會議變成你感謝我、我感謝你、你再感謝他的巡迴,很容易像是一場輪流上台的頒獎典禮,真正需要改善的問題反而沒有被拿出來討論、解決。
記得感謝但卻沒有提出「具體的回饋」來讓團隊更好,怎麼做讓每次Retro價值感提升、問題不再歷史重演。先聊聊為何總感覺一場retro 會議之後沒有踏實感,問題沒有被解決、回饋不夠到位的
主因— 1.成員間彼此不熟,深怕在會議中講話太過直接傷和氣
大部分會不敢在retro會議中直接反饋的原因是在團隊建立初期時,因為成員間彼此還不熟悉,還在摸索彼此的工作模式,在沒有建立起雙方默契時,若直接點出問題、給予回饋可能會像是在糾正或是找麻煩,如果這場會議剛好主管也在,當下被反饋的當事人不但沒有聽進去,之後再與他合作反而會出現無形隔閡。🙀
主因 — 2. 沒有抓到 Retro 的主要目的
一場Retro可能是回顧這個Sprint,也可以是針對部門的議題做討論,會議目的在事前沒有被確立好,只知道時間到了開始坐下來開會,在目的是什麼、要解決什麼事沒有被定義的情況下,焦點容易在會議上發散。主因 — 3. 節奏沒被掌握,該說的還沒說,會議就結束了
想像回顧會議就是這段日子以來的種種工作回顧,開心的是被好同事carry,不悅的是那個總是遲交文件的同事。感謝完好同事之後,卻不好意思點名那個有點雷的同事,於是會議就這樣結束了…。


:這件事有解嗎?

:有!

解法1. 會議前收集回饋, 會議中對「事件」而非「當事人」做回饋
通常PM在會議前,會群發一封信預告會議時間、地點,同時也可以利用這封信詢問針對會議有什麼「議題」想一起討論,這個議題可大可小、但都是在會影響工作、團隊運作的情況下提供,例如:團隊的溝通效率不佳、設計師的flow沒有及時更新,讓RD在開發時要不斷確認…等。這時候PM在會議前就會先整理大家回覆的email,在會議上針對大家的問題做討論,且注意是針對事「事件」而不是「當事人」,可以提及這是誰提出的問題,請當事人說明事情的原委,但非必要不用特別說明是給誰的建議(因為通常都心理有數),這時候大家會開始討論怎麼解決此事,例如事設計師與工程師間資料歸檔的問題,那就討論出雙方都願意配合的資料歸檔SOP。如此一來,不但提昇會議效率(事先整理好議題,當場討論解法)也避免成員間因為面對面而不敢表達的窘境,簡言之,事先花一點時間整理議題,可以省去很多事後的溝通成本。
解法2. 感謝轉成稱讚,描述事蹟更具體!
受別人幫助,我們會把它放在心上並由衷感謝,但感謝畢竟有其局限性,通常只能起到雙向作用,我感謝你對我感謝,但別忘了會議上還有其他人,若是把原先的感謝轉成真心的稱讚,反而讓力道更強、「具體事蹟」更容易被描述。例1:謝謝Carol準時交付檔案給我!例2: Carol做事很有效率, 準時給我UI檔案讓我及時交付規格。兩句可能是相同情境的話,只是從感謝轉成稱讚,效果就不一樣,成員聽見也會清楚知道那個人因為哪件事而被稱讚,全員一起學習共好!

📷Mindset → 氣氛對了!什麼都對了!
Retro 是一個不算太過正式的會議,因為通常除了回顧工作之外,團隊也會花1/3的時間閒聊工作上的趣事、時事。每個Sprint 已經有百百場會議了,如果每場會議都如此緊繃,會讓人窒息的。想主辦一場成功的Retro ,最終目的是問題得以解決,所要具備的心態就是「掌握節奏&好的氣氛」。因此身為會議主持人(通常是PO , PM or 成員輪流)會想花一點時間在會議前先跟大家聊聊,放鬆大家的心情。因為是非正式的會議,所以可以準備一些茶點、飲料還有萬用的「便利貼」!開始討論議題時,大家會一起想出多個解,這時候可以利用便利貼投票的方式,投出大家心中理想的解法,成員站起來到台貼便利貼寫+1或寫其他文字表達意見 ,如此一來也讓Retro 會議更活潑!😻
🔗線上Retro好用工具:
為什麼會看到廣告
avatar-img
14會員
13內容數
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
Aurora Chen的沙龍 的其他內容
自從兩年多前開始幫有需要的朋友履歷健檢,以及過去在HR單位看過上百封的履歷之後,我歸納出‘‘最多人會踩進的三大誤區’’ 分享給大家,這篇文章可幫助檢視正在撰寫履歷的你,是否中了最多人以為「沒問題」但卻「誤會大了」的三大誤區。
自從兩年多前開始幫有需要的朋友履歷健檢,以及過去在HR單位看過上百封的履歷之後,我歸納出‘‘最多人會踩進的三大誤區’’ 分享給大家,這篇文章可幫助檢視正在撰寫履歷的你,是否中了最多人以為「沒問題」但卻「誤會大了」的三大誤區。
你可能也想看
Google News 追蹤
Thumbnail
現代社會跟以前不同了,人人都有一支手機,只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行,然而如今科技快速發展之下,金融App無聲無息地進到你生活中。但同樣的,每一家銀行都有自己的App時,我們又該如何選擇呢?(本文係由國泰世華銀行邀約) 今天我會用不同角度帶大家看這款國泰世華CUB
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船,通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧,幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃,從而提升未來專案的成功率。
Thumbnail
上個禮拜,我們部門開了跨級溝通會。 跨級溝通會是非主管級員工和+2級主管直接溝通的場合, 所有+1級主管皆不可參加。 問題是會議前匿名蒐集的,讓我們有足夠的時間思考, 用文字表達也能好好地斟酌用詞和潤飾口氣, 更重要的是匿名提問,保護所有勇敢提問的人,挺好的。 不過,這次我沒
Thumbnail
會議,是許多中小企業最喜歡做的事情。 曾經看過一個團隊一周最少開7-10個會議,有時會更多,最後的結果大都議而不決,不斷地探討特殊個案的解方,或是調整企畫內容去符合某些小眾的需求。  換個角度來看,這些在職場的日子上,我們有多少企劃、多少的專案提報,總是過不了上面主管、頂層老闆的首肯。
Thumbnail
要是我對部門同仁說:這件事情你們討論就好。 這代表他們決定就好。 多年來我也都是這樣做事的。即使下屬的決定跟我想的不同,我也尊重他們的最終決議,因為是我授權他們做的決定。 初期有點困難,總覺得他們想的不夠透徹,但我忍住不插手。 經過這些年來我的感受是:即使處理方法不同,最終的結果有時也很好。
Thumbnail
在敏捷開發過程中,每兩週都會有一場回顧會議(retro),PO、UX、RD、QA 會針對該 Sprint 進行檢討和反思,這篇想記錄以產品經理(PO)的角度常被提到的檢討點,一方面是幫助自己成長,另一面是更濃縮自己的產品想法。 誰適合看這篇文章?✔ 對產品經理、產品企劃、產品策略、產品規劃有興
Thumbnail
本文探討了企業內部的回饋制度運作情況,指出缺乏日常的回饋將導致同仁無法清楚知道自身哪裡需要改善,進而影響績效。本文推薦了《麥肯錫主管意見回饋術》這本書,強調透過回饋提供每位同仁成長機會與適當建議。最後,作者提出了做好意見回饋的六個關鍵及意見回饋的四步驟,以及強調回饋作為領導力的基本功。
Thumbnail
絮絮叨叨說了這些,就像是在對過去說道別,打包放入記憶庫,歸攏架上,等到哪日再翻找出來回味。放下過去,迎向未來,說起來很簡單,但身處其中自有其箇中滋味,因為心中知道,走出去到其他地方,雖然不至於斷了聯繫,但也曉得時間會沖淡這一份熟悉感,慢慢變得模糊直至難以辨認出原始模樣。
選商會議最重要的三件事: 1。 讓與會的主管和使用者在最短的時間裏瞭解系統功能。 2。 讓與會人員有初步的互動機會,瞭解對彼此的基本看法。 3。 評分,建立一張表格來評分。 經由評分,就有比較客觀的依據來選擇專案成員最希望合作的廠商。 確定議約廠商後,就進入議約階段。
凡是專案,就一定有啟動會議。 啟動會議最主要的目的是讓專案成員、利害關係人齊聚一堂、互相認識,瞭解專案的目標、工作大項、程和里程碑,最重要的是要爭取功能主管對專案的支持,能夠派出成員利用在原部門工作的時間來參與專案。 ERP專案的啟動會議有兩次。
kick off meeting啟動會議是什麼?有什麼用?我們可以怎麼開展kick off meeting?跟著我們一起8步驟學會規劃啟動會議!通過不同類型的kick off meeting 範例分析進行學習,掌握啟動會議每一流程!更有高效會議規劃工具推薦,一鍵生成會議紀錄!
Thumbnail
現代社會跟以前不同了,人人都有一支手機,只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行,然而如今科技快速發展之下,金融App無聲無息地進到你生活中。但同樣的,每一家銀行都有自己的App時,我們又該如何選擇呢?(本文係由國泰世華銀行邀約) 今天我會用不同角度帶大家看這款國泰世華CUB
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船,通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧,幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃,從而提升未來專案的成功率。
Thumbnail
上個禮拜,我們部門開了跨級溝通會。 跨級溝通會是非主管級員工和+2級主管直接溝通的場合, 所有+1級主管皆不可參加。 問題是會議前匿名蒐集的,讓我們有足夠的時間思考, 用文字表達也能好好地斟酌用詞和潤飾口氣, 更重要的是匿名提問,保護所有勇敢提問的人,挺好的。 不過,這次我沒
Thumbnail
會議,是許多中小企業最喜歡做的事情。 曾經看過一個團隊一周最少開7-10個會議,有時會更多,最後的結果大都議而不決,不斷地探討特殊個案的解方,或是調整企畫內容去符合某些小眾的需求。  換個角度來看,這些在職場的日子上,我們有多少企劃、多少的專案提報,總是過不了上面主管、頂層老闆的首肯。
Thumbnail
要是我對部門同仁說:這件事情你們討論就好。 這代表他們決定就好。 多年來我也都是這樣做事的。即使下屬的決定跟我想的不同,我也尊重他們的最終決議,因為是我授權他們做的決定。 初期有點困難,總覺得他們想的不夠透徹,但我忍住不插手。 經過這些年來我的感受是:即使處理方法不同,最終的結果有時也很好。
Thumbnail
在敏捷開發過程中,每兩週都會有一場回顧會議(retro),PO、UX、RD、QA 會針對該 Sprint 進行檢討和反思,這篇想記錄以產品經理(PO)的角度常被提到的檢討點,一方面是幫助自己成長,另一面是更濃縮自己的產品想法。 誰適合看這篇文章?✔ 對產品經理、產品企劃、產品策略、產品規劃有興
Thumbnail
本文探討了企業內部的回饋制度運作情況,指出缺乏日常的回饋將導致同仁無法清楚知道自身哪裡需要改善,進而影響績效。本文推薦了《麥肯錫主管意見回饋術》這本書,強調透過回饋提供每位同仁成長機會與適當建議。最後,作者提出了做好意見回饋的六個關鍵及意見回饋的四步驟,以及強調回饋作為領導力的基本功。
Thumbnail
絮絮叨叨說了這些,就像是在對過去說道別,打包放入記憶庫,歸攏架上,等到哪日再翻找出來回味。放下過去,迎向未來,說起來很簡單,但身處其中自有其箇中滋味,因為心中知道,走出去到其他地方,雖然不至於斷了聯繫,但也曉得時間會沖淡這一份熟悉感,慢慢變得模糊直至難以辨認出原始模樣。
選商會議最重要的三件事: 1。 讓與會的主管和使用者在最短的時間裏瞭解系統功能。 2。 讓與會人員有初步的互動機會,瞭解對彼此的基本看法。 3。 評分,建立一張表格來評分。 經由評分,就有比較客觀的依據來選擇專案成員最希望合作的廠商。 確定議約廠商後,就進入議約階段。
凡是專案,就一定有啟動會議。 啟動會議最主要的目的是讓專案成員、利害關係人齊聚一堂、互相認識,瞭解專案的目標、工作大項、程和里程碑,最重要的是要爭取功能主管對專案的支持,能夠派出成員利用在原部門工作的時間來參與專案。 ERP專案的啟動會議有兩次。
kick off meeting啟動會議是什麼?有什麼用?我們可以怎麼開展kick off meeting?跟著我們一起8步驟學會規劃啟動會議!通過不同類型的kick off meeting 範例分析進行學習,掌握啟動會議每一流程!更有高效會議規劃工具推薦,一鍵生成會議紀錄!