주니어 PM의 백로그 관리법
자기 전에 생각나는 보물 보따리, 백로그
01. 백로그 (Backlog) 가 무엇이죠
'백로그에 적재하시죠', '백로그에 비슷한 이슈 있어요' 처럼 업무 중 자주 사용하는 용어 중 하나가 백로그 인데요. 제대로 된 뜻을 찾아본 건 이번이 처음입니다. back (뒤에 둔) + log (장작), 즉 당장 사용되지는 않아 뒤에 쌓여있는 장작을 의미하는데, '아직 하지 못한 일'을 비유적으로 가리키는 데에도 사용된다고 합니다. 저는 후자의 의미로 습득해 지금까지 자연스럽게 사용하고 있습니다.
(백로그의 의미를 찾다가, 위에 서술한 것 이상의 확장적인 개념으로 백로그를 다룬 글이 있어 재미있게 읽었는데요. 참고차 링크를 남겨놓습니다. 흥미로운 소재를 글로 남겨주시는 분들이 많아 감사하네요 :) )
제품을 만들고 개선하기 위해 '할 일'은 항상 많습니다. 그래서 '아직 하지 못한 일'의 목록이 반갑게 느껴지기는 어렵습니다. 저도 처음에는 백로그를- 체크 표시 없이 비워진 체크박스 무더기처럼 약간은 부담스럽게 생각하기도 했는데요. 제품 개선까지 가는 길에 대한 힌트 (헨젤과 그레텔이 남겨둔 빵 조각 이라고나 할까요) 정도로 생각하면서부터 조금씩 백로그와 친해진 것 같아 그 기록을 남겨보려 합니다.
02. 백로그를 이렇게 작성했습니다
(1) 언제
당장 제작 일정을 확보할 수는 없지만 제품 개선에 참고할 만한 의견이나 현상이 발생했을 때 작성했습니다. 백로그 적재 필요성을 빠르게 판단하기 어렵다 싶으면 일단 적재했습니다. 물론 이것의 전제는 -쌓은 백로그를 정기적으로 정리한다- 에 있겠지요.
(2) 어디서
고객 VoC, 스프린트 회고, 자기 전 머리 맡 등 제품 개선의 힌트는 곳곳에서 발생합니다. 보통은 슬랙이나 회고 기록 등 문서의 형태로 인입되지만, 캔틴에서 우연히 마주친 동료가 선물처럼 준 반짝이는 아이디어처럼- 잘 정리하지 않으면 휘발되는 형태로 생기기도 합니다. 그래서 처음에는 작은 수첩을 하나 들고 다녔는데 그것도 영 기록이 쉽지 않아 그 다음부터는 (좋은 방법인지는 모르겠으나) 구글 캘린더 앱을 켜서 아무 일정이나 확보하고 그 일정에 백로그 내용을 급히 작성했습니다. 그러면 그 일정에 알림이 와서, 기록해둔 백로그를 다시 잘 정리해 문서에 넣는 데에 도움이 되었습니다.
(3) 어떻게
백로그에 대한 고민은 작성 단계가 아니라 후에 돌아보는 단계에 있어야 한다고 생각했습니다. 그래서 작성은 최대한 간결하고 생생하게 하는 데에 초점을 맞췄습니다. 우선순위 (일정을 무조건 확보해야 하는 것은 P0, 추후 우선순위 논의를 통해 제작 여부를 결정해야 하는 것은 P1로), 유형 (버그, 개선 의견, 기타 중 택1), 제목, 참고할 슬랙/노션 등 문서가 있는 것은 링크, 백로그 후속 관리 현황을 알려드리기 위해 제보자 성함, 기타 정해지지 않은 형태이나 이 백로그의 맥락을 재현하기 위해 필요한 메모, 백로그의 상태 (백로그-default, 논의 중, 태스크화 완료 중 택1) 를 기록했습니다.
이성긍 브런치 채널의 백로그 예시03. 작성한 백로그를 이렇게 들여다보았습니다
(1) 누구나 언제든 (작성하고) 볼 수 있도록 하기
개인 구글 캘린더나 슬랙 DM 등, 휘발되지 않게 하기 위해 임시로 메모해둔 것도 모두 공개된 문서로 옮겨두었습니다. 누구나 볼 수 있는 위치에 두고 그 위치를 홍보해 스쿼드원들이 언제든 볼 수 있도록 했습니다. 그리고 대부분의 경우에는 PM이 작성했지만, '누구나 작성할 수 있음'도 중요한 원칙으로 삼았습니다. PM마다 스타일이 다르겠지만 저는 (결정과 실행이 필요할 때에는 각자의 직무 역량을 발휘하는 것이 중요하기 때문에 DRI가 분명히 설정되어 있는 것이 필요하다 생각하고) 제품에 있어 발산이 필요할 때에는 각자의 직급이나 직무와 상관 없이 모두가 목소리를 내는 것이 건강한 제품 문화라 생각하기 때문입니다. 이점을 체감하기도 했습니다. 예를 들어- 개발 과제라고 생각했던 '로딩 속도 개선'과 관련된 의견을, UX 개선 아이디어를 수집하던 프로덕트 디자이너가 주체적으로 제시해주신 덕분에 그 필요성이 더 빠르게 납득되어 실제로 태스크화해 진행했습니다.
(2) 정기적으로 들여다보기
백로그를 휴지통이 아니라 꿀단지로 만들려면 주기적으로 들여다보는 것이 가장 중요하다고 생각합니다. 쌓이기만 하고 도무지 해소는 되지 않는 문서처럼 여겨진다면- 어떤 의견이 제시되었을 때 "당장의 우선순위가 높지 않기 때문에 백로그에 넣어두고 실행 여부 결정하겠습니다."라는 말을 하는 PM과 제품 문화는 신뢰를 얻기 어렵습니다. 그래서 챕터별 목표에 따라 달랐지만- 재정비하는 것이 중요한 목표였던 챕터에는 주간 회의 문서 내에 백로그 데이터베이스를 넣어 매주 회의 때 자연스럽게 볼 수 있도록 하기도 했습니다.
(3) 유형화해서 소화하기
작성했던 백로그를 검토할 때에는 건 by 건으로 하나씩 쳐내듯 해결하는 것이 아니라 유형화하는 것이 필요하다 생각했습니다. 백로그의 내용은 다양합니다. 어떤 건은 '00이 불편해 개선이 필요해보임' 정도의 낮은 해상도로 단순 제보처럼 들어오기도 하고, 어떤 건은 해결책에 대한 아이디어까지 같이 제시되기도 하는데요. 각 백로그의 '원인'을 들여다보면 결국 같은 문제에서 기인한 것들이 꽤 있습니다. 이 과정이 백로그 소화의 핵심이라 생각합니다. 같은 원인에서 발생한 것을 묶어 백로그를 문제 단위로 만들면서, 원인 파악을 함께 하기 때문에 문제를 해결 가능한 대상으로 변환하는 과정까지 포함되어 있기 때문입니다. 실제로 이 과정을 통해- 영영 잊혀질 위기(?)에 처해있던 백로그들의 중요성이 재검토되고 프로젝트까지 진행한 경험이 있는데 이 때의 경험담은 별도의 글을 통해 풀어보도록 하겠습니다.
자기 전에 생각나는 보물 보따리 백로그, '기억해야 할 게 너무 많다!' 싶을 때는 그 자체로 든든한 존재가 되어주기도 합니다. 앞으로는 백로그 '문서'에 대한 작성/관리 노하우 뿐 아니라 이를 활용한 제품 로드맵 설계까지 고민해나가는 것이 중요할 것 같습니다. 부쩍 날이 쌀쌀해진 10월의 마지막 브런치 정리 글은 여기에서 마무리해볼게요 총총
