서비스 고도화 로드맵 짜는 법

 

서비스가 어느 정도 자리를 잡으면, 그다음부터는 신규 기능을 만드는 것보다 기존 기능을 다듬는 고도화 작업이 훨씬 큰 비중을 차지하게 됩니다.
문제는 이 고도화 작업이 신규 기획보다 로드맵으로 짜기가 더 까다롭다는 거였어요.
저희 팀이 고도화 로드맵을 짜면서 겪었던 시행착오와, 지금 쓰고 있는 방식을 정리해봅니다.

 

저희가 초반에 했던 실수는, 백로그에 쌓인 개선 아이디어를 순서대로 처리하는 걸 로드맵이라고 부른 것이었습니다.
백로그는 "해야 할 수도 있는 일"의 목록이고, 로드맵은 "이 순서로, 이 이유로 하겠다"는 의사결정이 담긴 문서인데, 저희는 이 둘을 구분하지 않고 있었어요.
그러다 보니 로드맵이 계속 바뀌었고, 팀원들도 "이번 분기에 뭘 하는 거예요?"를 자꾸 다시 물어봤습니다.
로드맵을 백로그와 분리하고 나서야, "왜 이걸 먼저 하는가"에 대한 설명이 명확해졌고 팀 내 혼란도 줄었습니다.

 

고도화 아이디어는 의외로 여기저기서 쏟아집니다.
CS 문의, 사용자 인터뷰, 내부 팀원 피드백, 경쟁사 벤치마킹까지 소스가 다양한데, 이걸 한곳에 모아두지 않으면 같은 아이디어가 여러 번 논의되거나, 좋은 아이디어가 그냥 흘러가버립니다.
저희는 결국 모든 고도화 아이디어를 하나의 노션 데이터베이스에 모으고, 각 항목마다 소스(어디서 나온 아이디어인지), 예상 임팩트, 예상 비용을 태그로 남기도록 했습니다.
이렇게 모아두니 분기마다 로드맵을 짤 때, 감이 아니라 실제로 쌓인 데이터를 보면서 우선순위를 논의할 수 있게 됐어요.

 

우선순위를 매길 때 저희는 임팩트와 비용을 각각 상/중/하로 매겨서 2x2 매트릭스에 배치하는 방식을 씁니다.
임팩트가 크고 비용이 적은 항목을 가장 먼저 처리하고, 임팩트도 작고 비용도 큰 항목은 과감하게 백로그 아래로 내립니다.
다만 이 매트릭스만으로 다 정해지지는 않아요.
임팩트가 중간이라도 사용자 불만이 반복적으로 쌓이는 항목은 신뢰도 관리 차원에서 우선순위를 올리는 경우도 있고, 다음 분기 다른 프로젝트의 기반이 되는 항목은 당장의 임팩트가 작아도 먼저 처리하기도 합니다.
매트릭스는 논의의 출발점이고, 최종 판단은 항상 팀 논의를 거쳐서 조정한다는 원칙을 세워뒀습니다.

 

로드맵을 한번 정해두면 끝까지 그대로 가는 게 아니라, 정기적으로 업데이트해야 한다는 것도 중요한 부분이었습니다.
저희는 분기 단위로 로드맵을 새로 짜고, 매달 한 번씩 "이번 분기 로드맵이 여전히 유효한가"를 짧게 점검하는 미팅을 갖습니다.
새로운 데이터나 시장 변화가 생기면 로드맵도 조정하되, 이 조정 내역을 반드시 문서에 이력으로 남겨서 "왜 계획이 바뀌었는지"를 추적할 수 있게 했습니다.
이 이력을 남기기 시작한 뒤로, "저번엔 이거 한다고 했잖아요"라는 오해가 줄었고, 계획이 바뀐 이유에 대한 설득력도 높아졌습니다.

 

마지막으로 배운 건, 같은 로드맵이라도 경영진에게 보여줄 때와 팀에게 공유할 때 설명 방식이 달라야 한다는 것이었습니다.
경영진에게는 임팩트와 비즈니스 지표 중심으로, 팀에게는 구체적인 작업 단위와 일정 중심으로 재구성해서 보여줘야 각자에게 필요한 정보가 명확하게 전달됩니다.
저희도 초반엔 하나의 로드맵 문서로 두 대상 모두에게 설명하려다가, 경영진에게는 너무 상세하고 팀에게는 너무 추상적인 애매한 문서가 되어버린 경험이 있어요.
이후로는 같은 로드맵을 두 가지 포맷으로 나눠서 관리하는데, 처음엔 이중 작업처럼 느껴졌지만 오히려 각자에게 필요한 커뮤니케이션 시간이 줄어들어서 전체적으로는 효율적이었습니다.

고도화 로드맵은 화려한 신규 기능 로드맵보다 눈에 덜 띄지만, 서비스의 체감 품질을 실제로 결정하는 건 이 고도화의 누적이라고 생각합니다.

저희 팀도 여전히 매 분기 우선순위를 두고 논쟁하지만, 적어도 이제는 그 논쟁이 데이터와 기준을 놓고 벌어지는 논쟁이 되었다는 점에서 예전과는 확실히 달라졌어요.
다음 분기부터는 이 로드맵 프로세스에 사용자 임팩트를 더 정량적으로 측정하는 방법도 추가해보려고 고민하고 있습니다.