제목 후보
•
유저의 의존성이 높은 워크스페이스 프로덕트에서 중요한 것
•
밀당 R&D가 급한 이슈에 대응하는 방법
•
워크스페이스를 만드는 팀의 이슈 대응 방법
•
밀당의 일하는 환경을 만드는 사람들
•
중요하지 않다고 생각하는 일을 중요하게 만드는 방법
•
이슈 트러블 슈팅하기
전달 하고자 하는 내용
•
밀당 R&D 팀의 목표
•
밀당 개발팀이 일하는 방법
•
내부 유저에 초점을 맞춘 프로덕트
끄적임
업로드 글 초안
제목
1.
유저 인게이지먼트가 높은 제품팀의 VOC 수집 & 대응 방법
2.
유저 인게이지먼트가 높은 제품에서 이슈 대응하는 제품팀 
안녕하세요! 밀당 Product Manager 유현영입니다.
사실 저는 PM으로 입사해서 일한이 이제 한 5개월이 되어가는 신입이랍니다. 밀당에서 일하면서 너무 리스펙하는 팀원들과 함께 프로덕트를 만들어나가고 있는데, 저희 팀의 노력과 문화가 외부에 잘 알려지지 않은 것 같아, 이 글을 시작으로 R&D가 일하는 방식들을 하나하나 소개하고자 합니다.
제가 밀당에 합류해서 가장 먼저 해야겠다고 생각한건 우리가 지금 우리 R&D가 해결해야하는 문제를 파악하고 인지하는 것이 중요하다고 생각했었습니다.
그래서 사용자들이 가장 많이 쓰고 있는 프로덕트에서 어떤 불편함이 많은지 이슈가 들어오는 채널을 관찰하면서 일원화하고 정리한 과정을 소개 드리겠습니다.
그전에 먼저 밀당은
"질 좋은 교육의 평등"을 목표로
전국, 나아가 전 세계의 모든 아이들에게 높은 수준의 교육을 제공하고자 합니다.
저희 R&D 팀은 이 목표를 실현하기 위해, 아이들에게 1:1 수업을 제공해주고 있는 ‘온택트 선생님’들과 학습에 효과적인 학습 자료들을 제작하고 있는 ‘콘텐츠 스페셜 리스트’ 팀원들이 사용하는 어드민에 가까운 프로덕트를 주로 개선하고 있습니다.
밀당PT는 학생들이 학습하는 페이지,
학생들의 학습 상황을 모니터링하고 관리하는 페이지(LMS, Learning Management System), 학생들의 학습 콘텐츠를 업로드하고 관리하는 페이지(CMS, Content Management System)로 나뉘어 있습니다.
LMS와 CMS는 어드민의 성격이 강하지만 300명이 넘는 온택트 선생님과 콘텐츠 스페셜리스트분들의 입장에선 매일 매일 사용하는 서비스 인거죠. 선생님들이 학생들과 직접 접하는 인터페이스 역할을 하기 때문에 매우 중요합니다.
선생님이라는 인터페이스가 아이들에게 제공되는 프로덕트이기 때문에 선생님들의 학습 관리 효율 극대화와 워크 스페이스의 이슈가 생기지 않는게 중요합니다. 따라서 우리는 사용 유저당 인게이지먼트가 높은 프로덕트를 만들고 있기 때문에 내부 프로덕트에 대한 이슈에 대해서 빠른 처리가 중요했습니다. 회사 내부에도 고객이 있어서 빠른 대응이 필요한게 핵심입니다.
만일 서버 하나라도 고장났다가는 최소 300명의 선생님들과 15,000명의 학생들이 수업 진행하고 하는데 갑자기 수업이 중단되어 버리게 되는 상황이 발생되게 된답니다. 조금만 느려지더라도 많은 학생을 관리하고 있는 선생님들에게는 1초가 1시간 처럼 길게 느껴질수 있습니다.
서버가 잠시라도 멈추면 수업 진행 난리가 나는..
바로 옆에 "그만큼 대응과 동시에 단점이 있었습니다."
띄고
회사 내부에 많은 유저들이 있을 때
1. 프로덕트에서 발생하는 각종 이슈들을 어떻게 개선하는지
2.우리 제품팀이 어떻게 일하고 있는지
소개 드리겠습니다.
로 가면 더 잘 읽힐 거 같다는 개인적인 생각입니당 ㅎㅎ
Plain Text
복사
문제 1. 이슈 우선순위를 모르겠어요
‘인입된 이슈는 바로 처리해 줘야 해’ 라는 생각을 갖고 모든 이슈를 빠르게 처리하려고 애썼어요.
이 때문에, 사실은 계획했던 기존 업무가 더 시급하고 중요도가 높음에도 불구하고 이슈 해결을 하느라 기존 과제의 우선순위가 밀리는 경우가 빈번하게 발생하고 있습니다.
메인 스프린트 과제를 해결해나가면서 이슈들을 처리했는데, 더 중요한 메인 과제 해결을 위해서 시간을 확보하여 꼭 담당자가 아니더라도 이슈를 확인할 수 있는 시스템이 필요 했습니다.
문제 2. 다양한 채널에서 산재되어 들어오는 이슈
각 본부와 소통하고 있는 채널마다 버그나 이슈가 제보되고 있었습니다. 약 10개 정도의 채널에서 제보되는 이슈들을 모든 개발 팀원들이 커뮤니케이션 채널에 다 들어가 있어야만 했습니다.
접수되는 채널들이 많아지니 해당 이슈가 해결이 되었는지, 어떻게 되었는지, 진행 상황을 여러명에게 물어보아야 하고, 커뮤니케이션이 넘 힘들다는 문제가 있었습니다.
또한 각각의 팀원들에게 DM 으로 와서 리소스 트레킹도 어려울 뿐더러 동일하게 발생하고 있는 이슈들이 중복으로 제보되고는 했습니다.
해결책
해결 1. 이슈 우선순위를 모르겠어요 → 정말 급하신가요?
1) 유저에게 급한 정도에 대한 판단을 주었습니다
•
지금 바로 해결이 필요해요 / 급하지는 않아요 로 개발팀에서 빠르게 대응 필요가 있는 것과 그렇지 않은것의 판단을 하게 했습니다. •
실제로 중요하고 시급한 업무에 집중할 수 있도록, 급한 알림은 바로 해결할수 있도록 슬랙 연동을 해놓고, 대응하고 있습니다.
•
나머지 급하지 않은 사항은 주에 한번씩 처리를 하거나 백로그로 놓고 다음 스프린트 과제로 챙기고 있습니다. :face_with_spiral_eyes:
해결 2. 다양한 채널에서 산재되어 들어오는 이슈 → 한 채널에서 확인 하실 수 있습니다
1) 이슈 접수 양식 및 채널 일원화
2) 처리 현황 공유
•
급건은 아니지만 아이디어들은 일주일이내에 확인해서 답변을 남겨 놓을게요
◦
확인중
◦
해결완료
◦
백로그
해결 3 → 반복되는 이슈는 해결
이렇게 빠르게 대응 할 수 있는 시스템을 만들었으면, 이제 반복되는 이슈에 대한 트레킹도 파악이 가능해졌습니다.
1) 해결 과정, 이슈 원인 남기기 이슈 재발 방지
2) 동일한 이슈 대응 가이드 배포
•
어떤 오류 유형이 많이 발생하는지 알기에 기능별 유형화가 되었습니다.
•
개발 우선순위상 빠르게 해결이 어렵거나 사용의 불편함으로 반복 되어서 나오는 이슈들은 이렇게 해결 가이드를 배포하여, 반복되는 이슈 제보 대응을 더 원활하게 하고자 했습니다.
3) 이슈 리포팅
•
위 이슈들을 가지고서 스프린트 1개 운영을 했을때 제보되는 개수, 대응하고 처리하는 비율, 백로그로 남겨지는 비율, 많이 발생하는 이슈 기능들에 대한 통계 파악이 가능해졌습니다.
•
큰 단위의 기능이 배포 되었을때 얼만틈 이슈들이 발생했고, 기능 사용의 빈도가 있는지도 예측할 수 있습니다.
주간 이슈 처리 현황 리포팅
월간 이슈 리포트
이러한 접근 방식을 통해, 우리는 한 스프린트 동안 약 90개의 이슈 접수에 대해 70%를 바로 해결하였으며, 나머지 30%는 백로그로 활용하고 있습니다.
현재까지 약 4개의 스프린트에서 이슈들에 대한 개수와 분리 작업을 통해 가장 많이 발생하는 이슈와 기능들에 대한 통계 파악이 가능해졌으며, 백로그를 관리해서 선생님들에게 가장 필요한 기능이 무엇인지를 수치적으로 판단할 수 있는 우선순위 근거로 활용할 수 있어졌습니다.
앞으로 미션
하지만 위 문제를 해결했다고 해서 끝이 아닙니다.
여전히 많은 채널로 유저의 목소리가 들려오고 있고, 더욱 좋은 학습관리 제공을 위해서는 자체적으로 더 개선 시켜나가야 하는데요. 다음 개선 액션으로는 아래와 같은 문제 해결을 해보고자 하고 있습니다.
자동화
•
이슈 제보 확인 되면 바로 티켓화 하여 관리 할 수 있도록 하기 → 리소스 파악
•
R&D 에서 해당 기능 자동 담당 배정
•
이슈 발생 시점이 퇴근 시간 이후 발생하여 이후에도 빠르게 대응할 수 있는 시스템
•
내부에서 본 과제 방해받지 않고도 원활히 움직일 수 있는 방향 고민하기
지금은 로드맵에 맞게 조직구조를 갖추고 실제로 하나씩 이뤄가고 있어요.
이렇게 R&D에서 내부에 있는 유저의 VOC 를 들으며 제품을 만들어 나가고 있는데요
밀당에서 ‘질 좋은 교육의 평등’ 을 만들어 나가기 위해서 해결해야하는 것들이 굉장히 많이 있습니다.
앞으로 아티클을 통해서 저희가 가지고 있는 목표뿐 아니라 저희의 조직 문화도 차차 소개 드리도록 하겠습니다.
함께 고속 성장할 멋진 동료를 찾고 있어요!
•
개발팀에서는 찾게 발생하거나 크리티컬한 오류들을 재발을 막을 수 있는 프로세스로 개선하거나 원인들을 남겨 놓아 개발 시스템을 보완시켜나가고 있습니다.