범위

같은 일을 두고 사람마다 다른 크기를 상상하던 문제에서 시작합니다. "쿠폰 기능 하나 붙이죠" 라는 말에 개발자는 결제 화면에 입력칸 하나를 붙이는 그림을 그리고, 세일즈는 고객사가 원하는 대로 쿠폰을 만들어 뿌리는 관리자 화면까지 포함된 그림을 그립니다. 둘 다 "쿠폰 기능" 이라는 같은 말을 쓰고 있으니 회의 중에는 어긋난 줄 모릅니다.

그 어긋남은 일정에서 먼저 드러납니다. 얼마나 걸리겠느냐는 질문에 한 사람은 2주라고 답하고 다른 사람은 6주라고 답합니다. 두 사람 중 누가 실력이 부족한 것이 아니고, 머릿속에 그려 둔 만들 것의 양이 서로 세 배 차이가 났던 것뿐입니다. 이 상태로 착수하면 4주째에 "이것도 되는 줄 알았는데요" 라는 말이 나옵니다.

그래서 만들 것을 말로 합의하지 않고 문서에 적는 칸을 따로 두게 됐습니다. PRD에서 이 칸이 하는 일은 기능의 이름을 적는 것이 아니라 그 이름이 어디까지를 뜻하는지를 못 박는 것입니다. 경계가 문장으로 남아 있으면 추정도 같은 그림 위에서 나오고, 나중에 요청이 늘었을 때 늘었다는 사실 자체를 짚을 수 있습니다.

목록과 깊이 두 층으로 섭니다. 무엇을 만들지를 항목으로 늘어놓고, 항목마다 어디까지 만들지를 한 구절씩 붙입니다. 목록만 있으면 경계가 서지 않습니다.

쿠폰을 예로 들면 이렇게 갈립니다.

1. 포함 목록. 결제 화면에 쿠폰 코드 입력칸을 붙인다, 입력한 코드의 유효 여부를 확인한다, 할인 금액을 결제 금액에 반영한다. 세 줄입니다.
2. 항목마다의 깊이. 코드는 정액 할인 한 종류만 처리한다, 코드 발급은 이번에 운영팀이 데이터베이스에 직접 넣는 방식으로 간다. 이 두 줄이 없으면 정률 할인과 관리자 발급 화면이 포함된 것인지가 사람마다 갈립니다.
3. 명시적 제외. 이번에 하지 않기로 한 것을 따로 적는 칸을 범위 밖이라고 합니다. 자동 적용 쿠폰은 하지 않는다는 한 줄이 있으면 3주 뒤 그 이야기가 나올 때 논의가 5분에 끝납니다.

경계가 정해지면 세 가지가 함께 묶입니다. 만들 양, 걸리는 기간, 붙는 사람입니다. 하나를 늘리면 나머지 둘 중 하나는 움직여야 합니다. 양을 그대로 두고 기간만 줄이자는 요청은 사람을 더 붙이자는 요청이고, 사람을 그대로 두고 기간만 줄이자는 요청은 양을 줄이자는 요청입니다. 셋을 한꺼번에 고정하려 들면 남는 것은 품질뿐이라, 테스트를 건너뛰거나 예외 처리를 빼는 방향으로 빠집니다. 쿠폰 항목을 세 줄에서 다섯 줄로 늘리면서 2주를 그대로 두자고 하면, 실제로 잘리는 것은 코드가 틀렸을 때 무엇을 보여 줄지 정하는 일입니다.

바꾸지 못하는 것은 아닙니다. 다만 바꾸는 절차가 있습니다. 새 요청이 들어오면 그 자리에서 받는 대신 문서의 이 칸을 고치는 결정을 거치고, 고치면 기간이나 사람도 함께 다시 봅니다. 이 한 단계를 건너뛴 채 요청이 쌓이는 현상을 스코프 크리프라고 부릅니다.

이 칸을 실제로 여는 자리는 넷입니다.

