강사 스케줄 관리 시스템 프로젝트 회고 -1
기획의 Flow와 요구사항 확인 및 문제 정의
이전글: 나만의 1 Pager 기획서 'Pitch deck'
다음글:
Intro
현재 제가 재직 중인 회사는 영어 발화 게임과 화상 교육 서비스를 운영 중에 있습니다. 그리고 화상 교육은 바이링구얼 한국인 강사들이 1:1로 수업을 진행하고 있습니다.
하지만 운영팀에서 강사들을 관리하는 과정에서 비효율적인 수기 작업이 있었고, 이런 상황이 지속되면 서비스 확장 시 관리가 어려워질 것으로 판단되었습니다.
따라서 이번 글에서는 이러한 작업을 해결하기 위한 여러 프로젝트 중 제가 처음으로 A to Z까지 진행한 ‘강사 스케줄 관리 기능’ 기획에 대한 회고 글을 작성해보려 합니다.
어떤 과정으로 기획을 진행하였고 기획을 통해 어떤 어려움을 겪었는지 공유드리도록 하겠습니다. :)
프로젝트 Flow
이번 프로젝트를 진행하며 어떤 Flow로 기획을 진행했는지 간략하게 말씀드리겠습니다. 팀 구성은 Front 2, Back 2, UX/UI 1, PM 1의 구성으로 진행하였습니다.
프로젝트 진행 과정
프로젝트는 '요구 사항 수집 -> 유저 스토리, IA 작성 관리 -> 와이어프레임 UI 제작 -> 기획 리뷰 -> UX/UI 디자인 진행 -> 디자인 리뷰 -> 개발 진행 -> QA후 배포' 순으로 진행되었습니다.
1. 요구 사항 수집
우선, 프로젝트의 효과성을 위해 강사 스케줄이 필요한 이유와 현재의 운영 방식을 알 필요가 있다고 생각했습니다. 따라서 운영팀을 찾아가 업무 방식과 수기 작업이 들어가는 부분을 파악하려 했습니다.
2. 유저 스토리, IA 작성 관리
프로젝트에 대한 Flow를 그려보며 사용자의 시나리오를 확인하려 했습니다. 또한, 시나리오를 통해 유저 스토리를 작성하며 사용자의 행동을 확인하고 필요한 기능들을 파악하며 IA를 작성했습니다.
3. 와이어프레임 UI 제작
저희 팀은 일반적으로 UI는 디자이너가 담당하지만, 간략한 UI를 만들 수 있는 능력도 갖추어야 했기에 이번 프로젝트에서는 피그마를 통해 UI를 작성했습니다. 현재까지도 피그마가 익숙지 않아 스터디에 대한 필요성을 느끼고 있습니다…
여기저기 들고 와서 만든 못생긴 나의 와이어프레임 일부4. 기획 리뷰
팀 전체를 대상으로 제작한 와이어프레임(UI)과 기획서(유저스토리)를 보여드리며 첫 리뷰를 진행하였습니다. 지금 생각해 보면 엄청 긴장되고 떨렸던 것 같습니다. 수많은 피드백과 함께 기획을 보완하며 2차 리뷰를 거쳤고 본격적인 디자인이 진행되었습니다.
5. UX/UI 디자인 진행
디자이너 분들은 단순히 UI만 그리는 게 아니라 UX에 대한 고민도 함께 진행합니다. 때문에 디자인을 진행하면서도 기능의 Flow나 인수조건에 대한 논의를 계속해서 진행하며 수정 보완했습니다.
6. 디자인 리뷰
확실히 완성된 디자인을 보면, 기획 단계에서 의도했던 서비스와 기능이 더욱 명확하게 전달되는 것 같습니다. 디자인이 완성되었을 때, 일정 및 리소스에 대해 개발자들과 조금 더 상세히 논의할 수 있었습니다.
7. 개발 진행
개발을 진행하면서 백엔드 기획이 정말 어려운 작업임을 깨달았습니다. 특히, 다양한 스케줄 상태에 따라 상태 값을 할당하고 구분하는 작업을 진행하였는데 다양한 Use Case가 발생해서 매우 복잡했었습니다. 기획은 시작부터 완성까지 계속해서 조율하고 수정하는 것이라는 생각이 들었습니다.
8. QA 후 배포
QA팀이 따로 없었기에 제가 QA까지 함께 진행하였고 QA는 내부, 외부 2단계로 나누어 진행하였습니다. 백오피스 기획은 기능 자체의 러닝 커브가 높기 때문에 다른 팀과 함께 진행하는 외부 QA에 생각보다 많은 리소스가 들어가 적합하지 않다는 것을 깨달았습니다.
요구 사항 확인 및 문제 정의
요구 사항을 파악하기 위해, 저는 직접 운영팀에 찾아가 업무 프로세스에 대한 설명과 인터뷰를 요청드렸습니다. 인터뷰를 진행하면서, 생각지도 못한 문제들을 파악할 수 있었습니다.
문제 정의
1. 수기 공수가 높은 엑셀 프로세스
운영팀의 업무 중 강사들의 전체 상황을 파악하고 학습자를 배정하는 업무가 있었습니다. 스케줄 관리 기능이 없어, 엑셀을 통해 운영팀에서는 강사 스케줄을 수동으로 취합하여 작성해야 했습니다. 이 과정에서 상당한 시간과 리소스가 소모되는 것이 문제였습니다.
2. 학습자 모니터링 기능 부재
화상 수업의 특성상 개인 시스템 환경에 따른 접속 문제가 빈번했고 시스템 오류가 생겼을 때, 즉각적인 대응이 어려웠습니다. 당시에는 운영팀이 강사들과 수동으로 연락하여 관리했지만, 시스템에서 정상 수업 여부를 직접 확인하고 대응할 수 있는 기능이 필요하다고 생각했습니다.
3. 비효율적인 백엔드 운영 리소스
화상 수업을 신청하기 위해서는 학습자가 일정을 선택해야 합니다. 이때, 시스템에서 강사 스케줄을 조회하며 신청 가능 일정을 확인합니다. 그러나 백엔드에서 강사 스케줄 티오를 관리하고 있었기에 강사의 스케줄 변경, 또는 강사의 추가 혹은 이탈 상황에서 백엔드가 수동으로 처리해야 하는 부담이 있었습니다.
이 외에도 여러 이슈가 있었지만 대표적인 문제만 기술하였습니다. 위와 같이 문제를 정의하였고 문제를 해결하기 위한 목표를 잡고 이를 위한 시나리오를 그려가며 유저스토리를 작성하였습니다.
프로젝트 목적 및 기획 과정 그리고 결과는 2부에서 추가로 말씀드리도록 하겠습니다.
감사합니다.
정리
1. 운영팀에서 강사들을 관리하는 과정에서 비효율적인 수기 작업이 많았음
2. 문제를 해결하기 위해 강사 스케줄 관리 기능 프로젝트를 기획하게 되었음
3. 프로젝트는 요구 사항 수집 → 유저 스토리, IA 작성 관리 → 와이어프레임 UI 제작 → 기획 리뷰 → UX/UI 디자인 진행 → 디자인 리뷰 → 개발 진행 → QA후 배포 순으로 진행함
4. 요구 사항 파악을 위해 직접 운영팀에 찾아가 업무 프로세스에 대한 설명과 인터뷰를 요청함
5. 문제 1: 관리 기능 부재로 강사 스케줄을 수동으로 취합하여 작성해야 했음
6. 문제 2: 시스템 환경 및 오류에 대응하기 위한 체계 및 기능이 없었음
7. 문제 3: 백엔드에서 강사 스케줄 티오를 관리하고 있었고 변경 사항에 대한 부담이 있었음
