작업 항목

일이 어디에 적혀 있느냐는 오래된 문제였습니다. 회의에서 정한 것은 회의록에 있고, 급한 부탁은 메신저에 있고, 고객 요청은 메일함에 있고, 나머지는 각자의 머릿속에 있었습니다. 적힌 곳이 네 군데면 아무 데도 적히지 않은 것과 비슷하게 작동합니다. 어느 하나에도 전체 목록이 없기 때문입니다.

그래서 주간 회의는 늘 같은 질문으로 시작했습니다. "그거 누가 하기로 했죠?" 아무도 확신하지 못하면 대화는 두 갈래로 갔습니다. 서로 상대가 맡은 줄 알았다고 하거나, 두 사람이 같은 일을 각자 해 놓았다는 사실을 그 자리에서 알게 되거나. 둘 다 시간을 잃는 방식은 같습니다.

페이지덱 초기에도 같은 일이 있었습니다. 고객사 한 곳이 파일 업로드가 안 된다고 알려 온 것을 수아가 개발팀 메신저 방에 옮겨 적었고, 태오와 다른 개발자가 각자 그 메시지를 보고 원인을 찾기 시작했습니다. 이틀 뒤 회의에서야 둘이 같은 기록을 들여다보고 있었다는 사실이 드러났습니다. 그사이 지현이 말로 부탁해 둔 결제 화면 수정은 아무도 손대지 않은 채 사흘이 지나 있었습니다. 누가 게을러서 벌어진 일이 아니라, 지금 남아 있는 일이 무엇인지를 한 화면에서 보는 사람이 없어서 벌어진 일입니다.

빠진 것은 성실함이 아니라 단위였습니다. 일이 눈에 보이려면 셀 수 있어야 하고, 세려면 하나를 하나라고 부를 기준이 있어야 합니다. 작업 항목은 그 기준을 만든 것입니다. 해야 할 일을 한 건씩 끊어 등록하고, 각 건에 누가 맡았는지와 지금 어느 단계인지를 붙여 둡니다. 그러면 "그거 누가 하기로 했죠" 라는 질문 자체가 사라집니다. 답이 화면에 있으니까요.

여기서 달라지는 것이 하나 더 있습니다. 일의 상태가 사람의 기억이 아니라 기록에 남으므로, 그 기록을 세면 팀이 어떻게 돌아가는지가 숫자로 보입니다. 이번 주에 등록된 건과 끝난 건, 2주 넘게 같은 칸에 멈춰 있는 건, 계획에 없다가 끼어든 건. 일하는 방식의 나머지 갈래가 계획과 추정과 회의를 다룬다면, 작업 관리는 그 모든 것이 올라탈 바닥을 까는 갈래입니다. 바닥이 고르지 않으면 위에 올린 숫자도 흔들립니다. 한 건의 크기가 반나절짜리와 두 달짜리를 오가면 남은 건수를 세도 진척을 알 수 없습니다.

작업 항목 아래 묶인 용어는 두 갈래입니다. 무엇을 한 건으로 볼 것인가(단위)와, 그 한 건에 무엇을 적어 둘 것인가(속성)입니다. 앞쪽은 일을 어디서 끊을지를 정하고, 뒤쪽은 끊어 놓은 것을 나중에 찾고 세고 판단할 수 있게 만듭니다.

단위는 한 건의 경계를 정하는 갈래입니다. 세 이름이 있는데 셋 다 비슷한 것을 가리켜 처음에는 헷갈립니다. 차이는 어디서 온 말이냐에 있습니다.

1. 티켓 — 처리할 일을 하나로 끊어 등록한 항목입니다. 접수 창구에서 번호표를 뽑는 그림에서 온 말이라 고객 문의나 장애 접수처럼 밖에서 들어오는 일에 자주 붙습니다.
2. 이슈 — 작업과 버그와 요청을 한데 묶어 부르는 이름입니다. 도구가 쓰는 공식 명칭인 경우가 많아, 팀 안에서 "이슈 하나 만들어 두세요" 라고 하면 종류를 가리지 않고 한 건을 등록하라는 뜻입니다.
3. 서브태스크 — 한 건을 더 잘게 나눈 하위 항목입니다. 한 건이 여러 사람에게 걸쳐 있거나 며칠 이상 걸릴 때 씁니다. 화면 하나 만들기를 디자인 확정, 화면 개발, 서버 연동으로 나누는 식입니다.

한 건에 실제로 적히는 것은 도구마다 이름이 달라도 대체로 같은 다섯 가지입니다.