1. 착수 전 추정. 개발자가 기간을 답하기 전에 먼저 읽는 칸입니다. 여기가 비어 있으면 나오는 답은 기간이 아니라 되묻는 질문입니다. 되물을 자리가 없는 상황이라면 대개 가장 큰 그림을 기준으로 답이 나옵니다.
2. 만들 것을 쪼개는 자리. 항목 하나를 사용자 관점의 한 문장으로 옮기면 유저 스토리가 되고, 그 문장들이 개발이 집어 갈 단위가 됩니다. 이때 범위에 없던 스토리가 만들어지면 그 자리에서 걸립니다.
3. 디자인 착수. 그려야 할 화면 수가 여기서 나옵니다. 입력칸 하나인지 관리자 화면까지인지에 따라 민서가 잡는 일정이 이틀과 2주로 갈립니다.
4. 고객에게 하는 말. 수아는 이 칸과 범위 밖을 먼저 확인하고 고객에게 답합니다. 확인하지 않으면 아직 만들지 않기로 한 것을 약속하는 일이 생깁니다.

페이지덱에서 쿠폰 기능을 잡을 때 실제로 그랬습니다. 지현이 처음 쓴 칸에는 "쿠폰 코드 입력과 할인 적용" 이라고만 적혀 있었고, 태오가 읽고 되물은 것이 두 가지였습니다. 정률 할인도 처리하느냐, 발급 화면도 이번에 만드느냐입니다. 두 줄을 더 적는 데 10분이 걸렸고, 그러고 나온 추정은 6주가 아니라 2주였습니다. 늘어날 뻔한 4주가 문장 두 줄에서 잘린 것입니다.

"이거 이번 범위에 들어가 있나요? 문서에는 안 보이는데요."

합의된 목록에 없는 요청이니 그냥 받지 말고 결정을 거치자는 말입니다.

"범위를 좀 좁히죠. 관리자 화면은 다음으로 넘기고 입력칸만 먼저 냅시다."

기간을 지키기 위해 만들 양을 줄이자는 제안입니다.

"범위가 이렇게 넓으면 2주로는 안 됩니다. 어느 쪽을 빼시겠어요?"

양과 기간이 서로 맞지 않으니 둘 중 하나를 고르라는 요구입니다.

착수 회의에서 이 말들이 나오는 위치가 정해져 있습니다. 규원이 언제까지 되느냐고 물으면 지현이 목록을 읽고, 태오가 읽은 목록을 기준으로 기간을 답합니다. 이 순서가 뒤집혀 기간이 먼저 정해지면 목록은 그 기간에 맞춰 줄어드는 대신 말로만 줄어들고, 문서에는 처음 목록이 그대로 남습니다. 3주 뒤에 문서를 여는 사람은 줄어들기 전 목록을 읽습니다.

한 번 정하면 못 바꾸는 약속으로 읽는 경우가 많습니다. 문서에 적혀 있고 여러 사람이 합의한 것이니 그렇게 보입니다. 하지만 이 칸의 목적은 변경을 막는 것이 아니라 변경을 눈에 보이게 하는 것입니다. 새로 알게 된 사실이 있으면 고치는 편이 맞고, 고치면서 기간을 함께 다시 보면 됩니다. 못 바꾸는 것으로 취급하면 팀은 문서를 고치는 대신 몰래 얹기 시작하고, 그러면 무엇이 늘었는지 아무도 모르는 상태가 돌아옵니다.

넓게 잡아 두면 안전하다고 생각하는 것도 흔합니다. 나중에 요청이 들어와도 이미 포함이라고 말할 수 있으니 편해 보입니다. 하지만 넓은 목록은 경계가 없는 목록과 같아서, 추정할 때 쓸 수 없고 무엇을 먼저 만들지도 정해 주지 않습니다. 넓게 적힌 한 줄은 3주 뒤에 "이것도 포함이었죠" 라는 말의 근거로 쓰이고, 그 말이 나오는 쪽은 늘 만드는 쪽이 아닙니다. 그때 문서는 합의의 근거가 아니라 방패로 쓰입니다.