자리비움 보고의 진짜 의미

부트캠프 내부 규칙에는 '자리비움을 팀원에게 미리 보고하기'가 있었다. 서로를 위한 매너의 차원에서 있었던 규칙이었다.

우리 팀은 초기에 슬랙 채널에 자리비움을 보고했다. 하지만 팀원 5명이 돌아가며 결석하거나 조퇴하거나 외출하다 보니 누가 언제 자리를 비울 예정인지 기억하기가 점점 어려워졌다. 게다가 실제로 자리비움 보고체계를 사용(?)해 보니, 자리비움 일정은 '이때 빠질 거예요'에서 끝나는 정보가 아니었다. 누가 언제 자리를 비웠고, 어떤 내용을 보충해 얼라인해야 하는지 확인하기 위해서도 필요한 정보였던 것이다. 즉, 아카이빙이 필요했다. 하지만 슬랙을 통한 자리비움 보고는 이후 검색은 가능했지만 일정이 구조화되어 쌓이지 않았고, 무료 플랜에서는 오래된 메시지를 계속 확인할 수도 없었다.

더군다나 부트캠프는 오전 9시부터 오후 9시까지 진행됐고, 팀 프로젝트와 논의도 수시로 이어졌다. 한 번 자리를 비우면 강의뿐 아니라 팀에서 오간 결정과 맥락까지 놓치기 쉬웠다. 처음에는 다른 팀에서 흔히 사용하던 것처럼 팀 노션 메인 페이지의 메모란에 일정을 적는 방식을 고려했다. 별도의 도구를 만들 필요가 없고 누구나 바로 입력할 수 있다는 점에서는 가장 간단한 방법이었다.

하지만 메모란은 기록을 계속 누적하기 어려웠다. 누군가 정기적으로 내용을 정리해야 했고, 지난 기록을 남기려면 별도로 아카이빙해야 했다. 기록을 지우고 나면 특정 날짜의 자리비움 여부를 확인하기 위해 당사자에게 다시 묻는 작업, 그 당사자가 과거 일정을 확인하는 작업까지 필요했다.

그렇다고 별도의 출결 관리 시스템까지 만들 필요는 없어보였다. 단기간에 피그마/노션/슬랙/프레이머/SQL 등 다양한 툴을 처음 접해 버거워하는 팀원들도 있었기에 툴 확장은 더욱 부적절했다. 팀원이 쉽게 등록할 수 있고, 다른 일정과 함께 확인할 수 있으며, 이전 기록이 남는 정도면 충분했다. 무엇보다 한 사람이 계속 정리하지 않아도 유지되어야 했다.

문제: 기록은 남길 수 있었지만 입력이 어려웠다

팀 노션에는 내가 만들어둔 일정 데이터베이스가 이미 있었다. 여기에 자리비움 일정을 직접 추가하게 하면 회의와 마감 및 제출, 아티클 카타, 자리비움 기록을 한곳에서 관리할 수 있었다. 페이지 템플릿을 만들어두면 입력 형식도 통일할 수 있을 것 같았다.

하지만 직접 사용하게 해보니 문제가 나타났다. 입력이 번거로웠던 것이다.

노션에 익숙하지 않은 팀원은 데이터베이스에 페이지를 추가하고, 여러 속성을 채우고, 시작일과 종료일을 설정하는 과정을 어려워했다. 노션에 익숙한 팀원에게도 매번 템플릿을 찾고 필요한 속성을 빠짐없이 입력하는 일은 번거로웠다.

기존 메모란보다 기록은 체계적으로 남길 수 있었지만, 입력 단계가 늘어나면서 사용자의 부담도 커졌다. 나중의 협업 비용을 줄이기 위해 지금의 불편을 반복해서 감수하게 하는 방식은 지속되기 어렵다고 판단했다.

물론 필요성을 설명하고 성실하게 입력해달라고 요청할 수도 있었다. 하지만 기능의 필요성을 이해하는 것과 매번 정확하게 행동하는 것은 다른 문제였다. 사용자의 협조에 기대기보다, 입력 과정 자체를 줄여야 했다.

가설

  • 데이터베이스를 직접 다루지 않고 폼으로 필요한 정보만 입력하게 하면 노션 숙련도와 관계없이 사용할 수 있을 것이다.
  • 제품이 이미 알고 있거나 추론할 수 있는 정보는 자동으로 입력하면 반복 선택과 입력 오류를 줄일 수 있을 것이다.

해결책 1. 데이터베이스 대신 폼으로 입력하게 하기

