상황
소수 인원의 개발 조직에서 여러 제품 화면을 동시에 출시 준비했습니다. 저는 개발 인력이 아니라 제품 관리와 설계를 맡았고, 개발팀이 검증할 수 있는 형태로 정책과 수용기준을 내는 것이 제 산출물이었습니다.
역할 경계를 먼저 문서로 박았습니다
가장 먼저 한 일은 기능 정의가 아니라 경계 정의 였습니다.
- 제품 관리가 정하는 것: 정책, 대상 사용자, 우선순위, 상태 확정 기준, 동의와 철회, 개인정보 최소화, 그리고 개발팀이 검증할 수 있는 수용기준
- 개발팀이 정하는 것: 실제 서버, 저장 구조, 재시도, 배포 방식 등 내부 구현
이 경계가 없을 때 나타나는 실패는 방향이 둘이었습니다. 제품 쪽이 내부 배선을 질문으로 만들어 개발자를 붙잡거나, 정책 문서에 구현 조사 내용이 섞여 정책이 무엇인지 읽히지 않게 되는 것입니다. 둘 다 겪은 뒤에 문장으로 고정했습니다.
재협의 사유도 못박았습니다. 정책이 바뀔 때, 개인정보를 더 넘겨야 할 때, 출시 범위나 일정이 바뀔 때입니다. 구현상 제약이 이 중 하나를 건드릴 때만 올라옵니다. 나머지는 개발팀이 결정하고 증거를 냅니다.
게이트를 하나로 줄였습니다
출시 준비 기간에 마감 게이트가 여러 개 있었습니다. 게이트가 여럿이면 각각이 개별 협상 대상이 되고, 하나가 밀리면 나머지가 연쇄로 밀립니다. 그리고 매번 "이번 건은 어느 게이트에 걸리나" 를 판정해야 합니다.
게이트를 하나로 합쳤습니다. 그 뒤로는 들어오는 요청마다 판정할 것이 없어졌습니다. 안이거나 밖입니다.
티켓에 축을 세웠습니다
이슈 라벨을 자유 태그로 두면 몇 주 만에 사람마다 다른 어휘가 쌓입니다. 축을 세 개로 고정했습니다. 기능, 제품 영역, 레이어. 이 셋이면 "무엇이 어디까지 준비됐나" 가 질의로 나옵니다. 진행률을 사람이 집계하지 않게 되는 것이 목적이었습니다.
담당자 배정도 서비스 기준으로 매핑을 만들어, 티켓을 만들 때 담당을 정하지 않아도 자동으로 라우팅되게 했습니다. 애매한 경우에 비워 두는 대신 리드에게 두고 재배정 표시를 남기게 한 것이 핵심입니다. 비어 있는 담당은 아무도 보지 않습니다.
그 축을 그리는 화면을 세웠습니다
축을 세워도 "지금 어디까지 됐나요" 에 답하려면 여전히 사람을 찾아야 했습니다. 진행 현황은 이슈 트래커에, 기준 문서는 저장소에, 배포 상태는 파이프라인 화면에 있었고, 셋을 합쳐 읽는 사람은 매번 같은 사람이었습니다. 각자 있는 곳이 잘못된 것은 아닙니다. 합치는 일이 한 사람의 머리에서만 일어난 것이 문제였습니다.
그래서 사내 포털을 세웠습니다. 크게 잡지 않고 셸 하나와 패널 셋으로 시작했습니다. 업무 현황, 파이프라인, 기준 문서입니다. 이 셋이 "얼마나 됐나, 지금 돌고 있나, 무엇이 기준인가" 에 각각 답합니다. 기능을 더 넣지 않은 이유는, 내부 도구가 실패하는 방식이 대개 기능 부족이 아니라 아무도 안 여는 것이기 때문입니다. 값은 처음에 손으로 갱신한 스냅샷으로 채우고 나중에 라이브로 옮겼습니다.
- 화면이 자기가 스냅샷인지 라이브인지 말해야 합니다. 갱신이 멈춘 값은 멈췄다는 신호를 스스로 내지 않습니다. 배지를 정직하게 고쳐, 무엇이 언제 기준으로 채워진 값인지 화면에서 읽히게 했습니다
- 가져오기가 실패하면 빈 화면이 아니라 스냅샷으로 떨어지게 했습니다. 빈 화면은 "값이 없다" 로 읽히는데 실제로는 "못 가져왔다" 입니다. 둘은 다른 말입니다
- 기준 값은 화면이 아니라 대조 스크립트가 지킵니다. 기준 문서가 바뀌었는데 포털이 옛 값을 들고 있는 상황을 사람이 발견하게 두지 않고, 대조해서 어긋나면 알리게 했습니다
포털을 만들며 말도 같이 정리했습니다. 딜리버리라는 이름을 업무 현황으로 바꾸고 홈 최상단에 올렸습니다. 개발 어휘를 그대로 두면 비개발 직군에게는 자기와 상관 없는 화면으로 보입니다. 실제로 그 화면은 그들이 가장 자주 물어보던 질문에 답하고 있었습니다.
배운 것
진행률을 사람이 집계하지 않게 되면서 회의에서 숫자를 맞추는 시간이 사라졌고, 그 시간에 숫자가 왜 그런지를 이야기하게 되었습니다.
가장 비싼 실패는 조용한 반복이었습니다. 같은 벽에 계속 부딪히면서 보고하지 않는 것입니다. 그래서 에스컬레이션 기준도 숫자로 적었습니다. 같은 접근 재시도는 두 번까지, 같은 문제에 일정 시간 이상 막히면 시도한 것과 각각 왜 안 됐는지를 붙여 올립니다. 그리고 범위를 몰래 줄여서 끝내지 않습니다. 줄일지 말지는 제 판단이 아닙니다.