스타트업에서 효율적으로 일하는 방법 4단계
알라미 팀에 합류했을 때, 업무관리가 쉽지 않았다. 팀의 스프린트 운영이 전 회사와 달랐기 때문이다. 전엔 한두 개의 업무를 집중적으로 진행했다면, 알라미 팀은 여러 업무를 동시에 진행했다. 그러다 보니 업무 진행을 균형 있게 운용해야 했고 개 중 놓치는 것이 없는지 꼼꼼하게 챙겨야 했다.
1단계 : 캘린더 뷰 + 1일 단위 할 일 목록
첫 한달은 개인 노션에 캘린더 뷰로 일단위 To do list를 작성했다. 캘린더 뷰를 사용했기 때문에 날짜는 기록할 필요가 없었고 그날 할 일만 작성하면 되었다. 그러나 사용 가능한 시간만큼 업무를 할당했음에도 시간이 항상 부족했다.
도대체 그 많던 시간이 어디로 간 걸까? 혹시 중간에 너무 많이 쉬었나? 비효율적인 작업이 있었나? 추측되는 원인이 너무 많았다. 결국 시간을 측정해서 정확한 원인이 무엇인지 찾기로 했다.
2단계 : 캘린더 뷰 + 1일 단위 할 일 목록 + 작업 로그
출근을 하면 문서를 생성한 뒤 업무의 시작, 종료 시간을 작성했다. 2단계 형식의 장, 단점은 다음과 같다.
장점
- “한 것도 없이 시간이 갔다”에서 “한 것도 없이” 대신 무엇을 해서 시간이 갔는지 알 수 있다. 아무것도 하지 않았는데 시간이 갔을 리 없다.
- 작업마다 대략 어느 정도 시간이 걸리는지 알 수 있다. 즉 나의 예상치와 결괏값을 비교함으로써 얼마나 차이가 발생했는지 알 수 있다.
단점
- 하루에 진행한 업무량을 보기엔 편하지만, 실제로 업무 1개당 얼마나 시간이 걸렸는지 알기 어렵다. 보통 업무는 하루 안에 끝나지 않고 다른 날에 쪼개어 작업하지만 문서는 하루 단위로 작성한다. 때문에 업무 1개에 사용한 전체 시간을 알기 위해선 문서마다 입력한 시간을 수동으로 더해야 한다.
3단계 : 스프린트 단위로 기록 자동 합산
한 달동안 사용한 첫 업무일지 형식은 장점보다 단점이 크다고 느껴졌기 때문에 몇 가지를 개선했다.
새로 개선된 업무일지 형식은 다음과 같다.
1. 문서 생성
- 주 단위로 문서 생성
- 문서 제목 : N월 N주 + N분기 N번째 스프린트
2. 문서 내용
- 스프린트 업무 목록 : 한 스프린트 동안 진행할 업무 목록
- Surprise : 진행할 업무 외에 갑자기 발생한 업무
- 월요일 ~ 금요일 : 그날 진행한 업무와 사용한 시간 및 컨디션 상태 기록
- Meeting log : 그 주에 진행한 회의별 진행상황 기록
“스프린트 업무 목록 ”의 상세 작업과 소요시간은 입력하지 않아도 된다.
“스프린트 작업 로그” 데이터 베이스를 관계형으로 연결했기 때문이다. 소요시간은 테이블의 합계 기능을 이용해서 총얼마의 시간을 썼는지 볼 수 있다.
요일별로 들어가는 “스프린트 작업 로그”의 관련 업무도 마찬가지다. 따로 입력할 필요 없이 “스프린트 업무 목록”을 관계형으로 연결한 뒤 관련 업무를 검색 후 클릭하면 된다. 이때 주의사항은 요일별로 테이블을 만들면 안 된다. 스프린트 마지막 요일까지 “스프린트 작업 로그”를 링크 복사해서 입력을 해야 한 곳에 데이터가 쌓일 수 있다.
해당 템플릿을 이용하면 입력한 작업이 카테고리별로 분류되기 때문에 업무에 얼마나 시간을 썼는지 수동으로 계산하지 않고 한눈에 볼 수 있다.
업무일지를 개선한 다음 회사 노션에 공개적으로 작성하기 시작했다. 때문에 다른 사람들이 언제든 내가 무슨 일을 하고 있는지 알 수 있었다. 원래 회사 Slack에 Daily Scrum 채널이 따로 운영되고 있었다. 의무는 아니었지만 스쿼드 멤버들 모두 이 채널에서 작성했다. 작성양식은 어제 무엇을 했고 오늘 무엇을 할지 적는, To do list 형태였다.
To do list만 작성해도 업무 운용이 잘 되도록 하기 위해선 아직 리소스 측정 연습을 더 해야 한다 판단했다. 업무 공유는 협업의 중요한 요소 중 하나이기 때문에 팀원들에게 업무를 공유하는 방법을 따로 만든 것이다.
업무일지는 디자인그룹 노션 내에 작성되었고 누구든 들어와서 볼 수 있었다. 그리고 업무일지를 2개월 정도 작성했을 때, 해당 업무일지를 디자인 그룹 내 문화에 포함하기로 결정되었다.
당시 디자인 그룹은 항상 리소스가 부족한 상황이었고 시간에 쫓겨 일을 하곤 했다. 해당 업무일지 양식은 업무에 리소스를 얼마나 투자하고 있는지 효과적으로 알 수 있는 형태여서 디자인그룹이 사용 가능한 시간만큼 일을 하고 있는지 또는 초과해서 하고 있는지를 쉽게 알 수 있었다. 그렇게 해서 디자인 그룹은 업무일지를 작성하기 시작했다.
이후 디자인 그룹은 기존에 파악하고 있던 것보다 리소스를 얼마나 더 쓰고 있는지 알 수 있었고 스프린트 운영 시 개인의 사용 가능한 시간 안에 업무 운용이 가능했다.
4단계 : 시간 구멍 찾기
여러 번의 업무일지 작성으로 어느 정도 리소스가 필요한지 예상이 되었고 이를 토대로 스프린트를 진행했음에도 여전히 시간이 부족했다. 왜일까? 분명 2시간 정도면 끝날 법한 일이 항상 3시간이 걸리곤 했다. 업무 일지로 해결하기 어렵다고 느낀 나는 자기 개발서와 생산성 관련 책을 찾아 읽었다.
그중 가장 도움이 되었던 책 두 권을 소개한다.
1권은 “일이 편해지는 TO DO LIST 250 ”이고 나머지는 “메이크 타임”이다.
두 권 모두 시간과 업무를 효율적으로 운용하는 방법을 소개하는 책이다.
만약 IT업계에서 Sprint 방식으로 일하고 있다면 후자를 더 추천한다.
책을 읽고 깨달은 점은 어떤 일에서 다른 일을 전환할 때 실제 작업 시간 외에 추가시간이 발생한다는 것이다. 즉 전환 비용이라 볼 수 있다.
캘리포니아대학 어바인 캠퍼스와 글로리아 마크 Gloria Mark는 사람들이 주의를 전환했다가 본래 하던 일로 되돌아오는 데 23분 15초가 걸린다는 것을 발견했다. 때문에 만약 일정에 미팅 시간이 30분 잡혀있다면 실제로 소요되는 시간은 30분이 아니라, 최소 70분이 소요되는 것으로 봐야 한다. 70분은 기존 업무에서 미팅으로 전환하는 시간 그리고 미팅 종료 후 다시 기존 업무로 전환하는 시간을 더한 시간이다.
이 사실은 ycombinator paulgraham이 작성한 Manager와 Maker의 시간 운영방식에 대한 글에서도 언급이 된다. 때문에 리소스 운영에서 시간의 양보다는 그 시간을 어떻게 배치하느냐가 중요함을 알 수 있다
만약 Maker와 manager의 위치에 따라 어떻게 시간을 운영하는지 더 자세히 알고 싶다면 아래 글들이 도움이 될 것이다.
새로운 사실을 알게 된 후 스프린트 일정 산정 시 미팅 배치를 고려했고 더 효율적으로 리소스를 운영할 수 있게 되었다. 더불어 다른 팀원에게도 리소스 측정에 도움이 되었으면 하여 전사 내에 해당 내용을 공유했다. 공유를 통해 내가 왜 이렇게 리소스를 측정했는지에 대해 타당한 근거를 전달할 수 있었고 당시 내 기억으로 팀원 간의 커뮤니케이션도 더 효율적으로 진행되었던 것 같다. 만약 공유 없이 스프린트를 진행했다면 “왜 저 사람은 미팅을 30분 하는데 70분이나 쓴다고 적은 거지 ?” 라고 의문을 가질 수 있기 때문이다.
그 외 책에서 도움받은 방법 중 특히 좋았던 것을 아래 적어본다.
- 가장 중요한 일과 두번째로 중요한 일 그리고 마지막으로 잡무로 업무를 분류한다. 이때 최우선 일과 두 번째로 중요한 일 모두 한 가지만 적도록 한다.
- 내가 할 수 있는 만큼의 일을 미리 정해두고, 우선순위를 미리 정해둠으로써 업무 범위를 명확히 할 수 있고 우선순위를 지켜 일을 할 수 있게 도와준다. 개인 스프린트 운영이 잘 되고 있는지 확인하기 좋았다.
이메일 처리 시간 정하기
- 말 그대로 일정표에 ‘이메일 시간’을 추가하는 것이다. 따로 정해놓은 시간이 있다는 것을 알면 더 수월하게 이메일에 시간을 낭비하지 않을 수 있다. 회의나 퇴근처럼 확실하게 정해진 일 앞에 이메일 시간을 잡아둘 경우 이메일 처리를 더 끌지 않고 끝내게 되는 또 다른 이점이 있다.
- 할당된 시간 동아 가능한 많은 이메일을 처리한 뒤 다음 일로 넘어가라.
기대치 재설정하기
- 이메일 처리 시간을 제한하거나 반응 시간을 늦출 때는 동료와 그외 사람들의 기대치도 관리해야 한다
- “일부 중요한 프로젝트를 우선으로 처리해야 해서 대답이 늦습니다. 급한 용건이 있으시면 문자 메시지를 보내세요.”
종이 사용하기
- 종이를 사용하면 하던 일을 멈추고 다른 일을 하기 위해 탭을 이리저리 찾는 시간을 줄일 수 있다.
- 나는 버너 리스트를 종이에 작성해서 프로그램을 열지 않아도 언제든 볼 수 있게 했다. 그리고 업무를 진행할 때마다 내가 우선순위에 맞게 업무를 잘 진행하고 있는지 확인했다.
책 외에도 스쿼드 팀원들에게 많은 도움을 받았다. 스프린트 회고 때마다 각자 어떤 방식으로 리소스를 잘 측정하고 있고 어떻게 하면 더 잘할 수 있을지 공유를 했다. 도움받은 방법들 중 특히 캘린더에 미리 진행할 업무를 생성해놓기와 Slack의 상태 메시지를 변경하기가 유용했다. 두 방법 모두 동료에게 내가 무슨 일을 하고 있는지 알림과 동시에 현재 즉각적인 대응이 가능한지를 알릴 수 있으므로 원하는 시간에 집중하는 것이 가능했다.
이후 다른 팀원들에게 공유를 부탁받아 업무일지 템플릿을 두어 번 공유드리기도 했다. 이처럼 사소한 공유로 서로 도움을 주고받는 경험을 통해 팀원 간 공유가 얼마나 중요한지 다시금 깨달았다.
“합시다, 스크럼”
여러 방법과 시행착오 끝에 어느 정도 리소스를 효율적으로 운용할 수 있게 되었고 스프린트 진행 시 예상과 빗나가는 경우가 거의 없게 되었다. 때문에 업무일지 작성은 내게 더 이상 필요한 작업이 아니었다.
그리고 업무일지 작성 후 시간이 날 때 Slack의 Daily Scrum 채널에 들어가 다른 팀원의 작성 글을 보곤 했는데, 나는 해당 채널에 작성을 하지 않으므로 가끔 채널을 봐야 하는 것을 까먹곤 해서 이에 대해 고민이 있었다. 이와 같은 이유로 더 이상 업무일지를 쓰지 않기로 결정 후 채널에 나도 작성이 가능한지 물어보았다.
당연한 이야기지만, 딱히 안될 이유가 없기 때문에 다음날 바로 작성을 시작했다. 작성하고 싶어도 아직은 때가 아니라 생각해 매번 지켜보던 상황에서 벗어났고 이렇게 업무일지 개선 여정을 마무리하게 되었다.
정답은 없다 개선만 있을 뿐
여러 방법을 사용하며 느낀 건 결국 개선을 통해 자신에게 제일 맞는 방법을 만드는 것이었다.
모두 다른 맥락과 환경에 맞게 만들어졌기 때문에 자신에게 딱 맞는 방법이 있기란 쉽지 않다. 좋다고 생각된 방법들을 하나씩 차근차근 실행한 뒤 어떤 부분이 나에게 맞고 더 개선이 필요한지 판단하고, 판단한 내용에 맞춰 다시 실행하는 과정이 필요하다. 이것은 IT 업계에서 흔히 사용하는 제품 실험과 같은 방법이다. 가설을 세우고 그 가설을 테스트하기 위해 실험한 뒤 결과를 측정하고 가설이 옳았는지 판단하는 과정을 거치다 보면 자신에게 최적화된 방법을 찾을 수 있을 것이다.