먼저 기존 일정 데이터베이스에 연결된 자리비움 전용 폼 뷰를 만들었다. 팀원이 직접 페이지를 만들거나 속성 구조를 이해할 필요가 없도록 입력 항목은 네 가지로 제한했다.

  • [선택] 자리비움 유형: 결석, 조퇴, 늦참, 외출
  • [텍스트] 이름
  • [텍스트] 요약: 간단한 사유
  • [날짜] 일시: 시작 및 종료 시간

팀원은 일정 캘린더 상단의 '자리비움 일정 추가하기' 버튼을 누르면 바로 폼에 진입할 수 있었다. 폼을 제출하면 일정이 캘린더에 등록되고, 잘못 입력하거나 일정이 바뀐 경우에는 등록된 페이지에서 수정할 수 있게 했다. 수정은 자주 발생하는 이벤트가 아닐 것으로 가정했다.

폼을 사용한 이유는 단순히 화면을 바꾸기 위해서는 아니었다. 혼란을 최소화하기 위해 입력이 필수적인 속성 항목만 선별해서 보여줄 필요가 있었다. 데이터베이스 페이지에서는 사용자가 모든 속성을 보고 수정할 수 있지만, 폼에서는 필요한 항목만 순서대로 보여줄 수 있었다. 그 결과 다른 일정 속성을 잘못 건드릴 가능성을 줄이고, 노션 사용법을 잘 몰라도 같은 형식으로 일정을 등록할 수 있었다.

해결책 2. 이미 정해진 정보는 다시 선택하지 않게 하기

기존 일정 데이터베이스에는 회의, 마감, 자리비움 등을 구분하는 ‘일정 유형’ 속성이 있었다. 일반적인 방식대로라면 자리비움 전용 폼에 들어온 뒤에도 사용자가 일정 유형에서 다시 ‘자리비움’을 선택해야 했다.

하지만 사용자는 이미 자리비움을 등록하기 위해 해당 폼에 들어온 상태다. 여기에서 다시 ‘자리비움’을 선택하게 하는 것은 제품이 이미 알고 있는 정보를 사용자에게 한 번 더 입력하게 하는 일이었다. 사용자가 실제로 판단해야 하는 것은 이 일정이 자리비움인지 아닌지가 아니라, 결석·조퇴·늦참·외출 중 어떤 유형인지였다. 따라서 폼에서는 세부 유형만 선택하게 하고, 상위 분류인 ‘일정 유형’은 자동화로 입력하기로 했다.

자리비움 유형에 결석, 조퇴, 늦참, 외출 중 하나가 입력되면 해당 페이지가 자동으로 자리비움 일정으로 분류되도록 설정했다. 일정 제목도 별도로 작성하지 않아도 ‘{이름} 자리비움’ 형태로 생성되게 했다.

최종적으로 팀원이 해야 할 일은 버튼을 누르고, 자리비움 유형과 일시를 선택한 뒤 이름과 사유를 입력하는 것이 전부였다. 데이터베이스의 구조를 이해하거나 일정 제목과 상위 분류를 반복해서 입력할 필요는 없었다.

결과: 질문 없이 쓰이고, 관리 없이 쌓였다

기능을 처음 안내한 뒤 사용 방법에 대한 질문은 나오지 않았다. 회의 중 한 팀원이 “내일 5시에 병원 때문에 조퇴한다”고 말하니 이를 들은 다른 팀원이 별도의 설명 없이 먼저 일정으로 등록하는 일도 일어났다. 팀원들이 사용법을 따로 학습하지 않아도 타팀원을 위해 바로 사용할 수 있을 만큼 입력 흐름이 자연스럽고 편안하게 받아들여진 것이다.

등록된 자리비움 일정은 회의와 마감 등 다른 팀 일정과 함께 주간 캘린더에 쌓였다. 누가 언제 자리를 비울 예정인지 한눈에 확인할 수 있었고, 지난 일정도 남아 이후에 다시 찾아볼 수 있었다.

내가 했던 것은 이미 사용 중인 일정 데이터베이스에 폼과 자동화를 더한 것뿐이다. 별도의 출결 시스템을 만들 필요는 없었다. 그럼에도 팀원에게는 직접 데이터베이스를 다루는 것보다 간단한 입력 방식을 제공하면서도, 팀에는 지속해서 쌓이는 기록을 남길 수 있었다.

작은 기능이었지만 사용자의 성실함에 기대는 대신, 필요한 행동이 자연스럽게 이루어지도록 입력 구조를 바꿔서 보람있었던 경험이었다.

 

SERIES

조직 생산성 향상을 위한 작은 시도들