產品、流程與團隊的回饋節奏
最近因為有新產品經理（PM, Product Manager）加入團隊，調整了一些產品的開發流程。為了讓團隊成員有更多溝通和討論的空間，我們也引入了一些討論與會議框架，來掌握開發節奏與溝通效率。
進行了幾次產品與團隊檢討會議後，我發現團隊們對於要如何進行討論還有優化空間。主要的問題在於團隊進行檢討時，很容易把針對「產品」、「開發流程」與「團隊」的反饋與檢討混再一起討論。這麼做很容易讓目標變得模糊，團隊成員也不容易在每一次的開發過程中迅速地學習。
舉例來說，在針對「產品」的討論中，我們希望能夠針對產品是否解決消費者的問題進行討論，如果這時候團隊成員們對「我們是否有更好的開發流程」、「我在開發過程中感覺到被充分支援」、亦或是「我覺得這次的產品好無趣」進行討論，就很容易失焦；相對的，在對「團隊」進行回顧的時候，我們則更應該將重點放於「團隊成員」而非「產品」。
要能充分討論不同的問題的回饋與解決方案，對於不同的會議主題應該要有清楚的了解。有了明確的會議目標，團隊成員們才能有效地提供想法。我在本篇文章介紹三個不同的會議形式：成果審查會議（Result Review）、流程回顧會議（Process Retrospective）和團隊健康檢查（Team Health Check），來協助大家更清楚了解。
- 成果審查會議（Result Review）讓團隊能夠對內或外展示完成的任務與產品；
- 流程回顧會議（Process Retrospective）重點在回顧產品開發與推進任務的過程中，我們有哪些做得好與需要改進的部分，專注在輸入、流程、協作與產出；
- 團隊健康檢查（Team Health Check）則是對整體團隊狀況進行全盤了解，如目標掌握、團隊成員是否有學習與成長、使命與價值、內外部合作、品質與債。
成果審查會議（Result Review）
「我們來交貨啦！來看看是否滿足你的需求吧！」——成果審查會議（Result Review）。
成果審查會議（Result Review）是三個中最容易理解的，在 Scrum 敏捷開發中，他同等於 Sprint Review。辛辛苦苦跑完一個 Sprint（完成一個階段的產品開發），成果審查會議讓團隊能夠在產品負責人、利害關係人（例如其他行銷團隊負責人）與全體團隊成員面前，展示（Demo）產品完成的部分，並確認是否符合期待。透過與會者的產品開發經驗，審查團隊可以評估本次的開發品質是否有完成、品質是否恰當、是否需要新增額外的修改等相應反饋，並對產品進行後續開發規劃。
如 Scrum 敏捷開發方法中的 Sprint Review、電影的製片會議、產品展示會議等，都算是成果審查會議的一種。成果審查會議提供了一個良好的機會讓產品在交付前進行品質管理，並確保產品能夠被順利遞交，或必須因應狀況改變而做出其他修改，因而對後續的產品與開發進度進行調整。
在「成果審查會議」中討論：
- 展示產品完成的部分
- 評估現況與產品
- 是否對產品或 Backlog 進行新增或調整
流程回顧會議（Process Retrospective）
「我們來檢討看看如何把這次任務做得更好吧！」——流程回顧會議（Process Retrospective）。
在進行某個任務的成果審查會議之後，我們也許會發現一些開發流程值得改進的地方，而流程回顧會議（Process Retrospective）是針對這項任務進行改善檢討。舉例來說：規格在制定的時候有什麼不如預期的地方？開發的過程是否有遭遇到任何困難？新技術的導入是否順利？是否有遇到意外的 Bug？設計的難度是否比預想中高？或者一切都進行順利？流程回顧會議給了團隊一個深入瞭解並分析這個任務的機會，如果再來一次，你會做出什麼改變來讓結果更好？
流程回顧會議就像圍棋的「覆盤」，你坐下來，仔細思考可以從每一子的回顧中，學習到什麼？覆盤給予了團隊成員每一個人一起分析思考，並且討論與回顧這個棋局中的各種可能。我們是否可以做到更好？——如果設計改成這樣，開發速度是否可以提升？如果專案中的開發順序調換，是否可以提高穩定性？如果再開發初期就知道後期才得知的資訊，是否可以讓設計更為優異？
如 Scrum 敏捷開發方法中的 Sprint Retrospective 會議、公司營運會議等，都算是這種會議形式的一種。和團隊一起進行流程回顧會議，也更容易了解彼此在任務中遇到的困難，並更深入的了解每一個開發項目，並從過去的經驗中學習。
在「流程回顧會議」中討論：
- 我們在本次開發中，進行順利的部分。
- 我們在本次開發中，遭遇困難的部分。
- 我們在本次開發中，我們可以做得更好的部分。
- 我們可以在開發流程中新增什麼？
- 我們可以在開發流程中刪去什麼？
- 我們在本次開發中，沒有預期的部分。
- 我們在本次開發中學到了什麼？
團隊健康檢查（Team Health Check）
「一起來深入瞭解團隊成員的個別與合作狀況！」——團隊健康檢查（Team Health Check）。
相較於成果審查與流程回顧——團隊健康檢查（Team Health Check）回顧的是團隊本身——團隊是否具清楚了解產品願景？團隊是否認同自己開發的產品品質？是否在開發過程留下技術債？團隊認為產品的開發與遞交速度如何？團隊成員覺得有趣嗎？有學習到新事物嗎？需要支援的時候，能夠從團隊內或外得到適當的資源嗎？
畢竟先有團隊，然後才有產品。定期深入了解你的團隊的「健康狀況」，可以讓你更加了解要如何推動團隊往前邁進。
請注意，你不應該對團隊健康檢查的結果給予「獎勵」或「懲罰」，你希望團隊成員誠實以對——無論是他覺得這一季的產品品質其實很差、在跟同事的合作上沒有進展、或是單純覺得這個開發項目很無趣——團隊成員的表達你都認真聆聽，並且跟成員一起誠實面對。團隊健康檢查的重點目標是改善，但改善的前提是我們能夠誠實的面對問題。千萬不要為了讓他們「看起來好看」，而讓你或團隊成員們無法說出真心話。
另外，切記不要拿團隊健康檢查在團隊之間比較。某一個團隊在某些面向的反應比較差，可能只是他們對自己的標準更高，或是他們正在面對更難挑戰的問題。無論如何，每一個團隊健康檢查 的應用範圍應該只限於該團隊之中，目標在於討論後優化遇到的狀況與問題，而不是拿來與人比較。
在「團隊健康檢查」中討論：
- 你是否清楚了解產品願景與目標？
- 你覺得我們的產品有提供使用者（或消費者）價值嗎？
- 你覺得我們有留下任何債（為了完成目標而留下的待解問題）嗎？
- 你覺得這一季的任務有趣嗎？
- 你在這一季中有學到任何新事物嗎？
- 你在這一季中，有得到充足的團隊支援嗎？
- 你覺得團隊需要支援時，外部夥伴能提供充足協助嗎？
掌握正確的節奏
如果你的產品適合或你正在使用 Scrum 等敏捷開發法，也許二到四週進行一次成果審查（Sprint Review）、接著進行流程回顧（Sprint Retrospective），並每季一次團隊健康檢查是一個很棒的方法。但如果你在進行其他類型的產品或任務，你也可以任意的調整上述的節奏，盡量確保成果不會累計太多才審查，並在完成 1-3 次成果審查後進行一次流程回顧，並在 3-6 次成果審查後進行團隊健康檢查，會是比較恰當的節奏。
| Examples | 產品團隊 | 設計團隊 | 行銷團隊 |
| 成果審查 | Sprint Review | 作品審查 | 行銷提案報告 |
| 流程回顧 | Sprint Retrospective | 設計流程檢討 | 提案或合作流程檢討 |
| 團隊健康檢查 | 團隊健康檢查 | 團隊健康檢查 | 團隊健康檢查 |
團隊健康檢查的週期一般來說比流程回顧會議更長。過度進行團隊健康檢查可能會讓團隊感到疲乏，畢竟團隊狀況的改善不像產品那樣直接，如果我們再一次團隊健康檢查中發現的問題，需要保留足夠的時間消化與解決。
雖然三種會議形式有著不同的主題，但請記得，不要因為有了不同的會議主題而扼殺團隊成員希望提供意見的機會。建立團隊的溝通模式是一個持續的過程，也許團隊成員在開發過程中有了重要的團隊疑慮，那麼即使沒有到進行團隊健康檢查的時間，你也應該要讓團隊成員充分發表回饋。
作為管理者，即使有了嚴謹的框架，你也應該保持彈性。你必須仔細聆聽回饋，並決定是否要優先解決該問題，或者讓問題等待下次的討論時間，讓產品與團隊都能持續保持順暢運作。
參考資料：