티켓

일이 말과 메신저로만 오가던 시절에는 무엇이 남아 있는지 아무도 정확히 몰랐습니다. 회의에서 부탁한 일, 복도에서 지나가며 말한 일, 대화방에 적어 둔 일이 각각 다른 곳에 흩어져 있었습니다.

그래서 같은 질문이 반복됐습니다. 그거 언제 되느냐고 물으면 답할 근거가 없습니다. 맡은 사람은 다음 주라고 기억하고 부탁한 사람은 이번 주로 들었습니다. 두 사람이 같은 일을 각자 하고 있는 경우도, 서로 상대가 할 줄 알고 아무도 하지 않은 경우도 생겼습니다.

페이지덱에서도 대화방에서 부탁받은 문구 수정이 다른 대화에 밀려 3주 뒤에 발견된 일이 있었습니다. 아무도 잊으려고 한 것이 아니고, 그 부탁이 남아 있는 자리가 흘러가는 대화뿐이었던 것입니다.

티켓은 일 한 건을 화면에 등록해 번호를 붙이는 방식입니다. 접수 창구에서 번호표를 뽑는 그림에서 온 이름이라, 등록된 순간부터 그 일은 누군가의 기억이 아니라 목록의 한 줄이 됩니다. 목록에 있으면 셀 수 있고, 셀 수 있으면 언제 되느냐는 질문에 답할 수 있습니다.

도구마다 이름이 달라도 실제로 적히는 것은 대체로 다섯입니다.

1. 제목입니다. 목록에서 한 줄로 보이는 부분이라 여기서 구분이 끝나야 합니다. 로그인 오류라고 적는 것보다 비밀번호 재설정 메일이 도착하지 않음이라고 적으면, 목록을 훑는 사람이 열어 보지 않고도 무엇인지 압니다.
2. 설명입니다. 왜 필요한지와 어떤 상황에서 생기는지를 적습니다. 버그라면 재현 순서와 기대한 동작과 실제 동작 셋을 함께 적습니다. 이 셋이 없으면 맡은 사람이 먼저 하는 일은 고치는 것이 아니라 상황을 다시 만들어 보는 것입니다.
3. 완료 조건입니다. 무엇이 되면 이 건을 닫아도 되는지를 적습니다. 다섯 가운데 가장 자주 빠지는 항목입니다. 적는 사람이 상대도 당연히 알 것이라 여기기 때문인데, 그러면 맡은 사람은 검색 결과 정렬만 고치고 닫았는데 만든 사람은 검색어가 비었을 때의 처리까지 기대하고 있었다는 식으로 갈라집니다. 이 차이는 대개 배포 직전에 드러나 일정을 하루 이틀 밀어냅니다.
4. 크기 추정입니다. 이 일이 얼마나 큰지를 적어 두면 다음 주기에 담을 양을 가늠할 때 그 값을 씁니다.
5. 연결입니다. 에픽처럼 큰 덩어리 아래에 매달아 두면 그 덩어리가 지금 몇 퍼센트 진행됐는지가 자동으로 나옵니다. 한 건이 여러 사람에게 걸쳐 있거나 며칠 이상 걸리면 서브태스크로 쪼개 아래에 붙입니다.

여기에 값이 몇 개 더 붙습니다. 담당자와 기한, 우선순위, 그리고 지금 어느 단계에 있는지를 나타내는 워크플로 상태입니다. 앞의 다섯이 내용이고 이쪽은 찾고 세기 위한 꼬리표입니다.

쓰는 사람과 읽는 사람이 다르다는 점이 이 기록의 성격을 정합니다. 읽는 쪽이 셋이고 각자 보는 곳이 다릅니다.

1. 쓰는 사람은 요청이 생긴 쪽입니다. 프로덕트 매니저도 쓰고 디자이너도 쓰고 고객 문의를 받은 사람도 씁니다. 등록 권한을 한 사람에게 모아 두면 그 사람을 거치는 동안 요청이 밀립니다.
2. 맡는 사람이 첫 독자입니다. 설명과 완료 조건을 읽고 시작하고, 읽어서 모르는 것은 티켓 안 댓글로 되묻습니다. 되묻는 자리가 티켓 안이어야 그 답이 나중에도 남습니다.
3. 흐름을 보는 사람이 둘째 독자입니다. 상태별로 몇 건이 쌓여 있는지를 보고 어디서 막혔는지 판단합니다. 이 사람에게는 개별 내용보다 꼬리표가 정확한지가 먼저입니다.
4. 반년 뒤에 오는 사람이 셋째 독자입니다. 이 화면이 왜 이렇게 되어 있는지를 찾는 사람이고, 그때 근거가 남아 있는 곳이 이 티켓입니다. 결정을 대화방에서만 하고 티켓에 옮겨 적지 않으면 그 근거가 사라집니다.

쓰는 시점은 요청이 생긴 순간입니다. 나중에 몰아서 쓰면 왜 그 요청이 나왔는지가 이미 흐려져 있습니다. 대화방에서 결론이 난 경우에도 그 결론을 티켓에 옮겨 적는 것을 규칙으로 두는 팀이 많습니다.

"티켓 하나 만들어 주시면 이번 주에 볼게요."

기억이 아니라 목록에 올려 달라는 요청입니다.

"완료 조건이 없는데요. 어디까지 하면 닫아도 되는 건가요?"

셋째 항목이 빠져 시작할 수 없다는 지적입니다.

"그 결정 대화방에만 있어요. 티켓에 옮겨 적어 두죠."

나중에 오는 독자를 위해 근거를 남기자는 제안입니다.

페이지덱에서는 등록을 누구나 할 수 있게 두고, 제목과 완료 조건만 필수로 잡았습니다. 설명이 짧아도 받아 주지만 완료 조건이 비면 도구가 등록을 막습니다. 수아가 고객 문의에서 올린 건도 같은 곳으로 들어오고, 지현이 주 1회 훑어 우선순위와 상위 항목만 붙입니다.

한 번 규칙을 고친 일이 있었습니다. 초기에는 태오가 대화방에서 부탁받은 일을 그대로 처리했는데, 그러면 그 주에 무엇을 했는지가 어디에도 남지 않았습니다. 지금은 5분이 넘는 일이면 티켓을 먼저 만들고 번호를 대화방에 붙여 둡니다.

잘게 많이 만들면 관리가 잘된다고 보는 경우가 가장 많습니다. 기록이 자세하면 좋다는 생각이 자연스럽게 따라옵니다. 하지만 티켓 하나에는 만들고 옮기고 닫는 손이 들어갑니다. 30분이면 끝나는 일을 서브태스크 넷으로 쪼개면 실제 작업보다 상태를 옮기는 데 시간이 더 걸립니다. 그러면 사람들은 상태를 미루다 한꺼번에 옮기고, 보드에 적힌 상태와 실제 상태가 어긋나기 시작합니다. 흐름을 보려고 만든 꼬리표가 흐름을 보여 주지 못하게 되는 지점입니다.

티켓에 적어 두면 전달된 것이라고 보는 것도 흔합니다. 등록했으니 상대가 읽을 것이라 여기기 쉽습니다. 다만 등록은 기록이고 합의는 아닙니다. 완료 조건에 적힌 내용이 맡을 사람이 생각하는 것과 같은지는 그 사람이 확인해 줘야 알 수 있습니다. 특히 다른 팀에 넘기는 건이 그렇습니다. 티켓만 만들어 두고 두 주가 지난 뒤 아직 시작하지 않았다는 사실을 알게 되는 일이 잦습니다. 등록한 다음에 한 줄 알리는 것까지가 요청입니다.