강사 스케줄 관리 시스템 프로젝트 회고 -2
목표와 기획 과정 그리고 결과 회고
이전글: 강사 스케줄 관리 시스템 프로젝트 회고 -1
다음글:
목표 설정
이해 관계자들과의 인터뷰를 통해 요구 사항을 충분히 정리한 후, 개인적으로 제가 달성하고자 하는 목표를 세웠습니다.
1. 엑셀 업무에 대한 의존도 감소
운영팀의 업무 중 50% 이상이 엑셀을 활용한 수동 작업이었습니다.
엑셀에서는 히스토리 관리와 수작업에 많은 시간이 소요되므로, 프로젝트를 통해 엑셀 업무를 줄이려는 목표를 세웠습니다.
2. 수업 모니터링 시스템 구축
운영팀에서는 이슈를 사전에 파악하고 예방할 수 있는 기능과 프로세스가 없었습니다.
그래서, 이슈 상황에서 보다 직접적으로 대응할 수 있도록 모니터링 기능을 구현하고자 했습니다.
3. 백엔드 운영 업무의 자동화
여러 프로젝트를 진행하며, 일정에 가장 큰 타격을 주었던 것은 예상치 못하게 발생하는 서비스 운영 관련 이슈들이었습니다.
따라서, 백엔드 팀이 효율적으로 작업을 수행하고 프로젝트에 전념할 수 있는 환경을 만들고 싶었습니다.
기획 & 개발 과정
기획 단계에서는 주로 컨플루언스와 피그마라는 두 가지 도구를 활용하여 작업을 진행하였습니다.
전체 프로세스 중에서 기획을 진행한 부분에 대해 좀 더 상세히 공유드리겠습니다.
프로젝트는 다음과 같은 프로세스로 기획을 하였습니다.
유저 스토리 작성(기능 명세 포함) & IA 작성 → UI 설계 → 디자인 → 개발
유저 스토리
요구 사항을 철저히 검토한 후, 요구 사항에 맞는 업무 플로우를 직접 그려보면서 아래와 같이 유저스토리를 작성해 보았습니다.
사용자(매니저/강사)는 클래스 일정과 학습자 및 강사를 관리하기 위해 스케줄을 모니터링할 수 있다.
사용자(매니저)는 클래스 배정을 위해 배정 가능한 강사 스케줄을 확인할 수 있다.
사용자(매니저/강사)는 근무 가능 일자를 공유하기 위해 강사 스케줄을 등록 및 수정할 수 있다.
유저 스토리 명세의 경우 상황에 따라 간결한 설명으로 작성되곤 하지만, 명료한 기획을 위해 각 기능에 대한 상세한 명세를 포함해 작성하였습니다.
또한, 각 기능에서 누락되는 부분이 없도록 기획 단계에서 테스트 케이스를 간략히 작성하였습니다.
강사 스케줄 유저스토리의 일부분(예시용)IA 작성 및 UI 설계
유저스토리를 기반으로 강사의 스케줄 관리를 위한 정보 구조도(IA)를 설계하였습니다.
2 Depth의 메뉴를 기획하였고, 메뉴 구조에 대한 이해를 돕기 위해 IA에 관한 문서도 별도로 작성하여 관리하였습니다.
1 Depth: 강사 스케줄 관리
2 Depth
강사 스케줄
배정 가능 스케줄
근무 가능 스케줄
강사 스케줄 관리 IA 일부분(예시용)UI의 경우에는 피그마를 통해 작업하였으며, 노트에 팬으로 스케치를 해보고 피그마로 작업하는 방식으로 진행하였습니다.
개발 과정
이 프로젝트는 제가 처음으로 리딩하는 프로젝트였기에, 기획부터 개발 배포까지 진행하는 과정에서 많은 어려움을 겪었습니다.
그중에서도 특히 어려웠던 경험 두 가지를 공유하고자 합니다.
1. 문서 버전 관리
기획, 디자인, 개발의 각 단계를 거치며 발생한 Use Case에 대한 논의와 개발 리소스 관리 등의 이슈로 기획이 계속해서 변경되는 상황이 많았습니다. 이로 인해 문서의 버전 관리에 어려움을 겪었습니다.
물론, 기획이 최신화될 때마다 문서 업데이트에 신경을 썼지만, 컨플루언스와 피그마 두 공간에서 기획서를 동시에 사용하다 보니 관리가 어려웠습니다.
문서 관리에 대한 문제는 여전히 실감하고 있으며, 문서 작성이 주요 업무 중 하나인 만큼, 이 문제를 해결하기 위한 별도의 방안을 찾아보려고 합니다.
2. 상태값(status) 활용 기획
학습자와 수업에 대한 실시간 관리가 어려웠던 문제를 해결하기 위해, 시스템에서 모니터링 기능을 제공하려는 계획을 세웠습니다.
모니터링의 경우 '수업 참여 여부, 실시간 옵저빙, 학습자 및 강사 정보, 수업 상태 조회'와 같은 기능들로 문제를 해결하고자 했습니다. 하지만 '수업 상태 조회'에서 상태값을 활용하는 과정이 어렵게 다가왔습니다.
새롭게 개발하기에는 리소스가 부족했기에 기존에 수업 예약 관리를 위해 구현되어 있었던 상태값을 활용해야 했습니다.
하지만 모니터링 목적에 맞게 상태값을 분류하고 정의하는 과정이 쉽지 않았고 시간과 수업 결과에 따라 상태값을 고려하여 테스트하는 것에는 많은 공수가 들었습니다.
결과적으로 모든 것이 무사히 마무리되었지만, 이 과정에서 새로운 것을 기획하는 것보다 기존의 것을 수정하는 일이 더 어렵다는 것을 알게 되었습니다.
결과적으로,
1. 엑셀 공수가 줄었습니다.
강사들이 시스템을 통해 스케줄을 등록할 수 있게 되었으며, 매니저는 일정을 기준으로 근무 가능한 강사들을 확인하는 것이 가능해졌습니다.
그러나, 모든 강사들을 한 페이지에서 관리하기 위해서는 여전히 엑셀 UI가 필요한 부분이 있었고, 이를 완전히 대체하지 못한 점은 아쉬움으로 남았습니다.
2. 모니터링 시스템을 구현하였습니다.
시스템을 통해 학생들의 결석이나 강사의 노쇼와 같은 이슈를 더욱 신속하게 파악할 수 있게 되었습니다. 또한, 실시간 모니터링을 통해 언제든 상황을 관찰할 수 있게 되어, 이슈에 대해 더욱 빠르게 대응할 수 있게 되었습니다.
3. 백엔드 공수가 줄었습니다.
엑셀 대신 시스템에서 스케줄을 등록하고 수정할 수 있게 되어 매니저가 직접 관리할 수 있게 되었습니다. 이로 인해 백엔드 팀이 스케줄 관리에 직접 개입할 필요성이 줄어들었습니다.
다만, 운영 시간을 조정하는 등 아직까지 일부 상황에서 DB를 건드려야 하는 점이 아쉬웠습니다.
성장을 위한 KPT
Keep
누가 시켜서가 아닌 직접 움직여 이해관계자들에 대한 인터뷰를 진행한 점
프로젝트를 진행하며 동료들과 원활히 커뮤니케이션 한 점
문제 상황에서 당황하지 않고 한 단계식 해결하려 한점
Problem
기획서의 기능 명세가 일관적이지 못한 점
인터뷰를 체계적으로 진행하지 못한 점
서비스의 Use Case 고려가 부족했던 점
문서의 버전 관리가 미흡했던 점
Try
나만의 기획 작성 프로세스 만들기
사용자 인터뷰를 조금 더 체계적으로 할 수 있는 방안을 고민
Use Case를 많이 고민할 수 있는 프로세스 정립
문서 관리에 대한 체계 만들기
끝으로, 프로젝트를 진행하며 생각한 대로 흘러가지 않는 경우가 많았습니다. 이는 계속해서 성장하는 과정이라고 생각합니다. 그러므로 실수나 실패를 두려워하지 않고, 오히려 그것들로부터 계속 배워나가는 자세를 유지하겠습니다.
감사합니다. :)
정리
1. 요구 사항을 정리한 후, '엑셀 의존도 감소, 모니터링 시스템 구축, 백엔드 업무 자동화'라는 목표를 세웠음
2. ‘유저 스토리 작성(기능 명세 포함) & IA 작성 → UI 제작 → 디자인 → 개발’의 프로세스로 기획을 진행함
3. 유저스토리는 업무 플로우를 그려보며 작성하였고 명료한 기획을 위해 각 기능에 대한 상세한 명세를 포함하였음
4. 메뉴 구조에 대한 이해를 돕기 위해 유저 스토리를 기반으로 IA를 문서화하여 관리함
5. 개발 배포까지 진행하며 문서의 버전 관리와 상태값 활용 기획에 어려움을 겪음
6. 결과적으로 엑셀 공수 감소, 모니터링 시스템 구현, 백엔드 공수 감소의 효과를 얻었음
7. 하지만, 엑셀을 완벽히 대체하지 못했고, 일부 상황에서는 여전히 DB를 관리해야 하는 점이 아쉬웠음
8. 프로젝트를 진행하며 생각한 대로 흘러가지 않는 경우가 많았음 하지만, 이는 성장하는 과정이며 계속 배워나가는 자세를 유지하려 함
