혼자 맡은 프리랜서 건에서 하나가 끝날 때마다 다음에 무엇을 할지 고객사 담당자에게 물어야 했다. 답을 기다리는 동안 눈에 띄는 것을 했는데 그것이 급한 것인지는 알 수 없었다.
Table of contents
Open Table of contents
증상 — 매번 묻는 동안 멈춘 시간
문제는 묻는 것 자체가 아니라 답이 올 때까지 판단이 멈춘다는 점이었다. 그 사이에 고른 일은 우선순위와 무관하게 눈에 띄었다는 이유로 골라진 것이었다.
물음을 줄이려면 무엇을 스스로 정해도 되는지가 먼저 정해져야 했다. 그 경계가 없으면 매번 처음부터 판단하게 된다.
판단 기준 — 정할 것과 물어볼 것의 경계
이미 합의된 BACKLOG.md 안의 것과 삼십 분 안에 끝나는 개선과 발견한 버그의 원인 조사와 README 갱신은 내가 정하기로 했다. 목록에 없는 새 기능과 하루를 넘기는 것과 고객사 다른 팀 일에 영향이 가는 것과 ALTER TABLE 처럼 되돌리기 어려운 변경은 물어보기로 했다.
기준을 이렇게 나누니 대부분의 경우 묻지 않아도 됐다. 경계가 애매한 것만 물으므로 묻는 횟수 자체가 줄었다.
조치 — 고를 수 있으려면 목록이 있어야 한다
내가 고를 수 있으려면 고를 것이 준비돼 있어야 했다. 두 가지 방법이 있었다. 고객사 Jira 에 내 작업을 올려 담당자가 순서를 매기게 하는 것과, BACKLOG.md 에 P1·P2 우선순위를 붙여 주에 한 번 같이 보면서 순서를 다시 정하는 것이다. 뒤쪽을 골랐다. 이유는 담당자가 Jira 를 매일 보지 않아 순서가 몇 주씩 안 바뀌어서다. 대신 목록 갱신을 내가 챙겨야 하는 것을 감수했다.
목록이 있으니 하나가 끝나면 위에서부터 내려가면 됐다. 고른 것을 아침에 한 줄로 알리고 시작했는데 묻고 기다리는 것과 알리고 시작하는 것은 멈추느냐 아니냐에서 갈렸다.
끼어들 수 있는 것의 범위
목록이 있어도 급한 것이 들어오면 순서가 흔들린다. 서비스가 멈춘 것은 하던 것을 즉시 멈추고 사용자 문의는 하던 것을 끝내고 그날 안에 처리하기로 했다.
요청받은 개선은 바로 하지 않고 BACKLOG.md 에 넣어 다음 주에 순서를 정하게 했다. 전부 급하다고 하면 목록이 의미를 잃으므로 무엇이 끼어들 수 있는지를 미리 정해 둔 것이다.
조사와 선택의 분리
버그를 발견하면 원인 조사까지는 내가 하고 고치는 방법의 선택은 물었다. 조사 결과와 영향 범위와 방법 몇 가지를 함께 내면 답이 빨리 온다.
조사는 내가 하고 선택만 묻는 구조로 나누니 대기 시간이 크게 줄었다. 물어봤다가 안 하기로 한 것도 BACKLOG.md 의 ## 보류 에 남겼는데 지우면 몇 달 뒤에 같은 것을 다시 묻게 되기 때문이다.
정리
- 다음 할 일을 매번 물으면 답이 올 때까지 판단이 멈춘다
- 그 사이에 고른 일은 우선순위와 무관하게 골라진다
- 내가 정할 것과 물어볼 것의 경계를 미리 긋는다
- 고를 수 있으려면
P1·P2가 붙은BACKLOG.md가 있어야 한다 - 묻고 기다리는 대신 고른 것을 알리고 시작한다
- 무엇이 끼어들 수 있는지를 정하지 않으면 목록이 의미를 잃는다
- 조사는 내가 하고 선택만 물으면 대기가 줄어든다
- 안 하기로 한 것도
## 보류에 남겨야 같은 것을 다시 묻지 않는다