할 일 목록에 결제 오류 수정과 코드 정리와 신규 기능과 서버 판 올리기와 문서 갱신이 함께 들어 있었다. 다섯을 놓고 무엇부터 할지 정하려는데 비교가 되지 않았다.
Table of contents
Open Table of contents
비교할 수 없는 것들의 한 목록
결제 오류와 문서 갱신을 같은 기준으로 비교할 방법이 없었다. 하나는 지금 사용자에게 영향을 주고 있고 다른 하나는 없어도 당장은 아무 일도 일어나지 않는다. 급한 정도 하나로 줄을 세우면 문서 갱신 같은 항목은 영원히 맨 뒤에 놓인 채로 남는다.
같은 기준으로 비교할 수 없는 것을 한 목록에 두고 있었던 것이 문제였다. 우선순위를 못 정한 것이 아니라 애초에 정할 수 없는 형태로 늘어놓고 있었던 것이다.
종류별 기준
넷으로 나눴는데 지금 문제가 되고 있는 장애와 버그, 누군가 원해서 들어온 요청 기능, 나중에 문제가 될 기술 부채, 기한이 있어 해야 하는 운영 작업이다.
각각 우선순위를 정하는 기준이 달랐다. 장애는 영향 범위와 심각도로 정하고 요청은 요청자와 기한으로 정하며 부채는 나중 비용과 지금 비용을 견주고 운영 작업은 기한으로 정한다. 보안 갱신처럼 기한이 이미 정해져 들어오는 것이 운영 쪽에 몰려 있다.
종류별 시간 배분
종류마다 주당 시간을 정했는데 장애는 나오면 바로 처리하되 시간을 정하지 않고 요청 기능에 주 3일과 기술 부채에 주 1일과 운영 작업에 주 1일을 뒀다.
시간을 종류별로 나누기 전에는 급한 것이 항상 이겼다. 요청 기능만 계속 하고 부채는 손대지 못했는데 그것이 판단의 결과가 아니라 배분이 없어서 생긴 결과였다.
장애가 넘치는 경우도 정해 뒀는데 장애 처리가 주 3일을 넘으면 그 주는 다른 것을 하지 않고 왜 장애가 많은지를 본다. 두 주 연속으로 넘었을 때 원인을 봤더니 대부분이 한 배포에서 나온 것이었다.
목록 분리와 증감 관찰
파일도 종류별로 나눴는데 한 파일에 있을 때는 긴 목록 하나만 보였고 나누고 나니 각각이 짧아 보이면서 어느 목록이 길어지는지가 드러났다.
issues 3
requests 12
debt 28
ops 4부채가 가장 길었고 주 1일로는 줄지 않고 있었다. 월별로 세어 보니 22건에서 25건을 거쳐 28건으로 오히려 늘고 있었다. 만드는 속도가 갚는 속도보다 빠르면 배분을 바꿔야 한다는 것이 숫자로 나왔다. 부채를 주 2일로 늘리고 요청 기능을 하루 줄였고 그 판단을 요청하는 쪽에 숫자와 함께 알렸다.
종류를 잘못 넣은 것들
목록을 보다가 요청으로 들어왔지만 성격이 다른 것을 찾았는데 로그 형식 통일은 사실 부채였고 서버 판 올리기는 운영 작업이었다.
그래서 항목이 들어올 때 종류를 정하게 하고 애매하면 물어보게 했다. 종류를 잘못 넣으면 잘못된 기준으로 우선순위가 매겨지므로 그 항목은 계속 뒤로 밀리거나 필요 이상으로 앞으로 온다.
여러 종류에 걸치는 항목
결제 오류를 고치면서 그 김에 구조도 바꿔야 한다는 항목이 있었는데 장애이면서 동시에 부채인 것이었다.
둘로 나눠서 넣었는데 결제 오류 수정은 장애 목록에 급한 것으로 두고 결제 구조 개선은 부채 목록에 급하지 않은 것으로 뒀다. 한 항목으로 두면 급한 쪽이 구조 변경까지 급하게 만들고 급하게 바꾼 구조는 대개 더 나빠진다. 나누고 나니 각각 맞는 속도로 처리됐다.
정리
- 성격이 다른 것을 한 목록에 두면 비교가 안 된다
- 우선순위를 못 정한 것이 아니라 정할 수 없는 형태였다
- 종류를 나누고 각각 다른 기준으로 우선순위를 정한다
- 종류별로 시간을 나누지 않으면 급한 것만 하게 된다
- 급한 것이 넘치면 그 자체가 봐야 할 신호다
- 목록을 나눠 두면 어느 것이 길어지는지 보인다
- 들어올 때 종류를 정한다. 잘못 넣으면 기준도 잘못된다
- 여러 종류에 걸치는 항목은 나눠서 각자 속도로 처리한다