前言
前文(*1)分享到，與其快速啟動PDCA領導團隊不斷解決program中大大小小不同的課題，最重要的是，需要汲取、反思之前曾遇過的突發事件，並誠心檢討、改善，以期日後在program中﹝甚至公司其他專案﹞都不會再有類似問題一再發生。
聽起來很合理、也很美好，這樣就天下太平了，不是嗎？
The Difficulties of A True/Effective Retro
跨不同公司文化差異
能不能「對事不對人」的關鍵，主要在企業文化、組織風氣是否能夠容許犯錯，讓員工、流程能在執行專案的過程中，同步成長；這個文化，對於公司在開創新的領域，是非常重要且關鍵的。但老實說，不是所有的領導者都有這個風範跟思維；導致有許多公司在成長轉型的過程中，成果不如預期。其實硬實力是一件事，甚至業界許多可以透過購併達成技術/市場的短時間目標。但長期而言，若領導人的視野、公司文化、組織體質沒有跟著轉變，大部分很難再創巔峰。
To Have Constructive Actions/Results is Not Easy
如何「客觀地」敘述一個事件的前因後果，完整還原時間順序、以及專案團隊成員間的處理過程，非常困難，很容易陷入團隊成員相互指責的迴圈：因為XXX當初沒有這樣、所以導致這樣的結果；如果是YYY處理，就不會這樣等等云云。所以我很推薦這篇文章 Blameless Culture Should Be a Standard for Engineering Industry (*2)。不要避重就輕、誠實帶領團隊成員面對錯誤，才能夠改進流程、不斷提升自己及團隊的硬實力或公司內部組織。
Time Constraints
通常問題發生的當下，Program Manager通常會帶領團隊趕快擬好mitigation plan & work on the solutions. 但船過水無痕，一旦解決了燃眉之急，原本十萬火急風風火火的團隊成員，瞬間都變成了慈眉善目話家常的好朋友，沒人想要再揭瘡疤–但也就是因為這樣，同樣的錯誤不斷在專案中重演，Program Manager整天忙著撲火、卻沒有想過好好地將lesson learned記下來、確實讓團隊成員成長。
我如何做retrospective
通常，我會用一個retrospective template﹝網路上許多範本可以參考﹞，先請事件(incident or technical issue)發生的主要相關成員共同協作出主要的時間軸、發生的問題、以及成員在其間的處理因應措施等。當然除了檢討事件外，還是得從正面角度先給一些正面鼓勵，如在事件處理因應中那些做的「好」的，先讓大家給予掌聲；但那些亟待改善的﹝做的不好的﹞，一樣讓cross-functional team members 分開input覺得可以導入的改善流程、品質驗證措施、或是設計checklist 等等等。當然，我非常建議當事件發生、處理得差不多的時候就可以開啟retrospective (or so-called post-mortem)；否則事過境遷，真的想要還原事件真相，可說是比登天還難！
若是涉及像我先前提到的，跨公司間的團隊合作專案需要做cross-company retrospective的話，也建議將至少中階主管﹝director level﹞邀請進會議討論；不是為了打小報告，而是為了增加一些管理階層的面向、甚至公司business等的討論，改進計畫會更加全面而有效，而非流於形式。
(*1) PDCA? PDCA-R Will Do Much Better!
(*2) Blameless Culture Should Be a Standard for Engineering Industry
一個PM的心路歷程 