트래킹 플랜

기록은 원래 기능을 만드는 자리에서 그때그때 심겼습니다. 개발자가 버튼에 이름을 붙여 분석 도구로 보내면 끝이었습니다.

문제는 반년쯤 지나서 드러났습니다. 지현이 지난달 문서 공유가 몇 번 일어났는지 묻자 태오가 분석 도구를 열었는데, 비슷한 이벤트 이름이 셋이었습니다. 웹에 심긴 doc_shared, 앱에 심긴 shareDocument, 브라우저 확장 프로그램에 심긴 Document Shared. 셋을 더해야 전체인지 아는 사람이 없었습니다.

같은 자리에서 다른 문제도 나왔습니다. 공유 이벤트에는 속성이 하나도 붙어 있지 않아서, 링크를 복사한 것인지 이메일로 초대한 것인지 구분할 수 없었습니다. 공유가 3,200번 일어났다는 숫자는 얻었지만 어느 방식이 많이 쓰이는지는 새로 심어 한 달을 기다려야 알 수 있었습니다.

트래킹 플랜은 이 합의를 심기 전으로 옮겨 놓은 문서입니다. 무엇을 남길지, 어떤 이름으로 남길지, 무엇을 함께 담을지를 기능 개발이 시작되기 전에 한 표에 적어 두고, 개발자는 그 표대로 심습니다. 이름 짓는 방식 자체를 통일해 두는 네이밍 컨벤션과 짝을 이루는데, 컨벤션이 규칙이고 플랜은 그 규칙으로 채운 목록입니다.

표 한 행이 이벤트 하나입니다. 열은 일곱 개를 기본으로 씁니다.

1. 이벤트 이름. 컨벤션에 맞춘 실제 문자열을 그대로 적습니다. 문서와 코드의 이름이 한 글자라도 다르면 문서가 쓸모를 잃습니다.
2. 무엇을 세는지 한 줄 설명. 언제 발생하는지를 조건으로 씁니다. 공유라면 공유 버튼을 누른 시점인지 상대가 실제로 초대받은 시점인지를 여기서 못 박습니다.
3. 발생 위치. 어느 화면에서 일어나는지 적습니다. 같은 행동이 세 곳에 있으면 셋을 모두 적어 이름이 갈라지는 것을 막습니다.
4. 수집 위치. 사용자 기기에서 보낼지 서버 수집으로 보낼지를 칸으로 표시합니다. 돈과 권한이 걸린 이벤트는 서버 쪽입니다.
5. 속성 목록. 이벤트 속성, 곧 한 줄에 함께 담을 부가 정보입니다. 속성마다 이름, 값의 형태, 가능한 값, 필수 여부를 씁니다. 공유 방식이라면 값을 링크·이메일·워크스페이스 셋으로 정해 둡니다.
6. 이 기록으로 답할 질문. 어떤 지표나 어떤 의문에 쓰일 예정인지 적습니다.
7. 상태와 담당. 제안·구현 중·검증 완료 가운데 어디인지, 누가 맡았고 언제 심겼는지를 씁니다.

사람에게 붙어 유지되는 값은 이벤트 표에 섞지 않고 별도 표로 둡니다. 요금제나 회사 규모 같은 유저 속성이 그쪽입니다.

가장 자주 비는 칸이 6번이고, 그 칸이 빈 이벤트가 먼저 짐이 됩니다. 쓸 데를 적지 못한 이벤트는 아무도 조회하지 않는데 코드에는 남아 있어서 기능을 고칠 때마다 함께 손대야 합니다.

초안은 그 기능을 맡은 기획자가 씁니다. 무엇을 알고 싶은지 아는 사람이 정해야 6번 칸이 채워지기 때문입니다. 데이터 전담자가 있으면 이름과 속성이 기존 규칙에 맞는지 검수하고, 열댓 명 규모에서는 그 검수까지 기획자가 겸합니다.

독자는 셋입니다.

1. 개발자. 심는 시점에 이 표를 보고 그대로 옮깁니다. 표에 없는 것은 심지 않고, 심어야 할 것이 생기면 표를 먼저 고칩니다.
2. 분석하는 사람. 반년 뒤에 어떤 이름이 무엇을 세고 있는지 확인할 때 봅니다. 2번 칸의 한 줄 설명이 여기서 값을 합니다.
3. 새로 들어온 사람. 어떤 데이터가 이미 있는지 파악할 때 첫 문서로 씁니다.

쓰는 시점은 기능 개발이 시작되기 전, 기획 문서를 쓸 때입니다. 개발이 끝난 뒤에 채우면 이미 심긴 이름을 옮겨 적는 작업이 되고 6번 칸은 끝내 비어 있습니다.

기능이 바뀌면 이벤트의 뜻도 바뀌는데, 같은 이름의 뜻을 고치면 지난 기록과 새 기록이 한 이름 안에서 섞입니다. 공유 이벤트를 버튼 누름에서 초대 완료로 바꾸면 그날부터 숫자가 30퍼센트 내려앉고, 문서에 적어 두지 않으면 다음 달에 누군가 공유가 줄었다고 보고합니다. 그래서 뜻이 바뀌면 새 이름으로 심고 예전 이름에는 폐기 표시를 달아 둡니다.

"이 기능 트래킹 플랜이 아직 없는데요. 개발 들어가기 전에 채워 주세요."

기록을 심는 작업이 기능 개발과 같은 일정 안에 있어야 한다는 요청입니다.

"플랜에 없는 이벤트가 심겨 있어요. 이거 누가 넣었는지 아세요?"

문서와 실제 코드가 어긋났다는 지적으로, 둘 중 하나를 맞춰야 한다는 뜻입니다.

"이 이벤트 뜻은 바꾸지 말고 새 이름으로 심어 주세요. 지난 6개월 값이 섞입니다."

정의를 갈아타면 과거 데이터와 새 데이터가 한 이름에 들어와 비교가 깨진다는 말입니다.

페이지덱에서는 기획 문서 아래쪽에 이 표가 붙어 있습니다. 지현이 새 기능의 화면과 동작을 적고 나면 같은 문서 끝에 이벤트 표를 채우고, 태오가 개발 착수 전에 그 표만 따로 확인합니다. 의견이 갈리는 칸은 대개 4번입니다. 요금제 업그레이드를 클라이언트에서 보내도 되는지 논의가 붙으면 결론은 서버 쪽이고, 그 결정이 표에 남으니 같은 논의를 반복하지 않습니다.

개발자가 쓰는 기술 문서라고 읽는 오해가 가장 흔합니다. 결과물이 코드에 들어가니 그렇게 보일 만합니다. 그런데 이 문서의 핵심은 무엇을 알고 싶은지를 정하는 쪽이고, 그건 기획하는 사람의 일입니다. 작성을 개발자에게 넘기면 구현하기 편한 단위로 이름이 붙습니다. 화면 단위로 페이지뷰만 촘촘히 심기고 정작 보고 싶은 행동은 빠지는 식입니다. 그렇게 만든 기록으로는 대시보드를 채울 수 없고, 반년 뒤에 필요한 이벤트를 새로 심어 다시 한 달을 기다립니다.

한 번 쓰면 끝나는 문서로 보는 경우도 자주 봅니다. 초기에 정리해 두면 이후로는 참고만 하면 될 것처럼 보입니다. 하지만 기능이 바뀌면 이벤트도 바뀌고, 갱신되지 않은 플랜은 없는 것보다 나쁩니다. 없으면 코드를 확인하러 가지만, 낡은 문서가 있으면 그것을 믿고 틀린 분석을 내놓기 때문입니다.