가치 흐름

각자 자기 구간을 빠르게 하고 있는데도 전체가 느린 상태가 있습니다. 기획은 이틀 만에 끝내고, 디자인도 이틀, 개발도 사흘이면 됩니다. 그런데 요청이 들어온 날부터 고객이 쓰는 날까지는 12일이 걸립니다.

페이지덱에서 지현이 이 질문을 꺼냈습니다. 문구 수정 요청 하나가 왜 2주나 걸리느냐고 물었더니 답이 이렇게 돌아왔습니다. 민서는 디자인은 이틀이었다고 하고, 태오는 개발은 사흘이었다고 하고, 둘 다 사실이었습니다. 아무도 자기 구간이 느리다고 말하지 않았는데 전체는 느렸습니다.

빠진 것은 구간 사이였습니다. 기획이 끝난 문서가 디자인 차례를 기다린 나흘, 디자인이 끝난 시안이 검토를 기다린 이틀, 코드 리뷰를 기다린 사흘은 아무의 작업 시간에도 잡히지 않았습니다. 각자 자기 담당 구간만 보고 있으면 이 시간은 누구의 화면에도 나타나지 않습니다. 가치 흐름은 보는 단위를 사람에서 일 한 건으로 바꿔서 그 시간을 드러내려고 그립니다.

일 한 건이 지나간 길을 시간과 함께 늘어놓습니다. 다섯 단계로 그립니다.

1. 실제로 끝난 일 하나를 고릅니다. 상상한 절차가 아니라 지난달에 정말로 나간 건이어야 합니다. 대표성 있는 흔한 크기를 고르고 가장 크거나 작은 건은 피합니다.
2. 그 건이 지나간 구간을 순서대로 적습니다. 요청 접수, 기획, 디자인, 디자인 검토, 개발, 코드 리뷰, 배포처럼 나옵니다. 조직도를 옮겨 적는 것이 아닙니다. 한 사람의 일이 아니라 일 한 건의 여정이라, 같은 팀 안에서 두 구간으로 갈라지기도 하고 두 팀이 한 구간에 함께 들어가기도 합니다.
3. 구간마다 두 숫자를 적습니다. 실제로 손댄 시간과 기다린 시간입니다. 이 둘을 나눠 적는 것이 이 그림의 전부입니다. 한 칸에 합쳐 적으면 나흘이 걸린 구간이 나흘 동안 일한 구간처럼 보입니다. 디자인 구간에 나흘을 적는 대신 대기 사흘과 작업 하루로 나눠 적으면, 그 구간에서 고칠 것이 디자인 속도가 아니라 순서를 기다리는 방식이라는 사실이 바로 드러납니다.
4. 합계를 봅니다. 요청이 들어온 뒤 끝날 때까지의 전체 시간이 리드 타임이고, 그중 손댄 시간의 비율이 흐름 효율입니다. 12일 가운데 3일을 손댔으면 25퍼센트입니다. 처음 재 보는 팀은 대개 15퍼센트 아래가 나옵니다.
5. 가장 오래 기다린 구간 하나를 고릅니다. 전체 속도를 결정해 버리는 가장 느린 자리를 병목이라고 부르는데, 개선은 여기서만 효과가 납니다. 앞의 예에서는 디자인 차례를 기다린 나흘이 그 자리입니다.

낮은 숫자가 팀이 놀고 있다는 뜻은 아닙니다. 한 건이 기다리는 동안 그 사람은 다른 건을 붙들고 있습니다. 그래서 이 그림이 가리키는 개선 방향은 사람을 더 바쁘게 하는 쪽이 아니라 기다리는 구간을 줄이는 쪽입니다. 기다림 자체가 낭비로 세어지는 이유도 같습니다. 아무도 일하지 않은 나흘도 고객이 기다린 나흘입니다.

무엇을 개선할지 고를 때 가장 많이 씁니다. 개선 아이디어는 늘 여러 개가 나오는데, 이 그림이 있으면 그중 전체 시간을 줄이는 것 하나를 고를 수 있습니다. 감으로 고르면 대개 눈에 보이는 작업 구간을 손보게 되고, 그 구간은 이미 빠릅니다.