1. 제목 — 목록에서 한 줄로 보이는 부분입니다. "로그인 오류" 보다 "비밀번호 재설정 메일이 도착하지 않음" 처럼 무엇이 어떻게 안 되는지까지 적어야 목록을 훑는 사람이 열어 보지 않고도 구분합니다.
2. 설명 — 왜 필요한지와 어떤 상황에서 생기는지를 적습니다. 버그라면 재현 순서와 기대한 동작과 실제 동작을 함께 적습니다.
3. 완료 조건 — 무엇이 되면 이 건을 닫아도 되는지입니다. 이 줄이 없으면 만든 사람과 맡은 사람이 서로 다른 끝을 생각한 채 진행합니다.
4. 크기 추정 — 이 일이 얼마나 큰지입니다. 계획을 세울 때 이 값을 더해 다음 주기에 담을 양을 가늠합니다.
5. 연결 — 상위 항목이나 관련 항목과의 관계입니다. 에픽처럼 큰 덩어리 아래에 매달아 두면 그 덩어리가 지금 몇 퍼센트 진행됐는지가 자동으로 나옵니다.

다섯 가지 중 실제로 가장 자주 빠지는 것은 3번입니다. 제목과 설명은 등록하면서 자연히 적히지만, 완료 조건은 적는 사람이 상대도 당연히 알 것이라 여겨 건너뛰기 쉽습니다. 그러면 맡은 사람은 검색 결과 정렬을 고치고 닫았는데 만든 사람은 검색어가 비었을 때의 처리까지 기대하고 있었다는 식으로 갈라집니다. 이 차이는 대개 리뷰나 배포 직전에 드러나 일정을 하루 이틀 밀어냅니다.

속성은 등록된 한 건에 붙는 값입니다. 네 가지가 있고, 각각 답하는 질문이 다릅니다.

1. 워크플로 상태 — 지금 어느 단계에 있는지입니다. 할 일, 진행 중, 리뷰 중, 완료처럼 팀이 미리 정해 둔 칸 중 하나를 가리킵니다. 칸을 늘릴수록 어디서 막히는지가 잘 보이지만, 옮기는 사람이 매번 손이 가서 실제 상태와 어긋나기 쉬워집니다.
2. 담당자 — 누가 맡았는지입니다. 한 건에 한 사람만 두는 것이 원칙입니다. 셋을 적어 두면 셋 다 누군가 하겠거니 하고 아무도 시작하지 않습니다.
3. 기한 — 언제까지 끝내기로 했는지입니다. 모든 건에 날짜를 박으면 곧 아무 의미가 없어집니다. 외부 약속이 걸린 건에만 붙이고 나머지는 순서로 관리하는 편이 오래갑니다.
4. 라벨 — 분류를 위해 붙이는 꼬리표입니다. 결제, 모바일, 기술 부채처럼 나중에 한 번에 모아 보고 싶은 기준으로 붙입니다. 종류가 서른 개를 넘어가면 아무도 일관되게 붙이지 않아 모아 보는 기능 자체가 무너집니다.

네 값을 꼬박꼬박 채우는 이유는 기록을 단정하게 만들려는 것이 아니라 나중에 물어볼 수 있게 하려는 것입니다. 담당자가 채워져 있어야 한 사람에게 몇 건이 몰렸는지 보이고, 상태와 날짜가 붙어 있어야 어느 칸에서 며칠씩 멈추는지 보이며, 라벨을 같은 기준으로 붙여야 기술 부채를 갚는 데 이번 분기에 며칠을 썼는지 셀 수 있습니다. 빈칸이 많은 보드도 목록으로는 쓰이지만 이런 질문에는 답하지 못합니다.

두 갈래 위에는 층이 하나 더 있습니다. 큰 덩어리부터 에픽, 유저 스토리, 태스크, 버그처럼 나뉘고 층마다 적는 정보가 다릅니다. 에픽에는 무엇을 왜 하는지가, 스토리에는 사용자가 무엇을 하려는지가, 태스크에는 실제로 손댈 파일과 순서가 적힙니다. 페이지덱으로 보면 문서 공유 개선이라는 에픽 하나 아래 스토리가 여섯 개 달리고, 그중 링크로 공유하기 스토리가 다시 태스크 셋으로 나뉩니다. 공유 링크를 만들어 주는 서버 작업, 공유 설정 화면, 링크를 받은 사람이 열었을 때 권한을 확인하는 처리입니다. 에픽만 보면 이번 달에 무엇을 하려는지가 보이고, 태스크까지 내려가면 내일 아침에 누가 무엇을 여는지가 보입니다. 어디까지 쪼갤지는 팀이 정하는데 대체로 한 사람이 며칠 안에 끝낼 크기까지 내려갑니다. 스프린트처럼 고정된 주기로 일한다면 한 건이 한 주기 안에 끝나는 크기여야 상태가 주기 끝까지 진행 중에 머무는 일을 피할 수 있습니다.

