흐름 효율

일이 늦어지면 가장 먼저 나오는 질문은 누가 덜 일했느냐였고, 그래서 회사는 사람이 쉬지 않고 일했는지를 쟀습니다. 개발자 한 명이 하루 여덟 시간을 꽉 채워 작업에 썼으면 좋은 상태로 봤고, 빈 시간이 보이면 일을 더 얹었습니다.

그런데 모두가 바쁜 팀에서도 기능 하나가 나오는 데 두 달이 걸렸습니다. "다들 밤늦게까지 일하는데 왜 아무것도 안 나오죠" 라는 말이 분기마다 반복됐습니다. 사람은 쉬지 않았는데 일이 멈춰 있었기 때문입니다. 기획안은 디자인 착수를 기다리고, 시안은 개발 착수를 기다리고, 다 만든 코드는 코드 리뷰를 기다렸습니다. 기다리는 동안 각자는 다른 건을 붙들고 있었으니 개인 기록에는 빈 시간이 남지 않았습니다.

흐름 효율은 보는 대상을 사람에서 일감으로 옮겨 이 공백을 드러냅니다. "이번 주에 몇 시간 일했나" 대신 "이 기능이 12일 동안 며칠이나 실제로 다뤄졌나" 를 묻습니다. 질문을 바꾸면 아무도 자기 담당이라고 생각하지 않던 대기 구간이 숫자로 나타납니다.

작업에 실제로 손댄 시간을 전체 경과 시간으로 나누고 100을 곱합니다. 12일 만에 나간 기능에서 사람이 붙어 있던 날을 세어 3일이었다면 흐름 효율은 25퍼센트입니다.

전체 경과 시간은 달력으로 잽니다. 일이 줄에 들어온 순간부터 고객이 쓸 수 있게 된 순간까지이고 주말과 공휴일도 그대로 세는 이 값을 리드 타임이라고 부릅니다. 여기서 착수 이전의 대기를 빼고 실제로 일을 시작한 시점부터 잰 값은 사이클 타임입니다. 어느 쪽을 분모로 쓸지 먼저 정해 두지 않으면 같은 일에서 두 배 넘게 차이 나는 값이 나옵니다.

재는 순서는 셋입니다.

1. 일감 하나를 골라 시작과 끝 시각을 적습니다. 티켓이 생성된 시각과 닫힌 시각이면 충분합니다.
2. 그 사이를 구간으로 쪼개고 구간마다 작업이었는지 대기였는지 표시합니다. 누군가 그 일을 붙들고 있었으면 작업, 다음 사람의 차례를 기다리고 있었으면 대기입니다.
3. 작업으로 표시된 시간을 더해 전체로 나눕니다.

2번에서 자주 막힙니다. 시각을 분 단위로 적어 둔 팀은 드물어서, 처음에는 티켓 도구의 상태 변경 기록만으로 시작합니다. 작업 중 칸에 머문 시간을 작업으로, 검토 대기 칸과 배포 대기 칸에 머문 시간을 대기로 잡으면 대략의 값이 나옵니다. 소수점까지 맞히는 것보다 대기가 절반을 넘는지 아닌지를 아는 쪽이 먼저입니다.

한 건만 재면 그 건의 사정에 휘둘리니, 최근에 끝난 열 건에서 각각 구해 가운데 값을 씁니다.

처음 재 보는 팀은 대개 5에서 15퍼센트 사이가 나옵니다. 3주가 걸린 일에서 실제로 손댄 시간이 이틀이었다는 뜻이고, 이 숫자를 처음 본 팀은 계산이 틀렸다고 생각합니다. 틀린 계산도, 유난히 못하는 팀의 값도 아니라 대부분의 팀이 처음 재면 나오는 값입니다.

꾸준히 손본 팀이 닿는 자리는 40퍼센트 안팎입니다. 100퍼센트는 목표가 아닙니다. 일감이 한 번도 기다리지 않으려면 모든 검토자가 요청이 올 때마다 비어 있어야 하니, 일감의 대기를 사람의 대기로 바꿔 치우는 셈입니다.

