팀의 공통 기준에 따라 우선순위 설정하기
많이 쓰여서가 아니라, 우리에게 잘 맞는지가 더 중요한 이유
해야 할 일을 위한 창고가 되어버린 백로그 보드
‘04.팀과 나를 위해 필요한 일을 주도적으로 찾아내는 방법’에서 말한 것처럼, 나는 내게 주어진 제한된 시간을 효율적으로 활용하는 데 많은 노력을 기울였다. 1인 기업으로 업무를 진행하는 것이 아니기에 팀으로서의 내 업무를 정확하게 파악하고 시간을 할당하는 방법을 계속 찾고 개선하고자 힘썼다.
하지만 그 과정에서 팀 단위 백로그는 상대적으로 관리가 소홀했다. 개인 투두 리스트를 종종 스스로 얼마나 많은 일을 했는지 만족하는 수단으로 바라본 적이 있었고, 같은 실수를 하지 않기 위해 노력했지만 팀의 백로그는 여전히 우리 팀이 해결해야 할 일을 정리하는 곳으로 여겨지는 때가 많았다. 그래서 우리 백로그에는 나를 포함한 팀원들이 제안한 의견이나 이슈, 사용자 피드백, 기능 개선 등 다양한 성격의 ‘할 일'이 저장되어 있었고 해결한 항목보다 해결해야 할 항목들이 더 빠르게 늘어났다. 등록일과 단순 구분에 따라 정리되어 있었기에 오랫동안 방치된 내용들도 있었다.
다음 스프린트 진행 전, 회고와 동시에 우리가 다시 집중해서 진행할 업무를 선정할 때도 도움이 되지 않았다. 백로그에 쌓인 항목들은 그저 날짜에 따라 정리되어 있을 뿐, 구체적인 내용들이 함께 작성되지 않은 경우가 많았기 때문이다. 제목만으로 작성된 항목은 정확히 무엇을, 어떻게 해결하기 위해 쓰였는지 확인이 어려웠다. 게다가 우선순위 설정에 대한 기준의 부재로 스프린트 진행 시, 자잘한 요구사항이 계속 생겼고 이는 앞선 문제를 해결하지 못한 상황에서 또 다른 문제로 백로그에 쌓이거나 스프린트 진행 방향을 흔드는 때도 있었다.
팀원들의 각자의 입장과 상황이 다르다는 점도 쉽지 않은 문제였다. 논의를 통해 결정될 때도 있었지만, 논의에 필요한 시간이 길어졌고 한 번의 미팅으로 의견이 좁혀지지 않을 때도 있었다. 결국 백로그 보드에 들어가는 순간, 수없이 많은 항목들을 보는 것 자체가 하나의 압박으로 다가왔고, 그 순간에도 다양한 이유에 따라 백로그에 추가되는 내용들이 생겼다.
관찰을 통해 살펴본 백로그 관리의 문제점
이대로는 단순 할일로 가득 찬 창고가 될 수 있겠다는 생각에, 백로그에 내용이 등록되는 순간부터 우리가 해당 항목을 확인하고 논의하며 우선순위를 설정하는 과정을 다시 한번 지켜보기로 했다. 이전에는 나 역시 과정에 따라 허우적거리는 경우가 많았으니, 이번에는 팀원들에게 양해를 구하고 관찰하는데 더 집중했다. 한 번으로는 쉽지 않았지만, 몇 번 반복하다 보니 그동안 보이지 않았던 문제들이 조금 더 명확하게 보이기 시작했다.
백로그에 담길 때 마땅한 구분이 없어 구조화가 되지 않는다.
항목 작성 시 내부 기준이 명확하지 않아 제목만으로 작성되는 경우가 많다.
무분별하게 쌓이는 내용들이 많아 팀이 백로그에서 점점 멀어진다.
구조화, 구체화 등에 대한 사전 준비가 되지 않아 우선순위 설정이 어렵다.
우선순위 설정에 대한 팀 단위 합의, 가이드가 존재하지 않아 그때그때 논의로 결정되는 때가 많다.
정리해보면, 관리가 제대로 되지 않았다!
왜 이렇게밖에 관리하지 못했을까 라는 자책감과 함께 빨리 수정하지 않으면 백로그 창고는 규모만 커질 뿐 필요할 때 바로 꺼내 쓰거나, 자주 쓰이는 걸 지근에 두지 못할 수 있겠다는 위기감이 몰려왔다. 팀원들 역시 스프린트 사전 미팅 때마다 백로그 보드를 보며 우선순위를 정하는 시간이 길어지고, 불필요한 커뮤니케이션이 많아지는 것에 대한 피로감을 느끼고 있는 상황이었다.
우리 팀에 맞는 백로그 관리 방법 적용하기
이런 상황을 쉽게 해결할 수 있는 방법은 우선순위 설정에 필요한 여러 프레임워크 중 하나를 팀에 적용하는 것이라 생각했다. 그렇게 MoSCoW, Kano, RICE 등 우리 팀에 잘 맞을 것 같은 몇 가지를 찾아 정리해보기도 하고 지인들이 다른 조직에서 활용하는 방법론 등을 공유받아 함께 작성해보기도 했다. 그중 MoSCoW는 PM이 업무 단위 내용과 이유를 팀에게 전달하고 활용하기에 가장 적합해 보였고, 난도가 높지 않아 팀에게 진행 방법을 공유해 테스트로 몇 번 사용해보자고 제안했다.
Must have : 이 기능(항목)을 빼고 서비스 운영을 생각하기 어려운 기준
Should have : 우선순위는 높지만 당장 적용되지 않아도 서비스에 영향은 없는 기준
Could have : 여유가 있을 때 시도해볼 수 있는, 적용하면 서비스를 더 좋게 만들 수 있는 기준
Won’t have : 중요도가 낮고, 효과가 미미한 기준
우리만의 기준이 없었으니, 적당한 합의가 있다면 이전보다 쉽게 논의가 될 수 있을 거라 생각했지만 실제론 그렇지 않았다. 세부 기준까지 고려하지 못한, 급한 마음에 전체 과정을 돌아보고도 일부 단계에 대한 개선점만 적용한 탓이었다. 또 이 기준이 백로그에 등록 시 구분에는 적용이 되지 않아 보드에서 어떤 범위까지 회의 시 다뤄야 하는지 선정하는 과정은 이전과 같은 어려움이 있었다. 다시 원점으로 돌아와야 하는 순간이었다. 나는 백로그에 항목이 담기고 다음 스프린트에 반영되는 우리만의 과정을 적고, 단계별 개선점을 다시 고민하기 시작했다.
1. 담는 순간부터 정리될 수 있는, 백로그 구분 정하기
백로그 보드에 ‘잘 담는’ 방법이 필요했다. 우리 팀은 트렐로를 쓰고 있었기에 리스트와 라벨 기능을 더 구체적으로 활용하기로 했다. 먼저 리스트를 정리했다. 내부 목표를 달성하기 위해 논의한 내용, 사용자 피드백이 담긴 리스트 마지막으로 아이디어 리스트를 생성했다. 적어도 작성하는 그 순간 어떤 리스트에 담길 내용인지 미리 생각할 수 있었으면 했다. 리스트에 각 항목을 작성할 때 역시 처음엔 귀찮더라도 구체적인 내용이 담길 수 있도록 했다. 라벨을 활용해 문제가 수집된 경로를 설정하고 연관 기능, 발생 가능한 이슈, 진행해야 하는 이유를 함께 입력할 수 있게 했다. 리스트와 라벨은 다른 팀이 잘하는 기준이 아니라 우리에게 잘 맞는 것으로 꾸준히 개선하는 것도 잊지 않았다.
2. 아이디어는 별도 템플릿을 만들어 관리하기
우리 팀은 슬랙 등을 통해 공유되는 아이디어가 꽤 많았었는데, 이전에는 백로그까지 닿지 않고 기획자인 내가 여러 채널로 들어오는 내용을 정리해 문서화하는 경우가 많았다. 그러다 보니 스프린트 사전 미팅 시 슬랙에서 나온 아이디어는 어떻게 할까요? 이번 기능 개선에 잘 맞을 것 같은데요? 와 같은 의견이 종종 나오곤 했고, 그때마다 아이디어 문서를 별도로 열여 함께 확인했다. 백로그 보드와 동기화가 잘 되었다면 문제 해결에 도움이 되는 식으로 연결될 수 있었을 텐데 하는 아쉬움이 많았다. 그래서 아이디어를 백로그 보드에 함께 포함시키되 두 가지 방법을 함께 활용하기로 했다.
(1) 아이디어 역시 정해진 기준에 따라 작성하는 방법. 예를 들어 사용자가 더 많은 콘텐츠를 업로드할 수 있게 툴팁을 활용하자는 의견이 있다면, 이 내용만 작성하는 것이 아니라 떠올리게 된 계기, 우리 서비스와 사용자에게 중요하다고 생각하는 이유, 우리가 달성하고자 하는 목표와의 연관성 등을 함께 작성하도록 한 것이다. 아이디어는 순간 스쳐 지나가는 경우가 많기에 가능한 구체적으로 붙잡아 두고 싶은 마음이었다.
(2) 연관된 항목을 미리 살펴보는 방법. 아이디어를 작성하는 순간에는 모를 수 있지만 우리가 해결하고자 하는 문제 즉 앞서 작성한 항목과 얼마든지 연결될 수 있을 거라 생각했다. 툴에 따라 다르지만 트렐로와 같은 서비스에서는 앞서 작성한 내용을 쉽게 연결할 수 있기에 링크 형태로 연결하기로 했다. 이 방법을 활용하기로 한 뒤 우린 문서 두 개를 함께 보는 일이 없어졌고, 제안한 아이디어가 어떤 문제를 해결하기 위해 나왔는지 더 구체적으로 확인할 수 있게 되었다.
3. 무분별하게 쌓이는 내용이 없도록 한 번씩 점검하기
구분을 정해 구체적으로 작성한다 하더라도 작성하는 순간 이전 내용을 확인하지 않거나 한 번씩 확인해 정리하지 않으면 이전처럼 할 일이 쌓여 있는 공간으로 머물 가능성이 높다고 생각했다. 그래서 일정 기간 이상 백로그에 담겨 있는 항목은 별도 미팅으로 팀원들과 확인 후 삭제하기로 했다. 몇 번 진행하면서 알게 된 사실인데 이 시간은 우리에게 백로그 내 업무 작성을 더 신중하게 할 수 있는 기회는 물론 작성 전 내용을 한 번씩 살펴보게 하는 중요한 역할을 해줬다.
4. 우선순위 설정을 위한, 우리만의 방법 설정하기
앞서 시도했던 MoSCoW는 결국 실패로 돌아갔기에 더 세부적인 기준이 필요했다. 다만 새로운 방법론을 적용하기보다는 우리에게 맞게 구체적인 기준을 정하기로 했다. 처음엔 영어로 작성, 직역된 내용들이 문제일까 싶어 우리만의 언어로 기준을 다시 써보기도 했지만 도움이 되진 않았고, 난 체크리스트를 만들어 네 가지 항목에 대입할 수 있을지 살펴보기로 했다.
알게 모르게 우리가 서비스를 개발하고 관리하는데 영향을 줄 수밖에 없는 내용들을 하나씩 적었다. 단계 별 설정한 목표에 부합하는지, 기존 운영 정책에 문제 되는 건 없는지, 사용자들에게 어떤 가치를 줄 수 있는지, 서비스 구조(개발 구조)에 영향을 주는 건 없는지, 배포 후 발생할 이슈를 특정할 수 있는지 등 20개 항목을 확인할 수 있었다. 작성 후 따로 구분하지 않고 팀원들에게 공유 후 추가로 중요하게 생각하는 기준이 있으면 이어서 써달라고 요청했다. 우리가 이런 논의를 하기 전, 각자의 입장에 따라 논의 내용이 달라지는 적이 많았는데 팀원들이 작성한 내용을 잘 정리하면 이런 문제를 조금이나마 해결할 수 있을 거란 생각이었다.
언제나처럼 중복되는 내용은 합치고, Must have/Should have/Could have/Won’t have 네 가지 기준에 각 항목을 하나씩 배치했다. 예를 들어 Must have가 기존에는 이 기능(항목)을 빼고 서비스 운영을 생각하기 어려운 기준이었다면, 이젠 목표 달성에 도움이 되는지, 리소스가 얼마나 투입되어야 하는지 등 세부 조건이 추가되어 더 빠르게 우선순위를 설정할 수 있는데 도움이 되었다. 팀원들 역시 각자의 상황과 입장이 반영되니 기준이 하나, 둘 담겨 있어 기준에 대한 별도 고민 대신 적용 이후 등에 대해 더 깊은 이야기를 나눌 수 있는 환경으로 받아들이게 되었다.
나는 지금도 이와 같은 기준을 먼저 만들고자 노력하는 편이다. 우리가 확인할 수 있는, 잘 알려진 기업에서 활용되고 있는 방법론을 한 번씩 확인하고 기본 틀을 잡는 것도 중요하지만 무엇보다 우리 팀에게 맞는 방법인지 살펴보는 것이 먼저라고 생각하기 때문이다. 팀을 옮기게 되는 경우 이런 과정은 더 중요해질 수밖에 없다. 더 좋은 방법인지 아닌지 판단하는 기준은 어디에서 많이 쓰이냐가 아니라, 우리 팀이 처한 상황에서 최대의 효율을 낼 수 있는지여야 하는 이유이기도 하다.
여전히 백로그를 관리하고 우선순위를 설정하는 건 가장 어려운 일 중 하나지만, 그렇기에 더 나은 방법을 고민하고 돌아보는 시간이 꼭 필요하다고 생각한다. 이번 내용이 우리만의 합의가 잘 만들어져 있는지, 부족하다면 어떻게 개선할 수 있을지 한 번씩 살펴볼 수 있는 기회가 될 수 있었으면 한다.
2023년 07월, 제 첫 도서가 출간되었어요. 제목은 ’10년 차 IT 기획자의 노트’입니다. 브런치 '기획자가 일하는 방법'을 시작하게 된 이유는 사수 없이 일하는 어려움을 저보다 조금 늦게 출발한 분들이 덜 느꼈으면 하는 마음 때문이었는데요. 같은 맥락에서, 9개 노트(기록)를 바탕으로 기획과 PM의 주요 업무를 어떻게 하면 좋을지 정리한 내용입니다. 아래 링크를 통해 자세한 내용을 확인하실 수 있어요!
