다음 프로젝트를 더 잘하는 방법
프로젝트 회고를 왜 해야하고, 어떻게 잘 할 수 있는지에 대하여
프로젝트를 할 때마다 '이번 프로젝트는 어떻게 더 잘할 수 있을까?' 에 대해 스스로에게 묻는 편이다. 하지만 종종 이런 고민들이 무색하게도 이전 진행했던 프로젝트보다 못한 경우도 발생하곤 한다.
어떤 프로젝트를 할 때는 '내가 이 일을 계속하는 게 맞나?' 하는 생각이 들 정도로 힘이 들 때가 있고, 또 어떤 프로젝트를 할 때는 '이 일은 내 천직이다. 너무 재밌다' 하는 프로젝트가 있다. 사실 이건 프로젝트의 문제보다도 같이 프로젝트를 하는 Makers의 영향이 큰 것 같다는 생각을 하게 된다. 하지만 모든 프로젝트를 잘 맞는 Makers와 할 수는 없으니 힘든 프로젝트를 조금은 덜 힘들게, 또는 이번보다 잘하고 싶으면 배포 후 회고는 짧게라도 하며 그들의 의견도 같이 들어보는 게 좋다고 생각한다.
회고를 하는 방법에 대해선 다양한 방법이 있고, 방법론에 대해 쓰인 좋은 글도 많기 때문에 그 글들을 참고하면 좋을 것 같고, 이번 글에서는 실무에서 회고를 어떻게 진행해야 하는지 그리고 어떤 진행 방식이 좋았는지 등에 대해 소개하려고 한다.
1. 프로젝트 진행 기록 (상황, 감정, 프로세스)
프로젝트 진행 시 단기 프로젝트는 1-2주 만에 배포할 때가 있고, 긴 프로젝트의 경우 6개월 이상 지속되는 경우도 있다. 보통 프로젝트의 기간이 길어질수록 챙길 것도 많고, 나도 힘들고 같이 협업하는 동료들도 힘들어지는 것 같다. 장기간 진행된 프로젝트의 경우 배포 후 회고 시점이 되면 '이 프로젝트가 왜 이렇게 힘들었지?'라는 질문에 스스로 답할 수 없는 경우가 많다. 프로젝트를 하며 힘들었어도 긴 시간 진행되었기 때문에 그때의 감정이나 힘들었던 이유가 세세하게 기억나지 않기 때문이다. 이렇게 되면 회고를 진행한다 하더라도 인사이트를 뽑아내어 개선할 점이 많지 않아진다.
이러한 문제를 해결하기 위해서 평소에 들여야 할 좋은 습관으로는 '메모하기'가 있다. 나는 보통 개인 노션으로 프로젝트를 진행하며 힘든 점을 적어놓고는 한다. 어떤 과제였는지, 무엇이 문제였는지, 그리고 무엇을 배웠는지를 생각날 때마다 적어두고 배포 후 회고 때 이야기한다.
개인 회고 템플릿 / 내용은 날 것이어서 히든처리..!처음에는 '누가 어떻게 해서 힘들다' '챙겨야 할 게 많아 지친다' 등 두루뭉술한 상황과 그당시 느꼈던 감정 위주로 적었는데, 동료 PO는 회고 전 일련의 상황과 감정들을 타임라인 형태로 적고 있는 걸 알게됐다. 타임라인 형태로 정리해놓으면 시간 단위로 어떤 부분이 어떻게 힘들었는지 한 눈에 구체적으로 알 수 있어 이 부분을 벤치마킹 해야겠다고 생각했다.
프로젝트 회고 전 개인이 정리해 놓는 방식은 정답이 정해져 있는 것은 아니므로 본인에게 맞는 방식으로 정리해 두면 되지만 '프로젝트를 진행했을 때 느꼈던 감정, 그때의 상황, 어떤 프로세스에서 야기된 문제인지'를 포함하여 적으면 훨씬 정리가 잘 된 상태로 회고에 참석할 수 있다.
2. 프로젝트 배포 후 회고 템플릿 작성
프로젝트 회고 템플릿은 팀마다, 담당 PO마다 본인이 원하는 방법론이나 스타일이 있어 이 부분에도 정답이 없다. 나도 회고를 많이 해본 것은 아니라 지금보다 개선해야 하는 부분이 많을 수 있지만 지금까지의 경험을 토대로 회고 템플릿 작성법을 말해보려고 한다.
진행 프로젝트명
진행했던 프로젝트명을 기재하여, 어떤 프로젝트의 회고를 진행하는지 알린다.
배포 일자
프로젝트의 배포일을 작성한다.
회고 일자
배포가 되었다면, 회고를 작성하는 일자를 작성한다. 보통 회고는 프로젝트 배포 후의 일정으로 잡아
프로젝트의 시작과 종료에서 발생한 모든 일련의 사건을 되돌아볼 수 있도록 한다. 또한, 회고 참석자
모두는 회고 작성일 전까지 문서를 작성토록 한다.
모니터링 결과
배포일자와 회고일자의 차이만큼 프로젝트를 모니터링할 수 있다. 예를 들어 9/1에 배포를 했고, 9/8일에
회고를 한다면 일주일치의 프로젝트 모니터링 결과를 간단하게 정리할 수 있다. 딥한 성과분석이 아닌
프로젝트 오픈 후 간단한 성과분석을 짧게 준비하면 이후 액션아이템을 도출하기에도 좋다.
좋았던 점
프로젝트를 진행하며 어떤 점이 좋았는지 최대한 구체적으로 작성한다.
예) 놓칠뻔한 케이스를 개발자와 QA가 크로스체크 하는 과정에서 발견하여 놓치지 않고 마무리했다.
개선할 점
프로젝트 진행 중 아쉬웠던 부분에 대해 구체적으로 작성한다.
예) 로그를 확인하는 과정에 시간이 많이 걸리는 편인데, 로그 누락이 많아 여러 번 체크해야 했다.
적용할 점
이번 프로젝트에서 적었던 좋았던 점과 개선할 점에 연결되는 부분으로 추후 프로젝트에 '적용하면
좋을 점'을 작성한다.
예) 기획 리뷰 단계, QA 리뷰 단계에서 놓치는 케이스가 없도록 크로스 체크 하는 프로세스를 추가하자.
개발 시, 로그명세서 맞게 로그 개발을 잘해뒀는지 개발자가 1차 체크 후 테스트를 요청하자.
Action Item
회고 중 나왔던 이야기 중 즉시 팔로업 가능한 부분이 있다면 액션 아이템 영역에 작성한다.
예) 멘션에 대한 확인이 늦을 경우, 팀 전체를 멘션 한다.
3. 프로젝트 회고 초대
프로젝트 회고 필참자는 보통 Makers이다. 경우에 따라 사업부나 마케터 분들을 추가로 초대하기도 한다. 나는 주로 프로젝트에 직접 참여한 동료는 필수 참석으로 초대하고, 해당 프로젝트를 발의했거나 프로젝트 오픈에 기여한 동료가 있다면 선택참석으로 초대한다.
필수 참석으로 초대 받은 경우는 회고록을 작성하고 회고시간에 필수로 참석해야하고, 선택 참석으로 초대받은 경우는 본인의 스케줄에 따라 참석 가능한 경우만 참석하면 된다.
4. 회고 진행
회고는 보통 작성된 문서 기반으로 PO가 리딩한다. 진행 방식은 본인 하기 나름인데, 나는 주로 좋았던 점을 먼저 쭉 이야기하고 그 다음 개선할 점, 적용할 점으로 순차적으로 이야기한다.
중요한 부분은 회고가 '감정적'으로 진행되지 않게 중간에서 최대한 컨트롤하거나 감정적으로 될 것 같으면 중간에 끊고 나서서 정리하는 것이다. 회고 진행 전 다시 한번 회고의 목적을 속으로 되새기고 참석하면 감정을 빼고 최대한 이성적으로 진행할 수 있다.
회고를 하다 보면 내가 잘 못한 부분이 있을 수도 있고, 동료의 행동이 잘 못됐을 수도 있다. 누구나 실수를 하고 어떠한 단점이든 갖고 있을 확률이 높기 때문에 단점에 포커스를 맞추려는 것보다는 우리가 가진, 또는 느낀 단점을 다음 프로젝트에 어떻게 커버할 수 있을까? 의 측면에서 많은 고민을 해야 한다.
그러니 회고를 진행하며 자칫 감정이 격해지거나, 누군가를 비난하려는 분위기가 생기면 중간에서 정리를 해주는 게 필요하다. 회고 시작 전이나 회고 중에 '회고의 목적'을 기억하는 게 중요하다. 우리가 회고를 진행하는 목적은 '누군가의 잘잘못을 따지는 것이 아니라, 다음 프로젝트 진행 시 서로의 핏을 더 잘 맞추기 위함'이다.
5. 회고에서 도출한 액션 아이템
회고를 하다 보면 생각보다 많은 의견들이 오고 가는데, 그중에서 지금 당장 할 수 있는 것들은 액션 아이템으로 정의한다. 액션아이템을 작성할 때는 담당자가 누구인지, due date가 있다면 언제인지 등을 함께 작성한다. 예를 들어, 회고 중에 티켓에 담당자를 멘션 했으나 담당자가 이틀이 지나도 답이 없어 진행이 더뎌졌다는 의견이 나왔다면 '멘션 알림을 쉽게 인지하기 위한 방법'에 대해 같이 논의하고, 합의한 결정에 따라 액션아이템을 정의한다.
여기서 액션아이템이 '멘션 알림은 이메일, 푸시 모드 켜둔다. 또는 멘션 알림에 답이 없을 경우 슬랙을 통해 담당자에게 한번 더 알린다' 등이 될 수 있다. 이 경우 알림을 확인하지 못하는 특정 담당자를 기재해 둬도 되고, 전체적인 문제라면 회고 필참자 전체에 해당하는 액션아이템이 되므로 필참자 전체를 멘션 해둔다.
그리고 꼭 다음 프로젝트가 아니라, 현재 하고 있는 프로젝트부터 가능하면 빠르게 적용하여 개선하려고 노력한다.
6. 마무리 및 실행
회고에서 좋았던 점, 개선할 점, 적용할 점을 모두 이야기했고 액션아이템까지 도출되었다면 각각의 task로 만들어서 관리할 수 있는 케이스가 있을 것이다. 예를 들어, 이번 프로젝트 진행하며 일정으로 인해 특정 기능을 제외하고 배포했다면 여기서 도출될 수 있는 액션아이템은 그 기능을 누가, 언제까지 운영에서 처리할 것인지이다. 이 경우는 명확하게 담당자와 due date가 찍혀있어야 진행 과정도 확인할 수 있고 배포일도 알 수 있으므로 티켓을 발행하여 관리하는 것이 좋다. 그럼 회고가 끝나면 액션아이템 중 티켓 발행이 필요한 것들에 대해 PO 또는 담당자가 티켓을 발행하고 담당자를 지정하고, due date를 지정해 놓고 운영 건으로 관리한다.
이렇게 되면 회고가 성공적으로 끝나게 된다.
마치며
여러 프로젝트를 병렬로 진행하며 프로젝트 진행하기에 너무 바빠서 회고를 진행 할 시간이 없다는 핑계로 회고를 스킵하고 그냥 지나가본 적도 있었다. 그러니 이전 프로젝트에서 어려웠던 점들을 다음 프로젝트에서도 동일하게 경험하는 경우가 발생했다. 회고를 진행할 경우 프로젝트 진행 시 내가 인지하지 못 했던 그들의 상황과 감정, 문제에 대해 인지할 수 있지만, 회고를 스킵 할 경우 이러한 상황을 인지하지 못 하므로 해결되지 않는다.
누구나 반복되는 문제를 싫어하고, 문제가 있을 경우 반복되지 않기를 기대할 것이다. 그리고 프로젝트를 하며 혼자 끙끙 앓고 있던 문제들, 누군가의 행동에에 실망하거나 화가 난 감정들을 풀지 못해 응어리진 채로 다음 프로젝트로 함께 하게 된다. 이렇게 되면 '프로젝트를 할 때 마다 매번 더 나은 프로젝트를 할 수 있을까?' 내 생각엔 No이다.
프로젝트는 혼자 하는 게 아닌 우리 모두가 함께 하는 것이므로 서로의 입장과 감정을 이해하고 이를 개선하며 더 나은 프로젝트를 만들어야 한다고 생각한다. 더 나은 프로젝트는 궁극적으로 더 좋은 성과를 갖게 하고 우리 비즈니즈 전체에도 도움이 되는 방향이기 때문이다.
오늘도 시간이 없다는 핑계 또는 불편하다는 핑계로 회고를 그냥 '지나치고 있다면' 다시 한번 멈추어 생각하길 바란다. '정말 이 시간들이 필요 없는 시간들일까' 하고 말이다.
