딜리버리 매니저

팀이 하나일 때는 이런 자리가 필요 없습니다. 누가 어디서 막혔는지가 같은 방 안에서 보이니 일정은 회의 한 번이면 맞춰집니다.

팀이 넷, 다섯으로 늘면서 문제가 생깁니다. 각 팀은 자기 보드 안에서는 멀쩡하게 돌아갑니다. 할 일을 뽑고, 끝난 것을 옮기고, 주기가 끝나면 돌아봅니다. 그런데 일은 팀 안에서 멈추지 않고 팀과 팀 사이에서 멈춥니다. 프론트엔드 팀은 API가 나오기를 기다리고, API 팀은 보안 검토 결과를 기다리고, 보안 검토는 외부 업체 일정에 묶여 있습니다. 이 기다림은 어느 팀의 보드에도 올라오지 않습니다. 각 팀 입장에서는 자기가 할 일이 아니기 때문입니다.

그 결과가 출시 사흘 전 회의에서 드러납니다. 한쪽에서 "저희는 지난주에 다 끝내서 넘겼는데요" 라고 하고, 다른 쪽에서 "저희는 그 결과를 오늘 받는다고 들었는데요" 라고 합니다. 둘 다 성실하게 일했고, 두 일정을 함께 본 사람이 없었을 뿐입니다. 딜리버리 매니저는 그 빈자리를 메우려고 생긴 역할입니다. 팀 하나를 더 빠르게 만드는 대신, 팀 사이에 생기는 대기와 어긋남을 찾아 없애는 데 시간을 씁니다.

하루의 절반은 여러 팀의 상태를 모아 하나의 그림으로 맞추는 데 쓰고, 나머지 절반은 그 그림에서 어긋난 곳을 풀어내는 데 씁니다.

1. 아침에 팀별 보드를 훑되 어제와 달라진 칸만 봅니다. 사흘째 같은 자리에 있는 작업은 그 자리에서 표시해 둡니다.
2. 블로커를 걷어 냅니다. 다른 조건 때문에 진행할 수 없게 막힌 작업을 뜻합니다. 대부분은 결정이 안 났거나, 접근 권한이 없거나, 다른 팀이 아직 안 준 것입니다. 직접 해결하기보다 해결할 수 있는 사람에게 연결하고 답 받을 기한을 못 박습니다.
3. 일정표를 갱신합니다. 오늘 바뀐 내용을 반영하고, 마일스톤까지 남은 작업량과 남은 날짜를 견줍니다. 마일스톤은 진척을 확인하려고 중간에 찍어 둔 기준점입니다.
4. 어긋남을 일찍 알립니다. 2주 뒤 일정이 지금 속도로는 나흘 늦는다는 계산이 나오면 그날 알립니다. 늦는 것보다 늦게 알려지는 것이 비싸기 때문입니다.
5. 이해관계자에게 상황을 정리해 보냅니다. 결과에 영향을 받거나 영향을 줄 수 있는 사람들로 경영진·세일즈·고객 지원이 여기 들어갑니다. 무엇이 예정대로이고 무엇이 위험한지를 나눠 적습니다.

출시가 가까워지면 비중이 달라집니다. 배포 당일에는 어느 팀이 먼저 올리고 문제가 생기면 어디까지 되돌릴지를 미리 적어 두고 그 순서대로 진행하는 일이 하루를 다 차지합니다.

혼자 결정하는 일은 거의 없고 남의 결정을 제때 끌어내는 일이 대부분이라, 상대가 누구냐에 따라 묻는 것이 달라집니다.

프로덕트 매니저와는 범위를 놓고 이야기합니다. 일정이 빠듯해지면 선택지는 날짜를 미루거나 범위를 줄이거나 둘뿐이고, 무엇을 뺄지는 프로덕트 매니저가 정합니다. 딜리버리 매니저는 무엇을 빼면 며칠이 돌아오는지를 숫자로 내놓습니다. 이 대화가 늦으면 스코프 크리프가 생깁니다. 합의 없이 범위가 늘어나 어느새 애초 계획의 두 배가 되는 현상입니다.