팀 경계에서 벌어지는 논쟁을 끝낼 때도 씁니다. 오래 멈추는 자리는 대개 아무도 자기 담당이라고 생각하지 않던 구간입니다. 디자인이 끝난 시안이 검토를 기다리는 이틀은 디자인의 시간도 개발의 시간도 아니어서, 그림에 적히기 전까지는 회의에서 거론되지 않습니다.

제품을 만드는 일에만 쓰는 개념은 아닙니다. 지원자가 원서를 낸 뒤 입사하기까지, 고객 문의가 해결되기까지, 계약서가 서명되기까지도 같은 방식으로 그립니다. 구간과 대기 시간이 있는 일이면 대상이 됩니다. 채용에서는 면접 결과를 정리해 다음 단계로 넘기기까지의 며칠이 흔한 병목이고, 그 며칠 동안 지원자는 다른 회사의 제안을 받습니다.

주의할 점이 둘 있습니다. 하나는 한 건만 그리면 대표성이 없다는 것입니다. 다섯에서 열 건을 그려 보면 매번 같은 구간에서 멈추는지, 아니면 건마다 다른지가 드러납니다. 다른 하나는 그리는 일 자체가 목적이 되는 경우입니다. 벽에 붙일 그림을 사흘 걸려 만들고 개선은 하나도 하지 않으면, 그 사흘이 새 낭비입니다.

"각 구간은 다 빠른데 리드 타임이 12일입니다. 사이를 봐야 해요."

작업 시간이 아니라 대기 시간에 답이 있다는 지적입니다.

"이번엔 디자인 검토 대기 나흘만 손보겠습니다. 나머지는 그대로 둡니다."

병목 하나에 집중해 전체 시간을 줄이겠다는 계획입니다.

"이 구간은 누가 담당인지 정해진 적이 없네요."

그림을 그리다 담당 없는 구간이 드러났다는 말입니다.

지현이 문구 수정 건 여덟 개를 골라 구간별 시간을 적어 봤습니다. 손댄 시간은 평균 사흘이고 전체는 평균 11일이었습니다. 가장 긴 대기는 디자인 검토를 기다리는 구간에서 나왔고, 원인은 민서가 검토를 주에 한 번 몰아서 하던 방식이었습니다.

검토를 주 이틀로 나눈 뒤 같은 종류의 일이 평균 7일로 줄었습니다. 작업 시간은 하루도 줄지 않았습니다. 태오는 이 결과를 보고 코드 리뷰도 같은 방식으로 나눴습니다.

가치 흐름을 프로세스 순서도와 같게 아는 경우가 가장 많습니다. 구간을 화살표로 이어 그린 모양이 똑같아 보이기 때문입니다. 차이는 시간을 적는지에 있습니다. 순서만 적은 그림은 이미 모두가 아는 것을 다시 확인해 주고 끝나지만, 구간마다 손댄 시간과 기다린 시간을 적으면 아무도 몰랐던 대기가 드러납니다. 이 오해를 그대로 두면 팀은 그림을 그려 놓고 고칠 곳을 못 찾습니다. 화살표만 있는 그림에서 나오는 결론은 대개 구간을 하나 없애자는 쪽이고, 실제로 시간을 먹던 대기는 그 구간이 사라진 뒤에도 그대로 남습니다.

한 구간을 빠르게 하면 전체가 빨라진다고 읽는 오해도 흔합니다. 각 구간이 더해져 전체가 된다고 보면 그렇게 됩니다. 실제로는 병목 밖을 개선해도 전체 시간은 거의 그대로입니다. 개발을 사흘에서 이틀로 줄여도 코드 리뷰 대기가 사흘 그대로면 전체는 12일에서 11일이 됩니다. 그 하루를 줄이려고 개발팀을 몰아붙이는 동안 나흘짜리 대기는 손대지 않은 채 남습니다.