회사에서 예약할 게 이렇게 많았나 (2)
문과생 유목이의 개발일지 · 2화
문제를 풀기로 마음먹고 가장 먼저 한 일은, 코드를 짜는 게 아니라 종이에 목록을 적는 일이었다.
우리 회사에서 '예약'이라는 단어가 붙는 것들을 전부 적어봤다.
적어보니 열 개가 넘었다
회의공간
- 대회의실 (3층)
- 소회의실 A, B (2층)
교육공간
- 교육실 (5층)
차량
- 법인차 3대
장비
- 촬영장비 세트
- 공용 노트북 4대
- 이동형 프로젝터 2대
직원 210명 규모 회사. 평소에 난 여기 구멍가게라고 자학을 하던 이 회사에 이리도 예약해야 할 목록이 많았단 말인가? 그리고 이것들은 관리 주체가 제각각이었다. 회의실은 내가, 법인차는 총무 담당 선배가, 촬영장비는 마케팅팀이 각자 자기 방식대로 관리하고 있었다.
법인차를 쓰려면 총무 선배한테 메신저를 보내야 하고, 촬영장비를 쓰려면 마케팅팀 단톡방에 물어봐야 했다.
그런데 구조는 전부 똑같았다
목록을 한참 들여다보다가 한 가지를 알게 됐다.
종류는 전부 다른데, 예약이라는 행위의 구조는 완전히 똑같았다.
누가 / 무엇을 / 언제부터 / 언제까지 사용하는가
회의실이든 법인차든 카메라든, 이 네 가지만 정해지면 예약은 성립한다. 그리고 "같은 물건을 같은 시간에 다른 사람이 이미 쓰고 있는가"만 확인하면 가능 여부도 판단된다.
대회의실 예약과 법인차 예약은 서로 다른 업무처럼 보이지만, 안을 들여다보면 완전히 같은 계산이다. 물건 이름만 바뀔 뿐이다.
그래서 방향을 이렇게 잡았다
여기서 프로젝트의 방향이 정해졌다.
회의실 예약표를 만드는 게 아니라, 자원 종류에 상관없이 쓸 수 있는 공용자원 예약 시스템을 만들자.
정리한 목록을 들고 갔더니 김 팀장님이 이렇게 물었다.
"유목 씨, 회의실만 먼저 해보는 게 낫지 않아?"
맞는 말이었다. 범위를 좁히면 빨리 끝난다. 그런데 목록을 이미 적어본 뒤라 마음이 바뀌어 있었다. 회의실만 생각하고 만들면, 나중에 법인차를 붙일 때 "차량은 운행 기록이 필요한데", "차량은 반납 확인이 필요한데" 같은 요구가 나올 때마다 처음부터 다시 만들어야 할 게 눈에 보였다.
반대로 처음부터 '자원'이라는 하나의 개념으로 묶어두면, 새 자원을 추가하는 일이 데이터를 한 줄 넣는 일로 끝난다.
그리고 하나 더. 자원마다 담당자가 다르다는 문제도 여기서 같이 풀린다. 예약 창구가 하나면, 직원은 뭘 빌리든 같은 곳에 가면 된다.
이 시점에서 만들고 싶은 게 명확해졌다.
직원이 아무한테도 물어보지 않고, 한 페이지에서, 회의실이든 차든 장비든 빈 시간을 직접 확인하고 예약하는 것
문제는 내가 개발자가 아니라는 점. 그래서 처음 손댄 건 내가 제일 잘 아는 도구였다.
다음 편 — 엑셀 예약표는 사흘 만에 무너졌다 (3)
※ 이 연재에 등장하는 ㈜세움과 모든 인물은 가상이다. 기술적인 구성과 시행착오는 실제 구축 경험을 바탕으로 재구성했다.
댓글
댓글 쓰기