개발 팀 리드와는 남은 작업량을 놓고 이야기합니다. 다음 주기에 이 팀이 소화할 수 있는 양, 즉 캐파시티 플래닝의 결과를 받아 일정에 반영합니다. 다섯 명에 2주면 50인일처럼 보여도 휴가와 면접과 다른 팀 지원을 빼면 41인일이라, 이 숫자 없이 짠 일정은 처음부터 어긋나 있습니다.

품질 검증 담당자와는 검수 시간을 놓고 이야기합니다. 개발이 늦어졌다고 검수를 이틀에서 반나절로 줄이면 출시는 날짜를 지키지만 그다음 주에 장애로 돌아옵니다.

외부 협력사와 일정을 맞추는 몫도 이 자리에 옵니다. 고객사 보안 심사, 외부 감사, 앱 스토어 심사처럼 속도를 조절할 수 없는 일정이 여기 해당하고, 우리 쪽 작업보다 먼저 걸어 두어야 합니다.

"3주차에 두 팀이 같은 날 배포를 잡았어요. 한쪽을 한 주 뒤로 옮길 수 있을까요?"

같은 시점에 몰린 작업을 흩어 위험을 나누자는 제안입니다.

"날짜는 지킬 수 있습니다. 대신 다국어는 이번 릴리스에서 빼고 다음으로 넘깁니다."

일정을 지키기 위해 무엇을 포기할지를 미리 꺼내 놓는 말입니다.

"지금 막혀 있는 건 결제팀 회신 하나예요. 오늘 오후까지 안 오면 위로 올리겠습니다."

한 건의 대기가 전체 일정을 잡고 있으니 절차대로 상위 담당자에게 넘기겠다는 뜻입니다.

페이지덱에는 아직 딜리버리 매니저 자리가 따로 없고, 팀이 둘이던 시절에는 지현이 제품 결정과 일정 조율을 겸해도 충분했습니다. 문제는 기업 고객용 권한 관리 기능을 내보내던 분기에 드러났습니다. 백엔드, 프론트엔드, 품질 검증, 보안 문서가 각각 다른 순서로 걸려 있는 데다 고객사 계약일이 못 박혀 날짜를 미룰 수도 없었는데, 지현이 제품 결정에 매여 일정표를 사흘에 한 번 여는 사이 보안 검토가 외부 업체 사정으로 한 주 밀린 사실을 아무도 알리지 않았습니다.

규원이 그 뒤에 정한 것은 사람을 뽑는 일이 아니라 순서였습니다. 주 2회 네 팀의 상태를 한 표에 모으고, 붉게 표시된 항목은 그날 안에 담당자를 정하게 했습니다. 이 일을 전담으로 맡길 만큼 출시가 잦아지면 그때 자리가 생깁니다.

일정을 채근하는 사람으로 읽는 경우가 가장 많습니다. 매일 진척을 묻고 늦어진 항목을 짚으니 그렇게 보이기 쉽습니다. 다만 채근으로 당겨지는 일정은 없습니다. 이미 할 수 있는 만큼 하고 있는 팀에게 더 빨리 하라고 말하면 돌아오는 것은 속도가 아니라 낙관적인 보고입니다. 실제로 하는 일은 반대에 가깝습니다. 막힌 이유를 찾아 치우고, 두 팀이 서로 기다리는 지점을 없애고, 지킬 수 없는 날짜를 일찍 인정하게 만듭니다. 채근하는 자리로 운영하면 보고가 실제보다 좋아지고, 진짜 상황은 출시 직전에야 드러납니다.

일정이 밀리면 이 사람의 실패라고 보는 것도 흔합니다. 밀림 자체는 개발 난이도, 외부 일정, 갑자기 들어온 장애처럼 이 자리가 통제하지 못하는 이유로 생깁니다. 이 역할의 성과는 밀리지 않는 것이 아니라 밀릴 것을 얼마나 일찍 드러냈는가입니다. 2주 전에 알려진 나흘 지연은 범위를 줄이거나 인력을 옮겨 대응할 수 있지만, 전날 알려진 하루 지연은 그대로 사고가 됩니다.