유저 인게이지먼트가 높은 제품에서 이슈 대응하는 제품팀
*유저 인게이지먼트란? 기업이 고객과 직접적이고 의미 있는 관계를 구축하고 유지하기 위해 사용하는 일련의 모든 활동을 의미합니다.
안녕하세요! 밀당 R&D 본부 Product Manager 유현영입니다 🌳
지금까지 밀당에서 일하면서 너무 리스펙하는 팀원들과 함께 프로덕트를 만들어나가고 있습니다. 이런 저희 팀의 노력과 문화가 외부에 잘 알려지지 않은 것 같아 이 글을 시작으로 R&D가 일하는 방식들을 하나하나 소개하고자 합니다 :)
가장 먼저 해결하고자 했던 것
제가 밀당에 합류한 이후 제가 첫번째로 집중한 것은 우리가 지금 우리 R&D가 겪고 있는 문제가 어떤 것 인지 명확하게 인식하고 인지하는 것이 중요하다고 생각했습니다.
그래서 사용자들이 가장 많이 쓰고 있는 프로덕트에서 어떤 불편함이 많은지 📤오류 및 문의가 들어오는 채널을 개선해야겠다고 목표했습니다.
> 사용자가 겪고 있는 문제를 파악할 수 있고
> 서비스 구석구석 디테일 한 기능과 활용까지 알 수 있으니
제가 처음 들어와서 밀당에 빠르게 적응하고 파악하고자 하는 저에게 최적의 프로젝트라고 생각했습니다.
먼저 밀당 R&D 는 어떤 걸 하나요?
“질 높은 교육 기회의 평등”
을 목표로 전국, 나아가 전 세계의 모든 아이들에게 높은 수준의 교육을 제공하고자 합니다.
저희 R&D 팀은 이 목표를 실현하기 위해, 아이들에게 1:1 관리형 수업을 제공해주고 있는 ‘ 👩🏻🏫 온택트 선생님’들과 학습에 효과적인 학습 자료들을 제작하고 있는 ‘ ✍🏻 콘텐츠 스페셜 리스트’ 팀원들이 사용하는 어드민에 가까운 프로덕트를 주로 개선하고 있습니다.
학생들이 학습하는 페이지 (B2C),
학생들의 학습 상황을 모니터링하고 관리하는 페이지(LMS, Learning Management System),
학생들의 학습 콘텐츠를 업로드하고 관리하는 페이지(CMS, Content Management System)로 나뉘어 있습니다.
LMS와 CMS는 어드민의 성격이 강하지만 300명이 넘는 온택트 선생님과 콘텐츠 스페셜리스트분들의 입장에선 매일 매일 사용하는 서비스이며, 선생님들이 학생들과 직접 접하는 인터페이스 역할을 하기 때문에 매우 중요합니다.
선생님이라는 인터페이스가 학생들에게 제공되는 프로덕트이며, 유저 인게이지먼트가 높기에 학습 관리에 필요한 LMS/CMS 이슈의 빠른 대응이 너무 중요합니다.
오류가 발생하면 내부 고객들은
최소 300명의 선생님들과 15,000명의 학생들이 수업 진행하고 하는데 갑자기 수업이 중단되어 버리게 되는 상황이 발생되게 된답니다.
조금만 로딩이 느려지더라도 많은 학생을 관리하고 있는 선생님들에게는 1초가 1시간 처럼 길게 느껴진답니다😫
밀당에서는 온택트 선생님들과 콘텐트 스페셜리스트 분들이 같은 사무실 환경에서 근무하시기 때문에 유저가 내부에 있다는 장점도 많지만 그만큼 동시에 어려운 점이 있습니다.
회사 내부에 많은 유저들이 있을 때 각종 이슈들에
> 발생하는 문제가 어떤게 있었는지
> 우리 제품팀이 어떻게 개선해나가고 일하고 있는지
소개 드리겠습니다. 😇
어떤 문제가 있었나요?
Problem 1. 다양한 채널에서 이슈들이 들어와서 정신없어요😵💫
약 10개 정도의 각 본부와 소통하고 있는 채널마다 채널에서 다양한 포멧으로 서비스의 오류를 제보하고, 문의를 하고 있었습니다.
접수되는 채널들이 많아지니 해당 이슈가 해결이 되었는지, 어떻게 되었는지, 진행 상황을 여러명에게 물어보아야 하고, 커뮤니케이션이 넘 힘들었죠.
또한 각각의 팀원들에게 Slack DM 으로 와서 팀원들 리소스 트레킹도 어려울 뿐더러 동일하게 발생하고 있는 이슈들이 중복으로 올라오고는 했습니다.
Problem 2. 이슈 우선순위를 모르겠어요
저희 팀원들은 각각의 능력들이 뛰어나 이전에는 ‘제보된 이슈는 바로 처리해 줘야 해’ 라는 생각을 갖고 모든 이슈를 빠르게 처리하려고 했어요.
이 때문에, 스프린트에서 진행하고 있는 메인 업무가 더 시급하고 중요도가 높음에도 불구하고 이슈 해결을 하느라 기존 과제의 우선순위가 밀리는 경우가 생기고, 컨텍스트 스위칭이 너무 잦게 일어나 피로도 심해졌습니다.
이렇게 제보되는 이슈들이 관리가 안되고, 우선순위를 모르니 빠르게 간단하게 해결할 수 있는 문제인데도 이거 핫픽스로 나가야 하는지, 나중에 수정할지 판단을 대기하는 시간이 더 길어졌습니다.
어떻게 해결했나요?
Problem 1. 다양한 채널에서 산재되어 들어오는 이슈
→ Soultion 한 채널에서 확인 하실 수 있습니다
기존에 중구난방으로 들어오던 이슈들을 한 채널로 일원화 했으며, 오류 확인에 필수적으로 필요한 계정 정보나 발생하는 기기명, OS버전 등에 대한 정보들 받아 많은 핑퐁 과정을 거치지 않아도 해결될 수 있도록 통일화 된 양식으로 접수 받았습니다.
또한 슬랙으로만 해당 이슈를 받게 되면, 실수로 놓쳐버린 이슈는 영영 잊혀지게 되는데요, 급건은 아니지만 아이디어들은 일주일 이내에 확인해서 답변을 남겨 놓고, 현황에 대해서 확인할 수 있는 현황판도 공유 했습니다.
Problem 2. 이슈 우선순위를 모르겠어요
→ Soultion 정말 급하신가요?
먼저 오류를 접수하는 유저에게 스스로 급건임을 판단할 수 있도록 우선순위를 접수 할 수 있게 제공했습니다. 이전에 제보된 내용을 보면, 아이디어성의 의견들이나 기능을 잘 몰라서 말씀 주신 이슈들이 많이 있더라구요
실제로 중요하고 시급한 업무에 집중할 수 있도록
[ 🔴 지금 바로 해결이 필요해요] 통해서 들어온 이슈는 슬랙 연동을 해놓고 바로 알람이 뜨게하고,
나머지 [ 🟡 급하지는 않아요 ] 로는 일주일에 한번씩 처리를 하거나 백로그로 놓고 다음 스프린트 과제로 챙기고 있습니다.
위 2가지 문제들 기준으로 해결하면서 추가적으로 개선하고 있는 과정도 있는데 같이 소개 드리겠습니다.
측정이 가능해야 개선이 가능합니다.
제가 좋아하는 피터드러커의 명언이 있는데요
‘측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선할 수 없다’
그래서 이슈들을 카운팅 하는 것 부터 시작했습니다. 현재까지 약 4개의 스프린트에서 이슈들에 대한 개수와 분리 작업을 통해 제보되는 개수, 대응하고 처리하는 비율, 백로그로 남겨지는 비율, 많이 발생하는 이슈 등에 대한 수치 파악이 가능해졌습니다.
- 큰 단위의 기능이 배포가 되었을때 자주 발생한 이슈의 개수와 자주 사용하는 기능 사용의 빈도를 예측할 수 있습니다.
- 백로그를 관리해서 선생님들에게 가장 필요한 기능이 무엇인지를 수치적으로 판단할 수 있는 우선순위 근거로 활용할 수 있어졌습니다.
평균적으로 1개의 스프린트를 운영하는동안 약 90개의 이슈 접수에 대해 약 70%를 바로 해결하였으며, 나머지 30%는 백로그로 활용할 수 있게 되었습니다.
더 이상의 반복은 없다! 반복되는 이슈는 해결
이슈들을 카운팅 하다보니 반복되는 이슈들이 눈에 보이고, 중복 해결방법에 대한 노하우가 쌓이게 되었습니다.
1 ) 해결 과정, 이슈 원인 남기기 이슈 재발 방지
우리 개발팀에서는 발생 원인과 해결 방법에 대한 기록을 하여 이 후의 오류에 대해서 원활하게 대응할 수 있도록 하고 있습니다.
2) 자주 나오는 이슈 해결 가이드 배포
잦게 발생하는 이슈들을 파악이 되었으니 가이드를 제공하여, 개발팀에서 확인하는 시간을 대기하지 않아도 오류들을 사전 확인해 나갈 수 있도록 가이드를 제공하고 있습니다. 이 내용을 먼저 봄으로써 간단히 해결할 수 있는 오류는 개발팀이 아니더라도 누구나 다 확인이 가능합니다.
앞으로 해결해야 할 우리의 미션
하지만 위 문제를 해결했다고 해서 끝이 아니죠
여전히 많은 채널로 유저의 목소리가 들려오고 있고, 더욱 좋은 학습관리 제공을 위해서는 자체적으로 더 개선 시켜나가야 하는데요. 이 과제의 다음 개선 액션으로는 이슈 티켓들을 JIRA 와 연동하여 더 효과적으로 관리하고 점차 버그들을 줄여 나가 제품을 완성도를 높이고자 목표 하고 있습니다.
지금 R&D에서 내부에 있는 유저의 VOC 를 들으며 제품을 만들어 나가고 있는데요. 로드맵에 맞게 조직구조를 갖추고 실제로 하나씩 이뤄가고 있어요.
밀당에서 ‘질 높은 교육기회의 평등’ 을 만들어 나가기 위해서 해결해야하는 것들이 굉장히 많이 있습니다.
앞으로 수 많은 버그들을 잡을 뿐 아니라 고객에게 가치를 제공하기 위한 문제를 풀어나가야 합니다.
