프로젝트 회고를 합시다
Project Retrospective
우리는 모두 살면서 나 자신을 돌아보는 회고의 시간을 가진다. 나는 하루에 한 번 업무 시간이 끝난 후 오늘 한 일과 내일 할 일을 전반적으로 정리하며 혹시 놓친 것은 없는지 체크한다. 그리고 분기가 끝날 때, 또는 연말 등 특정 시점에 회고의 시간을 가진다. 다이어리에 글로 적기도 하고, 잠자기 전 누워서 머릿속으로 되돌아보기도 한다. 이처럼 나 자신에 대한 회고는 누가 시키지 않아도 본인의 필요에 따라 자연스럽게 하지만, 여럿이 참여하는 회고는 누군가 주도해야 진행된다.
그래서 PM이 프로젝트 종료와 같은 특정 시점마다 회고를 진행하고, PM 없이 팀끼리도 회고를 자연스럽게 진행할 수 있도록 이것을 하나의 조직 문화로 만들어야 한다. 즉, PM이 주도해서 억지로 참여하는 회고가 아닌 필요에 의해 자발적으로 회고가 진행될 수 있도록 분위기를 형성해야 한다. 이를 위해서는 우선 주최자인 PM이 회고란 무엇이고 왜 필요한지 명확히 알아야 하기 때문에 오늘은 회고에 대해 전반적으로 이야기하려고 한다.
프로젝트 회고란,
'회고'의 사전적 의미 : 지나간 일을 돌이켜 생각하는 것
프로젝트 회고는 프로젝트 생명주기의 특정 시점에 프로젝트 구성원들과 함께 프로젝트의 진행상황 또는 결과물을 돌아보는 시간(미팅)이다. 회고의 시점 및 참석자, 진행 방식은 주최자인 PM이 정할 수 있다.
회고 시점(When)
회고의 시점은 구성원들과 협의하에 정할 수 있으며, 보통 애자일 조직에서 팀 단위로 회고를 진행할 때는 Sprint가 끝나는 시점에 지난 스프린트 회고를 진행한다. 프로젝트 단위로 진행하는 회고는 PM이 시점을 정하면 되고, 나는 보통 ①개발 완료 후, ②프로젝트 종료 후 이렇게 두 번 진행하고 있다.
처음에는 스프린트 종료되는 시점마다 프로젝트 회고를 진행했는데 2주에 한 번씩 회고를 하니 주기가 짧아서 참석자들이 매번 지난 회고와 동일한 이야기만 공유하고, 회고 자체에 부정적인 인상을 심어주는 것 같아서 주기를 늘려야겠다고 생각했다. 그래서 프로젝트 회고는 Sprint나 Monthly와 같은 주기에 맞춰서 진행하기 보다 개발, 런칭과 같이 큰 이벤트가 완료된 시점에 진행하는 것을 추천한다.
회고 참석자(Who)
프로젝트 팀원과 스테이크 홀더들로 구성되며, 어느 시점에 어떤 주제로 진행되는지에 따라 PM이 참석자를 조정할 수 있다. 또한 회고를 offline(대면)으로 진행하는지 online(화상)으로 진행하는지에 따라 최대 몇 명의 참석자를 수용할 수 있는지가 달라지기 때문에 시기 및 상황에 맞게 참석자를 조정하면 된다. 다만, 참석자들은 회고를 왜 하는지와 회고를 통해 얻는 게 무엇인지 알고 있는 사람들이어야 한다. 그래서 사전에 참석자 중 회고가 처음인 사람이 있는지 파악하고, 회고에 대해 싱크업 할 필요가 있다.
결국 회고 참석자는 시점, 주제, 방식, 그리고 당시의 특수한 상황(예. 런칭 후 다음 Phase 개발이 시작되어 엔지니어들의 참석이 어려운 경우)에 따라 조정될 수 있으며 아래와 같이 두가지 예시를 만들어봤다.
픽토그램 출처: www.flaticon.com예시 1. 개발 완료 회고
개발 완료 시점에 진행하는 회고는 기획부터 개발을 완료하기까지의 좋았던 점, 문제점, 개선해야 할 점을 이야기하는 자리이므로 실제로 개발을 한 엔지니어들이 참석해야 한다. 다만, 엔지니어들이 모두 들어오면 인원이 최소 15명 이상이므로 오프라인보다 온라인으로 진행하고, 1명당 3분씩 발언할 것을 고려하여 회의 시간을 길게 세팅해야 한다. 그리고 회고를 진행할 때 1명당 주어진 시간을 넘기지 않도록 말을 끊을 필요도 있다.
픽토그램 출처: www.flaticon.com예시 2. 프로젝트 종료 회고
프로젝트 런칭 후 진행하는 프로젝트 종료 회고는 소규모 인원(리더급)으로 구성하여 오프라인으로 진행하는 것이 좋다. 물론 엔지니어들까지 포함하여 오프라인으로 진행해도 좋지만, 대면으로 15명 이상의 인원을 통솔하며 2시간의 회의를 이끌어가는 것은 어렵기도 하고, 참석자가 많으면 회고의 의미가 희석될 수 있다.(사공이 많으면 배가 산으로 간다) 때문에 대면 회고는 최대 10명으로 1시간 진행하는 것이 적당하다고 생각한다. 물론 이 이상의 멤버도 통솔할 수 있다면 얼마든지 추가해도 된다.
엔지니어들을 제외한 대신 프로젝트 런칭에 큰 기여를 한 다른 구성원을 초대하는 것을 추천한다. 예를 들어, BM이나 프로젝트 전담 Legal(변호사), QA 등이 있다. 다만, 대면 회의인 만큼 회고에 적극적으로 임하고, 회고를 하는 이유가 내재화된 사람들로 구성해야 한다.
회고를 하는 이유(Why)
회고를 진행 하기 전, 회고 참석자들은 '회고'가 무엇이고 왜 진행하는지 충분히 이해하고 회고에 참석해야 한다. 그래서 회고를 어떻게 진행할 것이고, 회고에서 어떤 것을 이야기하면 되는지 간단한 가이드 문서(Wiki)를 만들어서 배포하는 것이 좋다.
모든 가이드는 심플해야 한다나는 전통적인 회고 방법론인 KPT를 기반으로 좋았던 점, 문제였거나 부족했던 점, 부족했던 점을 개선하기 위해 시도할 수 있는 것들에 대해 생각해오라고 가이드 했다. 우리는 이를 통해 아쉬웠던 부분을 바로잡고 프로젝트가 좋은 방향으로 발전할 수 있도록 개선할 수 있다.
회고 방식(How)
회고에는 KPT, AAR, 4L, 5F 등 여러 방법론이 있는데 그중 가장 많이 사용하는 방법론은 KPT이다. 회고 참석자들은 아래의 가이드에 맞춰 KPT 아이템을 각 1개 이상 작성하고, 돌아가면서 이야기한다.
Keep
좋았던 점을 기반으로 도출하며, 앞으로 프로젝트를 진행할 때 계속 유지해야 할 사항
Problem
아쉬웠던 점을 기반으로 도출하며, 앞으로 프로젝트를 진행할 때 개선되어야 할 사항
Try
Problem을 기반으로 도출하며, 다음 프로젝트에 적용해 볼 만한 Action items
온라인 회고는 상기와 같이 피그잼을 이용하면 화이트보드에 포스트잇을 붙이는 느낌을 주면서 지루하지 않고 재미있게 진행할 수 있다. 오프라인 회고는 우선 화이트보드가 있는 회의실을 예약하고, 참석자들에게 포스트잇과 볼펜을 나눠주고 5분 정도 KPT를 작성할 수 있는 시간을 준 다음, 돌아가면서 이야기하면 된다.
바쁘다 바빠 현대사회에서 이미 지나간 일을 시간을 내서 되돌아본다는 것은 결코 쉬운 일이 아니다. 하지만 프로젝트가 종료됐다고 해서 프로젝트 구성원들과의 관계가 끝나는 것이 아니고 다음 Phase 또는 다른 프로젝트에서 언제든 만날 수 있는 사이이기 때문에 각자 이번 프로젝트를 통해 배운 것, 느낀 것을 공유하고 공감하는 시간이 필요하다. 그리고 아쉬웠던 점, 부족했던 점에 대해 이야기하고 이것을 개선할 수 있는 액션 아이템을 함께 도출하여 다음 프로젝트에 적용해야 한다. 즉, 우리는 회고를 통해 프로젝트와 조직을 더 좋은 방향 발전시키고 성장시킬 수 있다. 다만, 이렇게 추상적이고 이상적인 것 말고 실제로 회고에 참여한 구성원들에게 회고가 의미 있는 시간으로 기억될 수 있도록 PM이 잘 리딩 해야 한다.