값이 낮게 나오는 원인은 거의 대기 구간에 몰려 있습니다. 검토자가 한 명뿐이라 그 사람이 회의에 들어가면 줄이 멈추거나, 한 사람이 다섯 건을 동시에 붙들어 무엇도 끝나지 않거나, 승인 절차가 이틀에 한 번만 열립니다. 그래서 이 숫자를 올리는 손잡이는 동시에 진행할 작업 수에 상한을 두는 WIP 제한입니다. 다섯 건을 한꺼번에 시작하는 대신 두 건까지만 열어 두면 시작된 일이 빨리 끝나고 뒤에 선 줄이 짧아집니다.

값 자체보다 방향이 답합니다. 15퍼센트가 20퍼센트가 됐다면 어딘가의 기다림이 줄었다는 뜻이고, 같은 자리에 머물러 있다면 지난 분기의 개선이 흐름에는 닿지 않은 것입니다. 팀끼리 견주는 데에는 쓰지 않습니다. 구간을 어디서 끊고 무엇을 대기로 칠지가 팀마다 다릅니다.

"이번 분기 흐름 효율이 12퍼센트예요. 일하는 시간이 모자란 게 아니라 기다리는 시간이 긴 겁니다."

사람을 더 뽑아 달라는 요청이 아니라 대기 구간을 손보자는 제안입니다.

"이 카드는 리드 타임이 18일인데 실제 작업은 이틀이네요. 나머지 16일이 어디로 갔는지 봅시다."

한 건을 표본으로 놓고 멈춘 자리를 찾자는 말입니다.

"흐름 효율 올리겠다고 모두를 더 바쁘게 만들면 반대로 내려갑니다."

각자 붙든 일이 늘면 일감 하나가 기다리는 시간도 함께 늘어난다는 경고입니다.

페이지덱에서는 지현이 분기 회고 때 이 숫자를 꺼냅니다. 지난 분기에 나간 기능 열 개를 뽑아 보니 가운데 값이 14퍼센트였습니다. 태오가 구간을 쪼개 보니 멈춘 시간의 절반 이상이 코드 리뷰 대기였습니다. 리뷰할 수 있는 사람이 둘뿐이었고 한 명은 늘 회의에 있었습니다.

그래서 다음 분기에는 리뷰 가능한 사람을 넷으로 늘리고, 리뷰 요청이 하루를 넘기면 블로커로 올리기로 했습니다. 블로커는 다른 조건 때문에 막혀 진행할 수 없는 작업이고, 매일 아침 이 목록부터 봅니다. 한 분기 뒤 값은 22퍼센트가 됐습니다. 사람 수도 일하는 시간도 그대로였습니다.

흐름 효율이 낮으면 팀이 놀고 있다고 읽는 경우가 가장 많습니다. 효율이라는 말이 붙어 있으니 사람의 근면함을 재는 숫자처럼 보이는 탓입니다. 하지만 이 값의 주어는 사람이 아니라 일감 한 건입니다. 12퍼센트는 그 일감이 88퍼센트의 시간을 줄에서 기다렸다는 뜻이고, 기다리는 동안 담당자는 다른 일감을 붙들고 있었습니다. 오해한 채로 대책을 세우면 이미 꽉 찬 사람에게 일을 더 얹게 되고, 줄이 더 길어져 다음 분기 값은 8퍼센트로 내려갑니다.

가치 흐름을 그려 놓고 숫자를 한 번만 재는 것도 흔합니다. 가치 흐름은 요청 하나가 고객 가치로 바뀌기까지 지나는 전체 경로를 구간으로 늘어놓은 그림인데, 그 위에 흐름 효율을 적어 넣고 멈추면 남는 것은 그럴듯한 그림과 숫자 하나뿐입니다. 이 값은 같은 방식으로 반복해 재면서 병목을 하나씩 걷어 낼 때만 움직입니다. 병목은 전체 흐름의 속도를 결정하는 가장 느린 구간이고, 한 곳을 뚫으면 다음 구간이 새 병목이 됩니다.