정확한 마감을 잡을수록, 더 자주 틀렸다
개발자로 몇 년 스프린트를 돌리고 나서 든 생각이 하나 있다. 나는 마감을 못 지킨 게 아니라, 애초에 마감을 잘못 잡고 있었다. 날짜를 정확히 박을수록 그 날짜는 더 빨리 거짓말이 됐다.
마감은 매주 바뀌었다
스프린트를 시작할 때 잡은 일정이 그대로 간 적은 거의 없다. 월요일에 "이건 이틀"이라고 적어두면, 수요일에 장애 하나가 터지면서 순서가 통째로 뒤집힌다. 이틀 안에 끝낸다던 작업이 남의 팀 응답 하나 안 와서 며칠 밀리기도 한다. 마감 하루 전 스크럼은 대개 "어디까지 됐나"보다 "무엇을 다음으로 미루나"를 정하는 자리였다. 정확한 날짜를 잡을수록, 그 날짜를 지키기보다 매번 다시 잡는 데 시간을 썼다.
버그는 견적 자체가 안 된다
새 기능은 그나마 낫다. 대충이라도 크기를 가늠할 수 있다. 문제는 버그와 장애다. 원인을 알아야 얼마나 걸릴지 아는데, 원인을 아는 순간 이미 절반은 고친 거다. 재현조차 안 되는 버그는 한 시간이 걸릴지 사흘이 걸릴지 아무도 모른다. 그런 일에 "목요일까지"를 붙이는 건, 모르는 걸 안다고 적는 일이었다.
계획이 정확해도 어긋난다
이게 소프트웨어만의 병은 아니다. 내가 본 글은 공장의 생산 계획을 예로 든다. 설비와 공정 데이터를 아무리 완벽하게 쥐고 있어도, 막상 라인을 돌리면 계획은 매번 어긋나 다시 짠다. 몇 초면 될 공정이 몇 시간으로 늘기도 한다. 완전한 정보를 쥔 제조업조차 그런데, 매번 처음 보는 문제를 다루는 개발이 날짜를 정확히 맞힐 리 없다. 정확한 견적이 가능하다는 믿음부터가, 현실보다 계획서를 더 믿는 착각이었다.
시간을 주면 딱 그만큼 쓴다
반대로 마감을 넉넉히 잡으면 그만큼 늘어진다. 파킨슨 법칙 그대로다. 일은 주어진 시간을 꽉 채운다. 이틀 잡은 일이 하루 만에 끝나는 경우는 드물고, 대개 이틀을 다 쓴다. 정확한 마감은 일을 앞당기지 못했다. 오히려 그 시간까지 붙잡아두는 장치였다.
날짜를 뺀 자리에 우선순위를 둔다
그래서 요즘은 날짜 대신 우선순위와 속도를 둔다. "지금 뭐가 제일 급한가"로 판단하면, 장애가 터졌을 때 죄책감 없이 순서를 바꿀 수 있다. 기한이 "이번 주" 정도로 느슨하면 오히려 급한 걸 먼저 처리할 여유가 생긴다. 어떤 지표는 하루치 결과만 보고 다 됐다고 말할 수 없어서, 며칠을 더 지켜본 뒤에야 개선 여부를 판단한 적도 있다. 날짜로 "언제 끝"을 못 박았다면 그 관찰 기간을 죄책감 없이 확보하기 어려웠을 거다. 이 블로그 자동화를 만들 때도 그랬다. "며칠까지"를 지운 뒤로 오히려 매일 조금씩 굴러갔다. 마감이 사라지자 미루게 된 게 아니라, 오늘 할 만큼을 오늘 했다.
기대를 넘기는 것
결국 날짜를 맞추는 것보다 기대를 넘기는 게 중요하다. "금요일까지"라고 못 박고 금요일에 겨우 내는 것보다, 날짜를 말하지 않고 수요일에 내는 편이 신뢰를 만든다. 정확한 마감은 통제하고 있다는 느낌을 주지만, 매일 바뀌는 현실을 따라가지는 못한다. 마감을 느슨하게 쥐는 건 게으름이 아니다. 상황이 바뀐다는 걸 인정하는 정직함이다.
관리자 입장에서는 이게 불안하게 들릴 수 있다. "날짜 없이 어떻게 팀을 운영하냐"는 질문을 실제로 받은 적도 있다. 실제로 없앤 건 날짜에 대한 거짓 확신이었다. 대신 우선순위 목록과 진행 속도를 매일 공유하는 걸로 채웠다. "이번 스프린트 끝"이라는 고정된 약속 하나 대신, "지금 이 순서로 가고 있고 이 속도면 이만큼 나온다"는 걸 매일 갱신해서 보여준 거다. 위에 보고할 때도 날짜 하나에 매달리는 것보다 이쪽이 오히려 편했다. 날짜가 틀렸을 때 변명을 준비하는 대신, 매일의 진행 상황 자체가 답이 됐기 때문이다.
그래서 누가 "언제 돼요"라고 물으면, 이제 날짜로 답하지 않으려 한다. "급한 것부터, 최대한 빨리"라고 답한다. 틀릴 날짜를 약속하는 것보다, 바뀔 걸 아는 채로 빠르게 움직이는 편이 결국 더 정확했다.
대화 참여하기