리드 타임

개발팀과 요청하는 쪽이 같은 일을 두고 다른 시간을 말하던 시절이 있었습니다. 개발팀은 "이틀이면 됩니다" 하고 답했고, 요청한 사람은 3주 뒤에야 결과를 받았습니다. 둘 다 거짓말을 하지 않았습니다. 이틀은 손을 대고 있던 시간이었고 3주는 요청서가 목록 어딘가에 놓여 있던 시간까지 합한 값이었습니다.

그래서 약속은 번번이 깨졌습니다. 영업이 고객에게 "2주면 나옵니다" 하고 전하면 개발팀이 말한 이틀에 여유를 얹은 셈인데, 정작 그 요청은 앞에 밀린 열두 건 뒤에 서 있었습니다. 한 달이 지나 고객이 전화를 걸면 개발팀은 "그건 아직 시작 안 했습니다" 하고 답했고, 영업은 자기가 무엇을 잘못 들었는지 알지 못했습니다.

리드 타임은 그 빈칸을 메우려고 세는 시간입니다. 누가 얼마나 빨리 코드를 쓰는지가 아니라, 요청한 사람이 기다린 시간 전체를 잽니다. 재는 구간을 바꿨을 뿐인데 팀이 보는 그림이 달라집니다. 줄에 서 있던 시간이 숫자 안으로 들어오는 순간, 그 줄이 얼마나 긴지가 처음으로 보이기 때문입니다.

요청이 접수된 시각과 그 일이 완료된 시각의 차이를 건마다 재고, 여러 건을 모아 분포로 봅니다.

접수와 완료를 언제로 잡을지부터 팀이 합의해야 합니다. 칸반 보드를 쓰는 팀이라면 카드가 처음 판에 올라온 시각이 접수이고, 마지막 칸으로 넘어간 시각이 완료입니다. 이 기준이 사람마다 다르면 같은 건의 리드 타임이 두 배씩 벌어집니다. 요청을 메신저로 받은 날부터 셀지 그것을 카드로 옮겨 적은 날부터 셀지가 대표적인 갈림길입니다.

계산은 세 단계입니다.

1. 최근에 끝난 건들의 접수 시각과 완료 시각을 모읍니다. 서른 건 정도면 분포를 보기에 충분합니다.
2. 건마다 두 시각의 차를 구합니다. 달력일로 셀지 영업일로 셀지를 정해 두고 끝까지 같은 방식으로 셉니다. 고객에게 날짜를 약속하는 용도라면 주말이 포함된 달력일이 맞습니다.
3. 모은 값을 작은 것부터 늘어놓고 중앙값과 85퍼센타일을 읽습니다. 85퍼센타일은 100건 중 85건이 그 안에 끝났다는 뜻의 값입니다.

평균을 쓰지 않는 이유는 한 건이 전체를 흔들기 때문입니다. 스무 건이 대부분 일주일 안에 끝났는데 한 건이 담당자 휴가로 두 달을 끌었다면 평균은 12일로 뜁니다. 같은 스무 건의 중앙값은 6일이고, 85퍼센타일은 14일입니다. 고객에게는 "보통 엿새, 늦어도 2주" 라고 전할 수 있습니다.

작업 종류를 섞어 세면 값이 뜻을 잃습니다. 버그 수정과 새 기능은 처음부터 걸리는 시간이 다르니, 종류별로 나눠 각각의 분포를 봅니다.

며칠이어야 좋다는 기준은 없습니다. 오탈자 수정과 결제 연동은 같은 잣대로 잴 수 없고, 팀마다 요청이 들어오는 경로도 다릅니다. 대신 두 가지를 봅니다.

첫째는 흩어진 정도입니다. 85퍼센타일이 중앙값의 몇 배인지를 보고, 두 배 안쪽이면 약속에 쓸 수 있습니다. 중앙값 6일에 85퍼센타일 10일인 팀은 "열흘 안에 드립니다" 라고 말해도 대체로 지킵니다. 중앙값은 같은 6일인데 85퍼센타일이 25일이면 어떤 숫자를 불러도 절반은 틀립니다. 체온계로 치면 눈금이 정확한지가 아니라 잴 때마다 다른 값이 나오는지의 문제입니다.

