요새는 정말 작은 스타트업이더라도 회고하는 곳이 많아진 것 같습니다. 이번에 무엇을 잘했고(Keep), 못했고(Problem), 개선해볼지(Try) 이야기를 나눈다는 것은 앞으로 일함에 있어서 성장을 가져다 줍니다. 그래서인지 멘토링을 하다보면 회고에 대한 이야기가 많습니다. 하지만 회고를 통해 변해가고 있냐 물어보면 부정적인 답변들을 들려줍니다.
감정적인 하소연만 하다가 회고 시간이 다 끝나서 회고를 해야할지 모르겠어요.
회고를 하면서 감정적인 하소연을 100% 없애는 것은 어려운 일입니다. 특히나 흔히들 사용하는 KPT 회고 방식의 경우 Problem을 이야기 할 때 "누가 무엇을 안해줘서/누가 이런 것을 해결해주지 못해서 내가 무엇때문에 힘들었다"라고 이야기를 안하는 사람을 거의 본 적이 없습니다. 이렇게 되면 서로 감정적인 하소연이 주가 되기 때문에 회고가 끝난 다음에 나도 모르게 내 기분이 상해 있게 됩니다. 이럴 경우 시간을 내서 회고를 한 목적이 없게 됩니다. 그렇기 때문에 회고를 하기 전부터 회고에 참여하는 사람들은 마인드셋을 바꾸고 참여하는 것을 권장합니다. 회고를 하기 전 반드시 가져야 할 필수적인 사전 과정 중 하나는 감정을 빼고 당시 상황을 종이에 작성해본다입니다. 예를 들면 "나는 xx월 xx일 마감해야 하는 A 업무에 대해 yyy 정보가 필요했으며, 그것이 zzz에 도착해서 n일이 지연되게 되었다." 입니다. 이렇게 하는 이유는 감정을 제외하고 내가 모르는 상황을 유추하지 않게 하여 결국 내가 겪은 상황에만 집중하게 만들기 위함입니다. 이런 선행 작업이 있는 상태에서 회고를 하면 상황들만 모이게 되며, 그 상황들을 같이 모여서 퍼즐을 맞추며 업무 프로세스 중 어디가 문제였는지를 빠르게 파악할 수 있습니다.
저희 회사도 회고를 하긴 하는데 액션아이템을 잡기가 정말 어려운 것 같아요.
- 기획자 Q : "저는 기획안을 일정 내로 주었는데 개발이 엄청 늦어졌습니다. 이게 고쳐졌으면 해요."
- 개발자 A : "기획이 너무 커서 개발하는데 일정이 부족했습니다. 기획이 커지지 않도록 앞으로는 초반에 확실히 안된다고 말할 거예요."
- QA 엔지니어 C : "검증 전에 개발 산출물들이 다 나왔어야 했는데 개발팀이 전달해주지 않았습니다. 그래서 제 액션 아이템은 개발팀이 문서를 빨리 줄 수 있도록 프로세스를 개선하는 것입니다."
실제 대부분 팀들이 회고하는 내용을 들어보면 위와 크게 다르지 않습니다. 공통점 하나가 보이실까요? 바로 우리/내가 바꿀 수 없는 큰 주제들을 문제로 이야기하고 있다는 점입니다. 우리/내가 바꿀 수 없는, 권한 밖의 이야기들, 남들이 변해야지만 내가 달라질 수 있는 아이템들을 액션아이템으로 잡으려고 하면 회고의 효과를 검증하기 어렵게 됩니다. 또한 모든 것이 장기적인 플랜이 될 수 밖에 없습니다. 그렇기 때문에 회고를 할 때 우리가 다뤄야 할 주제는 단기간에 내가 바꿀 수 있는 것들이어야만 합니다. 회고를 하는 이유는 우리/내가 변화되어서 팀이 더 성장하는 모습을 기대하기 때문입니다. 이러한 효과를 느끼지 못하는 회고는 하지 않는 것이 좋습니다. 그러면 아예 단기간에 내가 바꿔야 할 것들만 이야기해야 하는가?라고 물어보신다면 그건 아닙니다.
회고를 할 때 상황이 변화하기 어렵다는 전제로 내가 그 상황에서 단기적으로 어떻게 할 것인지, 대응할 것인지가 중심이 되어야 한다는 뜻입니다. 나 -> 유관 부서, 단기 -> 장기로 총 9개의 영역을 순서대로 이야기를 나눠야 회고 후 내가 앞으로 내 스스로 팀의 효과 향상을 위해 어떻게 일할 것인지 액션 아이템을 세울 수 있습니다.
디스코드 커뮤니티 안내
PM & PO 직군의 취직, 이직, 커리어를 같이 이야기할 디스코드를 운영 중에 있습니다. 그 외 많은 정보가 디스코드에 있으니 많은 관심 부탁드립니다.
