프로젝트 회고의 중요성
앞으로의 원활한 프로젝트 진행을 위한 디딤돌이 되는 과정
지금 나는 작년 하반기에 이어서 방금 큰 프로젝트(A프로젝트)를 하나 끝낸 참이고, 그 프로젝트의 연장선인 또 다른 프로젝트(B프로젝트) 진행을 준비하고 있다. 지난주에 킥오프를 진행했고 이번주부터 본격적으로 프로젝트를 진행한다. 1년 정도 길게 바라보는 큰 프로젝트라서 이번에서는 이전의 실수를 최소화하고 싶었다. 그러기 위해서는 A프로젝트를 돌아보고 고칠 점을 파악하는 [회고]를 해야 할 것이다.
회고를 왜 해야 하는가
회고(回顧). 사전적 의미로는 뒤를 돌아본다, 지나간 일을 돌이켜 생각해 본다는 의미가 있다. 이를 일하는 데에 적용해 보자면 업무 또는 프로젝트 하나를 진행하고 마치면서 그 프로젝트를 어떻게 진행하고 어떤 실수가 있었는지, 어떤 결과를 도출했으며 앞으로 이를 토대로 어떻게 발전시킬지를 얘기하는 과정이다. IT업계에서는 개발 조직이 프로젝트를 진행하는 데의 일련의 과정으로 회고를 진행하고 있는 경우를 많이 볼 수 있다. (개발 조직에서의 회고의 의미, 그리고 회고를 진행하는 꿀팁은 이 링크를 추천한다 : 인프런 기사 “개발자의 공유문화 이모저모 (2) 회고문화)
나는 일하면서 회고를 꽤 여러 번 진행했는데, 크게 나누자면 아래와 같이 나눌 수 있다.
1. 조직 내 회고
- 조직 내에서 기간별로 했던 업무들을 돌아보고 다음을 위한 목표를 개개인이 세우고 공유하는 자리.
- 우리 팀은 1달에 1번씩 진행하고, 조직 규모에 따라 분기별로 진행하기도 한다.
2. 프로젝트 회고
- 하나의 큰 프로젝트를 진행하고 나서 업무를 진행한 담당자나 유관부서끼리 모여서 진행하는 회고.
- 정기 행사는 주기적으로 회고를 진행하기도 하며, 큰 캠페인 역시 실적 공유 등을 위해 회고를 진행한다.
조직 내 회고 같은 경우 예전에 있던 팀에서부터 항상 진행하는 회고 방식으로, 구성원이 진행했던 업무에서 주요한 업무에 대한 회고(좋았던 점 나빴던 점)를 진행 후 이를 기반으로 다음에는 어떤 점을 고칠지 등을 얘기했다. 점점 구성원이 많아지면서 회고가 거의 타운홀 규모로 진행되기도 했지만(지금 팀은 규모가 훨씬 작아져서 진행이 수월해졌다) 1달 동안 일했던 나 자신의 모습을 돌아보면서 “다음에는 이렇게 해 봐야지” “다음에는 이러지 말아야지”가 명확해져서 이전의 실수나 잘못을 되풀이하지 않는 데에 큰 도움이 되었다.
프로젝트 회고는 실적 공유의 목적이 커서 사업 부문(마케팅, 기획 등)의 주최로 진행되는 경우가 많다. 그러다가 이전에 진행한 정기 이벤트 회고에 들어가게 되었는데(마케팅, 사업기획, MD, 디자인에서 진행) 생각보다 좋은 인사이트들을 많이 얻을 수 있었다. 디자인 조직에서 보기 힘든 실적 수치, 배너 클릭률, 쿠폰 다운로드 수 등. 회고를 보다 보면 디자인이 이런 영향을 미쳤으며, 앞으로 이렇게 진행했으면 하는 타 부서의 의견도 듣게 된다. 그리고 이 의견들을 모여서 다음 디자인에 적용되는 좋은 밑거름이 된다.
두 회고가 진행하는 목적이나 방식의 차이가 있을지는 몰라도, 이 회고들의 공통점은 [다음 업무 진행을 위한 발판]을 파악할 수 있다는 것이다. 개인의 업무를 위해서, 프로젝트의 결과를 위해서 지난번의 행동을 돌아보고 해야 할 것, 하면 안 되는 것을 명확하게 머릿속에 새긴다. 나에게는 특히나 지난번에 했던 실수나 잘못을 다음번에 하지 않기 위해 회고를 하는 목적이 제일 크다. 그래서 회고가 중요하다.
다음 프로젝트를 더 잘하기 위한
나 혼자 해보는 회고
A프로젝트를 함께 진행했던 TF는 프로젝트 결과물을 최종 배포하기도 전에 해체했기 때문에 회고를 별도로 진행하진 못했다. 대신 TF 사람들이 각자의 조직으로 돌아가서 개별로 TF 업무에 대한 회고를 진행했다고 한다. 나는 TF에 대한 회고를 조직 내 회고로만 작성해서 전체 프로젝트에 대한 것은 진행하지 않았지만 이후의 B프로젝트를 진행하면서 실수를 최소화하기 위해 나 혼자 A프로젝트에 대한 개인적인 회고를 써보려 한다. 이 지극히 개인적인 회고는 인프런의 개발자 회고 방식 중 KPT 방식을 차용해 보았다. (자세한 사항은 위에 달아놓은 링크 참고!)
[잘한 것]
- 그동안 오랫동안 정리하지 못했던 컴포넌트 개념을 정리하고 일원화했다. 그 와중에 디자인 개편도 진행해서 해당 컴포넌트에 대한 가이드와 정책을 명확시했다.
- 디자이너와 마케터가 컴포넌트에 대해서 그동안 후순위로 미뤄두었던 [사용성]에 대해 깊게 고민하고 디자인에 반영할 수 있었다. (유저 테스트가 큰 도움이 됨)
- 유관부서와의 미팅을 주기적으로 진행함으로써 그들이 이 컴포넌트에서 어떤 정보를 보여주고 싶어 하는지, 어떤 정보를 더 중요하게 생각하는지 들을 수 있었다.
- 결국 컴포넌트를 제일 많이 사용하는 사람은 디자이너이기 때문에 최종 배포 전에 실무 테스트를 진행 후 리뷰 미팅을 마련해서 의견을 들었다.
- 원활한 소통을 위해 서포트 채널을 만들어서 해당 채널에서 모든 문의를 받게끔 소통 채널을 통일했다.
[못한 것]
- 프로젝트 로드맵을 제대로 그리지 못한 상태에서 시작해서 많이 헤맸다. 로드맵이 명확하지 않으니 일정이 감이 잡히지 않고 점점 늘어진 것 같다.
- 주니어 디자이너들이 디테일한 부분을 볼 때 내가 큰 그림을 보고 방향을 잡아주지 못했다. 나도 주니어처럼 갈피를 잡지 못하고 헤맸다.
- 위에서 얘기한 사용성을 개선시키기 위해 프로젝트를 진행하는 사람들 모두 사용자 경험에 대한 공부가 필요하다. 나 역시 이 부분이 부족하다.
[앞으로 해야 할 것]
- B프로젝트에서는 각자 하위 프로젝트를 진행하는 주니어들이 각자 로드맵을 정하게 유도했는데, 이들이 헤매지 않게 로드맵 전체를 관리하고 잘 진행되게 도와주기.
- 주니어들은 아직 사용자 경험에 대한 배경지식이나 업무 경험이 부족하다. 이 역량을 늘리기 위한 스터디 방식 고민해 보기.
- 서포트 채널을 운영한다 해도 마케팅 부서의 컴포넌트에 대한 이해나 소통이 아직 부족한 것 같다. 마케터와도 적극적으로 소통하고 서포트 채널로 문의하도록 유도하기.
- 컴포넌트를 만들어도 정작 디자이너 외의 유관부서가 모르면 절대 소용없다. 디자이너뿐만 아니라 유관부서도 컴포넌트를 잘 이해할 수 있게 꾸준히 공유하기.
음… 쓰다 보니 생각보다 꽤 길어졌는데? 하지만 마케팅 디자이너 입장에서는 꽤 길게 진행한 프로젝트에서 느낀 점은 정말 많았고,(보통 마케팅 업무는 단기간 내에 빠르게 진행된다) 무엇보다도 글로 쓰고 정리해 놓으니 그동안 머릿속에서 떠돌기만 했던 반성의 흔적들이 한눈에 보이고 이를 통한 개선점도 더불어 빠르게 파악할 수 있었다.
이제 3월 말이다. 우리 조직은 4월 초에 3월 회고를 진행할 예정이다. 아마 위의 회고 내용을 3월 회고 문서에 적어놓고 팀 사람들에게 공유할 것이다. 그리고 4월에 그 회고를 토대로 프로젝트를 이끌어 나가겠지. 하지만 나는 4월의 나를 바라보는 것이 아니라, B프로젝트를 진행하는 미래의 나를 바라보고 이 회고를 적은 것이다. 이후의 내가 실수를 했다 생각했을 때 이 회고글을 꺼내보면서 “아 이렇게 하려고 했었지!” 하고 마음을 다잡고 더 나은 모습으로 일하기를 바란다.