둘째는 그 시간 중 얼마가 기다린 시간인지입니다. 사이클 타임, 즉 실제로 손을 대기 시작한 뒤 끝날 때까지 걸린 시간을 같이 재서 견줍니다. 리드 타임 9일에 사이클 타임 2일이면 이레는 아무도 손대지 않은 채 줄에 서 있던 시간입니다. 이런 팀이 사람을 더 뽑으면 사이클 타임만 조금 줄고 리드 타임은 거의 그대로입니다. 고칠 곳은 일하는 속도가 아니라 줄을 세우는 방식이기 때문입니다.

줄을 줄이는 가장 흔한 방법은 WIP 제한입니다. 한 칸에 동시에 올려 둘 수 있는 카드 수에 상한을 걸어 두면 새 요청을 무작정 받아 두지 못하게 되고, 이미 시작한 것이 먼저 빠져나갑니다. 어느 칸에서 줄이 길어지는지는 누적 흐름도에서 그 칸의 띠가 두꺼워지는 모양으로 확인합니다. 그 칸이 병목입니다.

"이 건 리드 타임 얼마나 볼까요? 고객한테 날짜를 드려야 해서요."

요청부터 전달까지 며칠 걸릴지를 묻는 것이지 개발에 며칠 걸리는지를 묻는 게 아닙니다.

"중앙값은 엿새인데 85퍼센타일이 3주예요. 그냥 3주로 말씀드리죠."

절반은 엿새에 끝나지만 편차가 커서 안전한 쪽 숫자를 부르자는 제안입니다.

"리드 타임은 늘었는데 사이클 타임은 그대로예요."

일하는 속도는 그대로고 앞에 밀린 줄만 길어졌다는 뜻입니다.

페이지덱에서는 수아가 고객에게 날짜를 전할 때 이 숫자를 먼저 확인합니다. 예전에는 태오에게 "이거 며칠 걸려요" 하고 물어 받은 답을 그대로 전했는데, 그 답은 손대는 시간만 센 값이라 절반쯤 빗나갔습니다. 지금은 지현이 분기마다 정리해 둔 종류별 분포를 보고 전합니다. 버그 수정은 중앙값 2일에 85퍼센타일 5일, 작은 기능 요청은 중앙값 8일에 85퍼센타일 3주입니다.

숫자가 약속을 대신하지는 않습니다. 수아가 "보통 일주일, 늦어도 3주" 라고 전한 뒤에 그 건을 앞으로 당길지는 지현이 다른 요청들과 견줘 정합니다.

리드 타임을 개발에 걸린 시간으로 읽는 경우가 가장 많습니다. 개발팀이 관리하는 숫자이니 개발 이야기일 거라고 짐작하기 쉽습니다. 하지만 이 값에는 요청서가 검토를 기다린 날, 우선순위 회의를 기다린 날, 다른 일이 끝나기를 기다린 날이 전부 들어 있습니다. 개발 기간으로 읽으면 9일이라는 값을 보고 "이틀이면 될 일을 왜 아흐레나" 하는 결론이 나오고, 그러면 팀은 실제로 손댄 시간만 세는 쪽으로 기준을 바꾸게 됩니다. 그 순간 숫자는 고객이 기다린 시간과 다시 멀어집니다.

줄이려면 더 빨리 일해야 한다고 보는 것도 흔합니다. 시간을 재는 숫자이니 속도 문제로 보이기 때문입니다. 그런데 대기가 전체의 7할인 팀에서 손대는 시간을 절반으로 줄여도 9일은 8일이 될 뿐입니다. 같은 팀이 동시에 붙드는 일의 개수를 절반으로 줄이면 줄이 짧아지면서 9일이 5일이 됩니다. 야근으로는 잘 줄지 않고 받아 두는 일의 개수를 줄이면 줄어드는 종류의 숫자입니다.