"그건 이슈로 만들어 주세요. 메신저에 적으면 내일이면 묻힙니다."

말로 오간 요청을 추적 가능한 한 건으로 남기자는 요구입니다.

"이 티켓 완료 조건이 안 적혀 있는데, 어디까지 하면 닫는 건가요?"

만든 사람과 맡은 사람이 생각하는 끝이 다를 수 있으니 먼저 맞추자는 말입니다.

"이건 너무 커요. 서브태스크로 쪼개서 이번 주기엔 앞의 둘만 담읍시다."

한 주기 안에 끝나지 않을 크기이니 단위를 나눠 진척이 보이게 하자는 제안입니다.

페이지덱에서 이 말이 가장 자주 오가는 자리는 주간 점검입니다. 지현이 보드를 열어 두고 진행 중 칸에 사흘 넘게 머문 건부터 짚습니다. 실제로 손대고 있는 중인지, 다른 일에 밀린 것인지, 아니면 이미 끝났는데 옮기지 않은 것인지를 묻습니다. 세 번째 경우가 생각보다 많고, 그때마다 보드는 조금씩 현실과 멀어집니다.

태오는 버그가 올라오면 재현 순서를 먼저 채워 달라고 요청합니다. "안 됩니다" 한 줄만 적힌 건은 확인하는 데만 반나절이 들고, 그 반나절은 계획에 없던 시간입니다. 민서는 디자인 검토가 필요한 건에 라벨을 붙여 두고 주 1회 모아서 봅니다. 건마다 불려 가는 대신 한 번에 처리하기 위해서입니다. 지현은 기한을 고객사와 날짜를 약속한 건에만 붙입니다. 한때 모든 건에 날짜를 넣어 두었더니 지난 날짜가 절반을 넘었고, 그때부터는 아무도 그 칸을 보지 않게 됐기 때문입니다. 도구를 잘 쓰는 팀과 못 쓰는 팀의 차이는 대개 이런 작은 약속이 있느냐에서 갈립니다.

건을 많이 만들어 두면 관리되고 있다고 여기는 오해가 가장 흔합니다. 보드가 항목으로 빽빽하면 일이 잡혀 있는 것처럼 보이니 그렇게 느끼기 쉽습니다. 그런데 300건이 쌓인 목록은 아무도 끝까지 읽지 않습니다. 읽히지 않는 목록은 적어 두지 않은 것과 같고, 게다가 안심시키는 효과까지 있어 더 나쁩니다. 실제로 필요한 것은 등록을 늘리는 일이 아니라 닫는 규칙을 정해 두는 일입니다. 반년 넘게 손대지 않은 건은 지금 안 하기로 결정한 것이니 닫고, 필요해지면 다시 만드는 편이 목록을 읽을 수 있게 유지합니다. 페이지덱 보드에도 한 번도 열리지 않은 건이 백 건 넘게 쌓여 있었는데, 지현이 반년 넘은 것을 한자리에서 닫자 남은 것은 서른두 건이었습니다. 목록이 끝까지 읽히는 길이로 줄고 나서야 그 안에서 무엇을 먼저 할지 정하는 대화가 가능해졌습니다.

두 번째는 상태 값을 실제 상태와 같다고 믿는 것입니다. 보드에 진행 중이라고 적혀 있으면 지금 누군가 그 일을 하고 있다고 읽게 됩니다. 값을 옮기는 일은 사람 손에 달려 있어서, 실제로는 이미 끝난 건과 일주일째 멈춘 건이 같은 칸에 나란히 있습니다. 그대로 두면 보드를 근거로 세운 계획이 매번 빗나가고, 결국 팀은 보드를 안 보고 서로에게 물어보는 예전 방식으로 돌아갑니다. 상태를 언제 옮길지를 팀이 합의해 두고 주 1회라도 함께 훑어야 기록이 현실을 따라갑니다. 페이지덱은 이 합의를 한 줄로 줄였습니다. 일을 시작할 때 옮기려 들지 말고, 그날 손을 떼기 전에 지금 들어가 있는 칸이 맞는지만 보자는 것입니다.