기획자가 지금 당장 프로젝트 회고를 시작해야 하는 이유
회고를 하고 있지 않는 조직에 몸담고 있다면 꼭 읽어보세요
"저희...이번 프로젝트 오프라인 회고 한번 해보면 어떨까요?"
프로젝트 팀원들을 한번도 대면으로 만나보지 않고 프로젝트를 무사히 끝마쳤다. 우리 회사는 자율적으로 재택근무를 할 수 있고, 중국 오피스에 계시는 경우도 있어, 거의 대부분 화상 회의와 메시지에 의지해 업무를 진행하고 있다. (목소리조차 들어본 적이 없는 팀원 분도 있다.)
내가 오프라인 회고를 진행하고 싶었던 이유
프로젝트는 비대면으로 잘 진행됐지만, 그래도 나는 우리 팀원들을 오프라인으로 만나보고 싶었다. 여기에는 여러가지 이유가 있다. 첫째. 누구의 말마따나 비업무적인 대화가 업무에도 도움이 된다는데, 나는 이들과 업무 이외의 대화를 해본 적이 없었다. 이분들은 이번 프로젝트를 처음으로, 앞으로도 나와 함께 이 모듈을 계속해서 맡아 진행해줄 든든한 지원군들이기에, 좀더 친해지면 좋을 것 같다는 생각이 있었다.
둘째. 프로젝트는 결과적으로 문제 없이 배포를 완료했지만, 그 과정에서 문제가 없었는지에 대한 피드백과 앞으로의 진행 프로세스를 정비해보고 싶었다. 나는 앱 개발자와 일을 한 경험이 많이 없었다. (거의 웹 개발자분들하고만 일했었음). 그래서 놓친 부분들이 왕왕 있었기에, 이런 부분에 대한 피드백도 궁금했다.
그래서 제안합니다. 오프라인 회GO!
그래서 나는 용기내어 회고와 함께 저녁 식사를 제안했다. 이게 뭐가 어렵냐 싶을 수도 있겠지만, 부끄럽게도 나를 포함해 우리 파트는 지금까지 개발자하고는 회고를 진행한 적이 없다. 이건 우리 파트의 특수한 케이스와 관계가 있다.
우리 파트 과제들의 경우, 범위가 크고 개발 파트도 커서 누가 개발을 맡게 될지 알 수 없다. 담당자도 바뀌는 경우가 많아서 과제 진행 시 One Team이라는 생각으로 과제를 진행하는 느낌이 아니다.
반면에 이번에 맡은 과제는 앞으로도 쭉 (퇴사 하지 않는다면ㅜㅜ) 함께 과제를 진행하게 될 것 같아, 용기를 내어보았다.
예상보다 반응이 좋았다.
생각보다 반응이 너무 좋았다. 다들 귀찮아하실 줄 알았는데 훨씬 적극적으로 식당도 알아봐주셨다. (회사 돈으로 밥먹을 생각에 신이 나신 것 같기도)
회고를 위한 사전 준비 (feat. 회고툴 써보기)
SaaS 서비스 회사답게 회고도 온라인 툴을 이용해보기로 했다. 이전부터 회고를 진행하면 써봐야지 하고 눈여겨보던 툴을 제안드렸고, 모두 흔쾌히 동의해주셨다.
Team Retro를 대해 간단히 소개하자면, 보다 효율적이고 효과적으로 프로젝트 회고를 진행할 수 있도록 회고 프로세스 전반에 걸쳐 사용할 수 있는 툴이다. 사용할 수 있는 템플릿의 종류도 많고, 회고 전, 회고 중, 회고 이후 단계 별로 가이드를 해주어서 우리 같은 회고 초짜에게 매우 유용했던 것 같다.
(유료인 점이 가장 아쉽다. 일단 우리는 Trial로 진행했다.)
우리는 회고 시간 이전에 미리 이번 프로젝트에 대해 1) 좋았던 점, 2) 아쉬웠던 점, 3) 다음에 시도해볼 만한 점, 4) 어려운 점 등을 함께 적어두고, 회고 시간에 함께 이야기 해보기로 했다.
Let's start 회GO
드디어 회고날이었다. 다들 실물로는 처음 보는 거라, 마치 연예인을 보는 느낌이었다... 프로필 사진은 분명 흑발이었는데 금발이었을 때 그 충격이란! "머리 색깔이 프로필 사진과 달라서 깜짝 놀랐어요~"가 절로 나왔다.
출처: 데브 경수 인스타그램 (@waterglasstoon)회고는 크게 3가지 단계로 나뉘어졌다.
1. 아이스브레이킹 : 처음 뵙겠습니다.
아무튼 처음보는 만큼 회고 전 아이스브레이킹이 필요하다고 생각했다. 그러나 정말로 초면인 사람들이기에, 너무 사적인 질문을 하는 것은 오히려 불편할 수 있다고 생각해, 이번 프로젝트 관련해 느꼈던 아무말 대잔치를 하기로 했다.
아무말 대잔치는 나부터 시작했다. 이번 과제를 온전히 내가 진행하기 위해 부단한 노력이 있었다는 것. 그래서 잘 해낼 수 있다는 것을 증명해야 하기 때문에 부담감이 있었지만, 개발 분들께서 적극적으로 스펙에 관여해주셔서 무사히 끝낼 수 있었다는 것. 그럼에도 불구하고 기획 각 파트에서 현황 취합이 안되어서 아쉬운 부분도 있었다는 점을 솔직하게 말씀드렸다.
이어서 말씀해주신 분들도 각자의 입장에서 있었던 고충과, 좋았던 점을 솔직하게 말씀해주셔서 화기애애한 분위기에서 회고를 시작할 수 있었던 것 같다.
돌이켜보면 어줍잖은 아이스브레이킹을 할 바에 이렇게 자유롭게 먼저 시작했던 점이 오히려 좋았던 것 같다.
2. 본격적인 회고: 놀라움의 연속
본격적인 회고를 시작했다. 회고 툴에 적어둔 내용들을 기반으로 함께 이야기했는데, 결국 비슷한 이슈별로 묶어볼 수 있었다. 좋았던 점들을 읽어보며 서로를 칭찬할 수 있었고, 아쉬운 점들을 읽어보면서 해결 방법을 찾을 수 있었다.
회고를 하지 않았다면 몰랐을 개선점들을 찾을 수 있었던 것이 큰 수확이었다. 특히 놀라웠던 점은, 회고가 아니었다면 전혀 발견하지 못했을 문제점들을 찾아낼 수 있었다는 점이다. 이 부분에 대해서는 아래 '회고를 하며 얻은 것'에서 더 자세히 다루도록 하겠다.
3. 서비스 로드맵: 우리는 한 배를 탔어요.
이번 회고에는 사실 더 큰 목적이 있었다. 우리 팀원들이 우리 서비스에 대한 방향성을 이해하고, 이를 위해 하고 기획에서 준비하고 있는 일들을 통해 하나의 프로덕트를 만들어가는 Team 의식을 만들고 싶었다.
나는 우리 팀원들이 단순히 기획서에 있는 내용을 구현하는 일에만 머물게 하고 싶지 않다. 더 큰 숲의 관점에서 이 기능이 왜 필요한지, 앞으로는 어떤 기능이 추가로 들어갈지 미리 예상을 하고 개발하실 수 있도록 하고 싶었다. 그리고 지금까지 일을 하면서 우리 팀원들은 그런 부분에도 충분히 관심이 있는 개발자분들인 것 같다는 생각이 들었다.
우리 서비스의 로드맵과 현재 기획팀에서 하고 있는 일들을 공유드리니, 흥미로워하셨다. 그리고 앞으로 우리 서비스가 이렇게 되어야 한다는 것에 공감해주셨다.
내가 이 서비스를 처음 맡을 때만 해도 이 서비스는 운영성 업무가 주였다. 그리고 지금은 이 서비스가 좀 더 발전할 수 있다는 사실에 사내의 많은 사람들이 공감하고 있다. 그러나 나는 서비스를 함께 만들어 나가는 사람들이 나의 방향성에 공감해줄 때 더 많은 용기가 생긴 것 같다.
물론 벌써부터 구조개선할 생각에 서버 개발자분은 살짝 두렵다고도 말씀해주셨다 ㅋㅋ
회고를 하며 얻은 것
회고를 하며 생각보다 많은 것들을 배우고 얻었다.
1. 기획 및 개발 프로세스에서 고쳐야 할 점
첫번째로 회고를 하면서 더 확실하게 깨달았던 점이, 스펙에 대해 잘 알고 있는 사람은 리더가 아닌 실무자라는 것이었다. 나는 여태까지 각 개발, 기획 리더하고 커뮤니케이션 했던 적이 많아서 과제 리뷰와 의견 취합을 모두 각 파트 리더에게 요청을 드렸었다.
그러다보니 리더가 스펙에 대해 잘 몰라 누락된 스펙이 있기도 했고, 초기 개발 리뷰때 실무 개발자분들이 과제 리뷰에 참여하지 못하기도 했다. 과제 리뷰를 요청드릴 때 늘 그렇듯 개발 리더님을 초대드렸는데, 개발 리더님께서 실무 개발분들을 초대해주시지 않았던 것.
이 부분은 앞으로 내가 더 잘 챙기는 것이 맞다는 생각이 들어서 앞으로는 기획, 개발 모두 실무진들 위주로 커뮤니케이션해야겠다는 결론에 도달했다.
두 번째는 어느 개발 파트에 문의를 드려야 하는지에 대한 정보가 없었다는 점이다. 팀원분들이 모두 나와 비슷한 연차의 주니어 개발자 분들이시라, 어떤 API에 대해 어느 파트로 문의를 드려야 하는지에 대해 어려운 부분이 있었다고 한다. 사실 나도 잘 모른다... 저도 이 기능을 맡은지 얼마 안되었어요ㅜㅜ
그럼에도 불구하고 전체적인 시야에서 이 서비스의 스펙을 알고 있는 것은 바로 나 기획자 (혹은 PM)이라는 생각에, 각 모듈 별 담당자를 정리하는 것이 필요하다는 생각이 들었다.
그래서 회사 WIKI에 각 모듈 별 담당자를 알아낼 때마다 한판에 정리를 해두기로 논의했다.
2. 기획자가 알지 못했던 개발 상의 고충
회고를 하면서 가장 놀랐던 포인트가 바로 '개발 상의 고충'을 기획자가 해결해줄 수 있었다는 부분이었다.
우리가 맡은 기능은 아주 예전부터 서비스하던 기능이라, API 버전이 v.7까지 나온 상태였다. 그런데 v.1부터 v.6까지 아직도 서버에서 운영중이라, 코드가 점점 더 복잡해지고 운영이 부담스러운 상황이라고 하셨다.
API가 지금까지 7개가 운영되고 있었다는 거죠...? 나 (a.k.a 기획자)는 전혀 모르던 사실이었다. 서비스에서 사용되지 않는 API 버전은 Fade out하는 것이 맞겠다는 판단에, 현황 조사를 약속했다.
그리고 바로 다음날, 나는 해당 API를 사용하는 모든 클라이언트 쪽에 버전 현황을 취합했고, 현재 v.7 이전 버전을 쓰고 있는 클라이언트는 없다는 것을 확인했다. 이로서 이전 버전의 API는 곧 전부 Fade out될 예정이다. 서버 개발자분의 부담을 조금이나마 줄일 수 있었다는 점에서도 이번 회고가 큰 의미가 있었다고 생각한다.
3. 일로 만났지만 반가워요.
무엇보다 나는 개발자가 아닌, 사람을 얻었다는 점이 가장 큰 수익이었다. 재택근무라는 좋은 환경에서 업무에 집중할 수 있는 것은 큰 복이라고 생각한다. 그럼에도 불구하고 가끔은 재택근무라는 점 때문에 서로서로가 단절되기도 하는 것 같다.
일로만 사람을 대하다보면, 나와 하고 있는 이 일로만 사람을 평가하게 되는 것 같다. 약간 개체가 아니라 NPC같은 느낌도 든다. 정작 이 개발자는 여러 프로젝트를 동시에 진행하고 있을 것이다. 그리고 업무는 업무일 뿐, 이 사람은 퇴근 후에 본인의 삶을 살아가는 사람일 것이다.
사람 대 사람으로서 만나다보니, 이 사람이 이 일 외에도 어떤 일을 맡고 있는지 알게 됐다. 그리고 현재 업무적으로, 또는 생활 면에서 가지고 있는 고충은 무엇인지 알 수 있었고, 동료를 이해하는 데에 큰 도움이 되었다.
