우당탕탕 2022년, PM 회고하기 (2)
작년 한 해, 과연 내가 PM으로서 일을 '잘'하고 있었을까?
셀 단위로 조직이 개편되고, 200일이 조금 넘는 시간 동안 많은 도전을 했다.
회고를 하며 셀 운영에 있어서 정말 중요한 것은 셀원들과의 관계와 소통이라는 것을 절실하게 느꼈다.
1. 우당탕탕 스프린트 진행기
흔히들 애자일, 애자일 하는데, 애자일 방법론이란 과연 뭘까?
Agile : 날렵한, 민첩한, 재빠른, 기민한
애자일 방법론은 요구사항을 민첩하고 빠르게 반영하는 것이라고 한다. 개인적으로는 프로젝트를 할 때 군더더기를 걷어내고 MVP를 구축하며 빠르게 도전해 보는 방법 정도로 이해하고 있다. 애자일 방법론에 대해서는 더 자세하고 정확하게 설명해 주는 사람들이 많으니 이쯤에서 정리하고...ㅎㅎ
애자일 방법론에서 나오는 개념 중에는 스토리와 스프린트가 있다.
스토리(story)란, 배포가 가능한 가장 작은 단위의 요구사항이며 독립적이다. 예를 들어, 장바구니 담기 시스템을 구축할 때는 1. 상품을 보여주고 담을 수 있도록 만들고, 그리고 2. 담은 상품을 확인할 수 있도록 하는 기능 등이 필요하다. 이때, 기획적인 측면에서는 플로우가 이어지지만 상품을 담는 기능과 상품을 확인하는 기능은 독립적이며 따로 배포가 가능하다. 그래서 스토리가 2개로 나눠질 수 있다. 물론 매번 이렇게 쪼갤 수는 없어 나는 개발자들과 상의해서 적정한 수준의 스토리를 쪼개고는 한다. 처음에는 스토리 쪼개는 것도 감이 오지 않아 너무 비대한 스토리를 만들거나 너무 작은 스토리를 만들고는 했다. (그리고 그 감을 찾는 것은 정말 많이 해보지 않고서는 어떻게 조언을 해줄 방법이 없다..)
스프린트(sprint)란, 1~2주 정도의 반복주기를 잡고 계획부터 실행, 회고까지의 프로세스를 반복하는 것을 말한다. 이때, 해당 스프린트에서 실행할 스토리들을 계획하고 각 스토리들의 공수를 파악한다. 그리고 회고 때는 스프린트에서 실행한 스토리들을 구현하는 과정과 결과 등에 대해 논의한다. 윙잇에 처음 입사했을 당시, 스프린트가 갓 만들어졌었다. 개발 1팀과 개발 2팀 각각의 스프린트가 따끈따끈하게 만들어졌고, 각각 2주씩의 주기가 주어졌다.
처음 애자일 방법론에 대해 알지도 못하고 스프린트가 뭔지도 모르는 상태에서 회의에 참여했을 때는 뭐가 뭔지 도통 알기 어려웠다. 한 번에 많은 기획을 하고 한꺼번에 전달하는 워터폴 기획에 익숙한 나로서는 요구사항을 잘게 쪼개서 관리하는 방법이 어색했기 때문이다. 하지만 요구사항들을 잘게 나누어 개발을 하는 방식은 관리가 용이하고 불필요한 기능을 구현하지 않아도 된다는 장점이 있었다. 개인적으로 판단하기에는 비대한 기획을 스토리로 변환할 때, '진짜 이 기능이 필요한가?'에 대해 한번 더 고민할 시간이 있었기 때문이라고 생각한다.
하지만 분명히 단점도 존재했다. 기간을 정해놓고 기획과 개발을 진행하니 점점 스토리들을 기간 내에 쳐내는 것에만 신경을 쓰고 있었다. 회고를 하는 시간은 줄어들었고, 하나의 스프린트 다음에는 이전 스프린트의 문제점들을 개선하며 진해하는 것이 아닌, 스토리를 와장창 넣고 쳐내기식의 프로세스를 반복하고 있었다. 또 몇 개의 스프린트가 반복이 되면 하나의 스프린트 내 구현이 가능한 스토리들의 공수 파악이 가능할 줄 알았지만, 계속해서 어떤 스프린트는 너무 여유롭고 그다음 스프린트는 너무 넘치는 등의 현상이 반복되고 있었다. 또 개발자마다 강점이 다 다르니 똑같은 스토리들의 공수 측정을 '객관적'으로 하기에 힘든 점이 있었다.
2. 스프린트.. 꼭 필요할까?
셀 단위 구조로 개편하면서 가장 먼저 대두되었던 사안은, 스프린트를 계속 유지할 것인가? 였다. 스프린트의 장점이 분명히 있긴 하지만 시간의 압박감과 퀄리티에 대한 생각이 계속 남아있었다. 그래서 처음 셀 내 팀원들과 합의를 한 점은 바로 "셀 구조로 개편이 되었으니, 우선 스프린트를 깨 보자!"였다.
이후 스토리 포인트를 산정하던 방식에서 스토리를 분배하고 각 개발자분들이 본인의 공수에 맞게 해당 스토리의 개발 일정을 산정하는 방식으로 바꿨다. 객관적인 스토리의 공수 측정도 중요하지만, 그보다는 스토리 개별의 일정 관리가 더 중요하다는 것을 배웠기 때문이다. 또한 개발 일정을 산정하면 나는 해당 일정을 관리하고 그 일정에 맞춰 프로젝트들을 기획하고 또 사이사이 스토리들이 비지 않도록 끼워 넣는 방식으로 진행했다.
물론, 이 방식 또한 문제가 있었다. 스프린트 방식으로 진행할 때는 정해진 스토리의 양이 있기 때문에 배포가 진행되고 다음 스프린트 전까지 추가되는 스토리는 극히 적었다. 하지만 스프린트가 깨지고 스토리가 그때그때 여유가 있는 사람에게 배정되다 보니, 하나의 스토리의 배포가 되기도 전에 다른 스토리가 배정이 될 때가 많아졌다. 이 때문에 스위칭 코스트가 너무 많이 든다는 문제점에 직면했다. 그럼에도 스프린트 방식 때보다는 훨씬 자유도도 높고 일정관리가 편했기 때문에 스프린트로 돌아갈 수는 없었다.
결론적으로, 스프린트는 깨졌고 스위칭 코스트를 줄이기 위해 하나의 프로젝트 단위로 셀을 운영하기로 했다. 즉, 스프린트는 아니지만 스프린트와 비슷하지만 결이 다른..! 우리 셀 만의 약속을 만들었다. 하나의 프로젝트가 끝나기 전까지는 되도록 다른 일감을 전달하지 않고 매일 스크럼 시간에 프로젝트 일정을 체크하는 것이었다. 간단해 보이지만 이런 약속을 통해 스프린트보다 자유롭지만 규칙은 살아있는 최선의 방법으로 셀을 운영하게 되었다.
개인적으로 PM을 하면서 가장 어려운 점은 일정관리를 하는 것이다. 나만의 일정을 관리한다면 상관없지만, 셀 내 모든 인원들의 일정을 고려하며 관리를 하는 것이 처음에는 많이 어려운 점 중 하나였다. 더욱이 유관부서와 함께 협업을 하는 상황이라면 문제는 더 커진다. 기획과 개발을 하면서 많은 변수가 생기는데, 이를 유관부서가 이해할 수 있도록 일정을 잘 전달하는 것은 생각보다 어려운 일임을 PM을 하면서 깨닫기도 했다. 하지만 혼자서 일정을 관리하려고 고군분투하기보다 셀원들 모두가 함께 관리를 할 수 있도록 합의하고 약속을 하는 방식을 도입했고, 나름 성공적으로 진행하고 있다.
3. TMI 회고를 마치며...
셀로 개편된 이후 가장 좋았던 것은 나 혼자만 셀 운영이나 셀의 OKR에 대해서 고민하는 것이 아니라 셀원들과 다 같이 고민할 수 있었다는 것이다. 물론 개편되고 난 후 처음부터 아이디에이션 회의나 회고 회의를 진행한 것은 아니다. 작년 10월 말쯤부터 본격적으로 진행했는데, 이 또한 셀원들의 소중한 의견을 받아 시작하게 되었다. 짧게 회고나 아이디어를 논의한 적은 있지만 본격적으로 정기 회의를 진행하니 생각보다 더 좋았다. 혼자서 생각하거나 레퍼런스를 찾을 때보다 더 좋은 의견들이 많이 나왔고, 실제로 적용한 부분도 많았다. 화룡점정으로 12월 말, 셀 개편이 된 후 우리가 어떤 걸 했는지 나열하며 회고를 진행했다. 이때 내가 부족한 점도 많이 깨달았지만, 셀원들이 함께 했기 때문에 많은 일을 할 수 있다는 것을 절실히 느꼈다.
주니어 PM으로 살아가면서 아직도 잘하고 있는지, 이렇게 하고 있는 게 맞는지 고민할 때가 많다. 어떤 때는 잘하고 있다고 생각이 되다가도, 어느 날에는 맞는 방향성인가? 하며 밤잠을 이루지 못할 때가 많았다. 우당탕탕 회고를 쓴 이유도 사실 내가 뭘 잘했다고 적기보다는 지난 1년을 돌아보며 느꼈던 점들을 잊지 않기 위해 스스로 끄적이는 글에 가깝다. 결론적으로 내가 잊지 말아야 할 단 한 가지, 세상 어디에도 완벽한 정답은 없기 때문에 동료들과 많이 소통하며 합을 맞추는 것이 중요하다는 것이다. 갑자기 왜 이런 말이 나오지?라고 생각할 수 있다. 하지만 앞서 스프린트를 깨자! 라든가 회고랑 아이디에이션을 다 같이 하자!라는 것들은 누가 가르쳐주지 않는다. 책을 보면 스프린트는 아주 정답이고 모든 상황에 반드시 필요한 것처럼 보인다. 하지만 어떤 때는 일을 더 잘하기 위해 정답처럼 보이는 것들을 과감하게 깨버리는 결단이 필요하다. 그리고 그 결단은 나 혼자가 아닌, 함께 일하는 사람들과 함께 합의해야 한다는 것을 반드시 잊지 말자.
다음에 쓸 글을 잠깐 스포하자면, "우당탕탕 A/B 테스트 체험기"를 통해 어떤 것들을 배웠는지 나눠보려 한다. 다양한 A/B 테스트 정답들이 있지만, 내가 어떻게 나름의 정답을 찾아가게 되었는지 궁금하다면.. 다음 글에서 확인해 보자.
