“일단 백로그에 넣어두고 여유 있을 때 보는 걸로 할까요?” : 백로그를 백로그로 두지 않는 법
안녕하세요! 배민선물하기 서비스를 만들고 있는 PM 곽민경입니다.
프로덕트를 개발하다 보면 마치 세포분열이라도 하듯 할 일들이 늘어납니다. 그러다 보면 PM이든, 개발자든 습관적으로 자주 하게 되는 말이 있죠.
"일단 백로그에 넣어두고 여유 있을 때 보는 걸로 할까요?"
백로그(Backlog). 단어가 주는 느낌 때문인지 어쩐지 해야 할 일을 뒤로 미뤄두는 느낌이 듭니다. 당장 시간이 없다는 이유로 해야 할 일을 미룬 것은 아닌가 죄책감이 들 때도 있고요. 한두 개 프로젝트를 하다 보면, 어느새 눈사태 일보 직전처럼 쌓인 백로그 양에 압도되기도 합니다.
백로그의 어원을 찾아보니, 벽난로 뒤에 쌓아놓은 장작용 통나무를 부르는 용어였다고 합니다. 필요하긴 한데 일단은 아무렇게나 쌓아둔 상태를 의미하는 백로그. 이런 백로그들에 파묻혀 지내는 것은 *프로덕트 메이커들에게 꽤 흔한 일상이지요.
*프로덕트 메이커: 비즈니스 문제를 자신만의 기술로 풀어내는 사람으로, IT 업계에 종사하고 있는 기획자, 개발자, 디자이너, 프로덕트 매니저, 마케터 등을 포함한다.
출처: Canva AI 이미지 생성기
이 글은 백로그와 함께 살아가는 프로덕트 메이커들이 자기도 모르게 놓치지 말아야 할 것을 놓치고 있는 것은 아닐까? 라는 고민에서 시작되었습니다. 한정된 리소스로 해야 할 일을 결정해야 하는 PM에게 백로그는 완전히 없어서도 안되고, 너무 많아서도 안되는 애증의 존재라고나 할까요? PM은 중요도, 긴급도 등에 따라 할 일의 우선순위를 정하게 됩니다. 주로 사용자의 불편함이 크거나 비즈니스 임팩트가 큰 것을 위주로 우선순위를 높게 결정하는데요, 그러다 보면 사용자의 불편이 있긴 하지만 불편을 겪는 수가 적다고 판단되면 우선순위를 높이기가 쉽지 않습니다.
배민선물하기팀에서는 이런 백로그들을 어떻게 해결해나가고 있는지 실제 사례를 통해 공유해 보려고 합니다.
1. 처음은 고객의 작은 요구로부터
선물하기 팀에서는 정기적으로 선물하기를 사용하시는 분들의 목소리(Voice of Customer, 이하 VoC)를 모니터링합니다. 이 목소리들 중에 “선물 거절을 하고싶다” 는 내용을 종종 발견할 수 있었어요. 배민선물하기의 상품권은 등록을 한 이후로부터 사용, 거절 등 액션을 할 수 있는데요, 때문에 ‘선물 거절하기’ 기능을 통해 상품권을 등록을 한 후라면 언제든지 거절할 수 있었습니다. 그래서 단순하게 상품권을 등록하시고 거절하기 버튼을 누르시면 거절할 수 있다고 알려드리고 넘어갔죠.
저는 대부분의 거절이 필요한 경우에 대해서 ‘에이 뭘 이런 걸 다~ 마음만 받을게요.’ 같은 긍정적인 거절이 대부분일 것이라고 생각했던 것입니다. 이 때는 몰랐습니다. 거절을 원하는 목소리들에 숨겨진 니즈가 있다는 것을요!
2. 찜찜한 마음으로 백로그를 쌓아두다
‘거절 기능이 있는데 사람들이 왜 거절 기능을 잘 찾지 못할까?’ 라는 의아함을 가진 채로 일단 백로그를 기록해두었습니다. 선물하기 팀에서는 백로그를 가볍게 남길 수 있도록 스프레드시트를 만들어두었거든요. 어느 정도로 가볍게 적을 수 있냐면 제가 작성한 백로그의 이름은 ‘선물 거절을 편하게?’ 였습니다. 사실 처음에는 무엇이 문제점인지 정확히 알지 못했고, 서비스를 운영하는 입장에서 ‘거절’은 달가운 것이 아니었기 때문에 그렇게 중요하게 생각하진 않았습니다. 무엇보다 VoC의 숫자가 많지 않았고, 이미 거절하기 기능이 있긴 했으니까요.
출처: 배민선물하기 프로젝트/백로그 관리 시트
그런데 그 이후로도 거절 키워드가 포함된 VoC가 조금씩이지만 꾸준히 들어왔습니다. raw data를 통해 좀 더 내용을 상세히 살펴보니, 거절 기능을 어떻게 쓰는 건지 몰라서 문의를 주시는 고객들도 많았지만, 등록하고 거절을 하는 것에 대해서 불편함이 있다고 말하는 분들도 있다는 것을 알게 되었습니다.
‘받고 나서 거절하는 게 민망해요’
‘한 번 등록하면 거절 못 하는 거 아니에요?’
‘모르는 사람이 저한테 선물을 보낸 거라 바로 거절하고 싶어요’
‘배민 앱이 없어서 어떻게 거절해야 하는지 모르겠어요’
‘마음만 받을게요~’ 같은 긍정적인 거절만 예상했었는데, 부담스러운 선물이라 바로 거절해야 하는 경우도 많았던 것이죠. 배민을 잘 쓰지 않아서 거절을 하려면 앱을 깔아야 한다는 것에 대한 불만도 있었습니다. 사실, 배민앱을 안쓰던 고객님이었더라도 선물을 받아서 배민을 사용하게 되면 좋겠다는 바람이 있기도 했기 때문에, ‘선물 거절을 편하게?’ 백로그는 계속해서 방치될 수밖에 없었습니다.
3. 백로그를 말할 결심
저는 꾸준하게 들어오는 거절 백로그에 대해 조심스럽게 이야기를 꺼내볼까 고민했습니다. 그러나 다른 중요한 프로젝트들이 돌아가고 있는 시점에 갑자기 ‘거절을 편하게 하는 방법을 고민해봅시다!’ 라고 얘기하면 환영받지 못할 것 같았습니다.
백로그가 뒤로 밀리게 되는 수많은 이유 중 하나가 말하기 어려운 환경인 것도 있는 것 같은데요, 왜냐하면 수많은 백로그들의 대부분은 화려하고 혁신적이진 않기 때문입니다. 백로그는 ‘혁신’이라는 큰 변화를 만들기보다는 ‘개선’이라는 작은 변화를 의미하는 경우가 많습니다. 그러나 우리 삶에 혁신만 필요할까요? 좋은 서비스에는 혁신적인 변화도 필요하지만 작고 소중한 개선들도 필요합니다.
4. 백로그에 날개 달아주기
팀원들에게 혁신은 아니지만 작은 변화를 만들어보자고 설득하려면 몇 가지 준비가 필요했습니다. 다행히 선물하기 팀은 3주 간격으로 스프린트 플래닝을 진행하는데요, 플래닝 시간에 이번 스프린트 기간 동안 해야 할 일을 결정하게 됩니다. 장기 호흡으로 진행해야 하는 중요 프로젝트를 이야기하고, 이후에 운영개선 백로그를 이야기하는 시간이 있습니다.
그럼에도 불구하고 ‘거절을 편하게 할 수 있도록 개선해보자’ 고 가볍게 던지기는 어려웠습니다. 오히려 거절하지 않았을 사람들까지 거절하게 되는 것은 아닐지 걱정이 있었기 때문입니다. 그렇기 때문에 오히려 해야하는 이유를 잘 설득해야겠다고 생각했습니다. 수많은 백로그 중 하나를 해치운다고 생각하면서 일하기보다는, 백로그라는 장작 하나를 난로에 넣어서 더 활활 타오르게 할 수 있도록 말입니다. 백로그를 치워야할 무언가로 정의하기보다, 우리 프로덕트를 더 좋게 만드는 의미 있는 일이라는 생각이 들면 보람차게 일할 수 있을 테니까요!
일단 백로그를 ‘거절 경험 개선’이라는 이름으로 재정의하여 과제화 했습니다. 그리고 과제화를 하게 된 배경과 필요한 작업, 예상되는 기대효과를 공유했습니다. 놀랍게도 생각보다 많은 공감을 얻었고, 결과적으로 디자이너, 개발자, PM이 함께 이 과제를 시작할 수 있게 되었습니다. 한 줄짜리 백로그로 시작해서 실제 프로덕트 개선, 그리고 결과까지 이루어지는 과정이 마치 계란에서 태어난 병아리가 닭이 되기까지의 성장을 경험한 것처럼 느껴졌습니다.
5. 프로젝트의 끝은 언제나 성과와 함께
PM에게 있어 프로덕트 개선에 참여한 모든 이의 리소스를 의미 있게 사용했음을 증명하는 것도 역할 중 하나입니다. 때문에 어떠한 과제든 마무리는 작은 성과라도 항상 함께 공유하고 있습니다. 부정적인 결과가 나왔거나, 아니면 너무 미미한 변화더라도 일단 확인 후 다음 의사결정 때에 반영합니다.
과제 시작 전부터 ‘거절’은 서비스를 운영하는 입장으로서는 조심스러운 점이 있었기 때문에 여러 지표를 설정해두었습니다. 첫 번째로 꼭 달성해야 하는 지표(=목표 지표), 두 번째로 이 과제로 인해 떨어지면 안 되는 지표(=가드레일 지표), 마지막으로 반드시 달성해야 하는 것은 아니지만 살펴보면 좋은 지표(=모니터링 지표)로 나누어서 살펴보았습니다.
- 목표 지표: 거절을 원하는 사람이라면 등록 후 거절보다 등록 전 거절을 선호할 것이다.
- 가드레일 지표: 거절의 전체 수치는 늘지 않을 것이다.
- 모니터링 지표: 고객센터로 거절 방법을 문의하는 사람이 감소할 것이다.
결과를 살짝 공유드리면, 기존 사람들이 불편해했던 등록 후 거절 수는 기능 추가 후 이전보다 60% 감소했고, 고객센터로 들어오는 거절 문의도 66% 감소되었습니다. 등록 전에 거절할 수 있도록 개선하자 고객센터에 문의를 하지 않고도 쉽게 거절할 수 있게 된 것이죠. 다만 전체적으로 거절하시는 분들의 수도 조금 늘게 된 점은 아쉬웠는데, 이는 아마 그동안 여러 이유로 거절을 못 하던 사람들이 거절 기능을 인지하게 돼서, 나중에 거절하는 것이 아니라 받자마자 거절하게 된 것으로 보입니다.
6. 마무리하며
물론 모든 백로그가 이처럼 과제화가 되어야 할 만큼 복잡하고 고려해야 할 부분이 많은 것은 아닙니다. 저도 위 사례처럼 과제화를 진행해서 처리한 백로그가 아주 많지는 않거든요. 보통은 좀 더 가벼운 것들이 많습니다. 예를 들면 내부 사용자들이 사용하는 어드민에 필터를 추가해야 한다거나, 에러 텍스트 메시지를 수정해야 한다거나 등 정말로 간단한 운영개선 건들이죠.
그러나 간단한 백로그도, 무거운 백로그도 항상 남아있습니다. 백로그 정리는 마치 방 청소와 같아서, 지금 다 해도 언젠가는 또 다시 해야합니다(하하). 백로그는 얼른 털어내 이별을 고하고 싶은 마음의 짐으로 여겨지곤 합니다. 또는 작은 운영개선을 하는 것은 소모되는 일이며, 의미 있는 큰 프로젝트만을 해야 도움이 된다고 생각하는 분들도 계실 겁니다.
분명한 것은 쌓이기만 하고 영원히 남아있는 백로그는 결국에는 프로덕트의 발목을 잡게 됩니다. 마음의 짐에도 보이지 않는 무게가 있지요. 백로그를 백로그로 두지 않는 법은, 결국 한마디로 ‘치우거나 해결하거나’입니다.
이런 단순한 결론에도 이렇게 글을 쓰게 된 것은, 모든 백로그가 단순하게 치워버려야 할 짐덩이는 아니며, 이 중에는 반드시 짚고 넘어가야 할 중요한 것들도 있을 수 있음을 전하고 싶었습니다. 작은 변화를 쌓다 보면 프로덕트도 조금씩 성장하고 발전할 테니까요!
이 과정을 통해 배운 교훈을 간단히 정리해 보면 이렇습니다.
- 적지만 꾸준히 들어오는 고객의 목소리를 자세히 살펴보면 해결해야 할 점이 보입니다.
- 플래닝 단계에 백로그/운영개선 건들도 말할 수 있는 환경이 중요합니다.(팀원 모두 운영개선도 중요하다는 공통된 합의가 필요하겠지요)
- 해야 하는 목적과 기대효과만 명확하면, 백로그도 작업자로 하여금 중요한 일로 받아들여질 수 있습니다.
우리들의 프로덕트에는 언제나 백로그가 존재할 것입니다. 제품 개발에 있어서 운영은 뗄 수 없고, 이로 인해 발생하는 여러 개선 사항들도 뗄 수 없을 테니까요. 쌓인 백로그에서 숨은 보석을 발견하지 못하고 있지는 아닌지, 아니면 백로그가 너무 많아 우리의 제품이 숨을 못 쉬고 있는 상태는 아닌지 돌아보는 시간이 필요합니다. 어떤 백로그에 날개를 달아줄지, 어떤 백로그에게 작별을 고할지 지혜롭게 관리해 보는 시간을 갖는 것도 좋은 프로덕트로 나아가는 한 발짝이 될 것입니다.
🎁 배민선물하기 서비스는 배달의민족 앱 또는 아래 링크를 통해 구경해 보실 수 있어요. 생일, 응원, 단체선물 등 상황에 맞는 다양한 카드와 모바일 상품권으로 센스 있는 선물을 전해보세요!