변경 안내

제품이 2주에 한 번씩 바뀌는데 고객은 그 변화를 월요일 아침에 화면에서 처음 만나던 시절이 있었습니다. 제품팀은 배포 목록을 성실히 적어 두었지만 그 목록은 만든 쪽의 언어로 쓰여 있었습니다. 어떤 기능이 추가됐고 어떤 동작이 개선됐다는 문장들이었고, 읽는 사람이 무엇을 해야 하는지는 적혀 있지 않았습니다.

결재 요청 버튼의 위치가 바뀐 날이 그 차이를 보여 줬습니다. 배포 목록에는 한 줄이 올라갔습니다. 그날 문의는 마흔 건이 들어왔고 대부분 같은 질문이었습니다. 버튼이 없어졌다는 것입니다. 사내 교육 자료에 예전 화면을 캡처해 둔 기업 고객 세 곳은 그 자료를 다시 만들어야 했고, 한 곳은 우리에게 알리지도 않고 다음 분기 도입 확대를 보류했습니다.

변경 안내는 이 빈칸을 메우려고 따로 만든 문서입니다. 무엇이 바뀌었는지를 적는 데서 멈추지 않고, 이 변화가 고객의 업무 절차에서 무엇을 건드리는지와 고객이 언제까지 무엇을 해 두어야 하는지를 적습니다. 쓰는 사람의 시점이 아니라 받는 사람의 할 일이 기준입니다.

한 건의 안내는 여섯 항목으로 짭니다. 순서를 바꾸지 않는 이유는 읽는 사람이 첫 두 줄에서 자기 일인지 아닌지를 판단하고 내려가기 때문입니다.

1. 한 줄 요약입니다. 무엇이 언제부터 어떻게 바뀌는지를 한 문장에 담습니다. 제목에 기능 이름만 적으면 메일 목록에서 걸러지므로 날짜를 함께 넣습니다.
2. 적용 날짜와 대상입니다. 전체 고객인지 특정 요금제인지, 한 번에 켜는지 며칠에 걸쳐 나누는지를 적습니다. 대상을 비워 두면 해당 없는 고객까지 문의를 보냅니다.
3. 고객이 해야 할 일입니다. 여기가 이 문서의 몸통이고, 할 일이 없을 때도 없다고 적습니다. 비워 두면 읽는 사람은 자기가 무언가를 놓쳤다고 의심하며 문의를 보냅니다.
4. 바뀌기 전과 후입니다. 절차가 바뀌었으면 단계를 나란히 적고, 화면이 바뀌었으면 이미지를 둘 넣습니다. 글로만 쓰면 관리자가 사내 공지를 다시 쓸 때 우리 문장을 그대로 옮기지 못합니다.
5. 영향받는 기존 설정과 연동입니다. 권한 규칙, 템플릿, 외부 도구 연결 중 이번 변경으로 다시 확인해야 하는 것을 짚습니다. 이 항목이 없으면 배포 다음 주에 연동이 조용히 멈춘 계정이 나옵니다.
6. 도움말 문서와 문의 창구입니다. 자세한 사용법은 도움말 문서, 곧 기능별 사용법을 적어 둔 안내 문서로 넘기고 안내 자체는 짧게 둡니다.

되돌릴 수 없는 변경은 따로 다룹니다. 기존 방식이 아예 없어지는 경우 페이지덱은 최소 30일 전에 알리고, 그 기간에 쓸 수 있는 임시 방법과 담당자 연락처를 함께 적습니다.

초안은 제품팀이 씁니다. 무엇이 바뀌었는지를 정확히 아는 사람은 만든 쪽이므로 태오가 배포 내용과 적용 범위를 적습니다. 그다음 수아가 고쳐 씁니다. 고객이 해야 할 일과 기존 설정에 미치는 영향은 고객의 업무를 아는 쪽만 쓸 수 있고, 여기에서 문장의 절반이 바뀝니다. 파괴적인 변경이면 지현이 공지 시점과 임시 방법을 함께 정합니다.

독자는 한 종류가 아닙니다. 셋으로 갈리고 필요한 것이 다릅니다. 매일 제품을 쓰는 실무 사용자는 화면이 어떻게 달라지는지만 알면 됩니다. 계정 관리자는 권한과 설정을 다시 봐야 하는지를 알아야 합니다. 기업 고객의 사내 교육 담당자는 자료를 고쳐야 하므로 이미지와 단계 목록이 필요합니다.

그래서 한 건을 여러 창구로 나눠 보냅니다. 제품 안 배너는 실무 사용자에게, 메일은 계정 관리자에게, 영향이 큰 변경은 담당자가 직접 계정에 연락합니다. 사내 교육 담당자가 있는 기업 고객에는 교육 세션, 곧 담당자가 직접 진행하는 사용법 교육을 한 번 더 잡아 줍니다. 인증 프로그램처럼 숙련도를 공인해 주는 과정을 운영하고 있으면 그 교재도 같은 날 고칩니다. 교재가 예전 화면을 담고 있으면 우리가 만든 자료가 고객을 틀린 방향으로 가르칩니다.

"이번 배포 변경 안내 초안 왔는데 고객이 해야 할 일 칸이 비어 있어요. 없으면 없다고 적어 주세요."

이 칸의 공백이 문의로 돌아온다는 지적입니다.

"결재 흐름이 바뀌는 건이라 30일 전 공지로 갑니다. 이번 배포에는 안 넣습니다."

되돌릴 수 없는 변경은 배포 일정보다 공지 기간이 앞선다는 뜻입니다.

"기업 고객 다섯 곳은 메일만 보내지 말고 담당자가 직접 알립시다. 사내 교육 자료 고쳐야 하는 곳이에요."

같은 내용이라도 계정에 따라 창구를 달리한다는 판단입니다.

페이지덱에서는 배포 하루 전에 수아와 태오가 안내 한 건을 같이 읽습니다. 태오가 적은 문장에서 기능 이름을 걷어내고 고객이 하는 일의 이름으로 바꾸는 것이 대부분의 작업입니다. 권한 모델이 바뀌었다는 문장은 팀원을 초대하는 방법이 달라졌다는 문장이 됩니다.

배포 다음 주에는 문의 내용을 다시 봅니다. 같은 질문이 열 건 넘게 들어왔으면 안내가 그 항목을 빠뜨린 것으로 보고 문서를 고친 뒤 도움말 문서에도 반영합니다.

배포 목록을 올렸으면 안내한 것이라고 생각하는 경우가 가장 많습니다. 두 문서가 같은 배포를 다루니 하나로 보이기 쉽습니다. 하지만 목록은 무엇이 바뀌었는지를 시간 순으로 적은 기록이고, 안내는 특정 고객이 무엇을 해야 하는지를 적은 편지입니다. 목록만 올리고 끝내면 그것을 찾아 읽는 고객은 전체의 한 줌이고, 나머지는 화면이 바뀐 뒤에 문의로 알게 됩니다.

작은 변경은 알릴 필요가 없다고 보는 것도 흔한 오해입니다. 만든 쪽에서는 버튼 위치를 옮긴 일이 코드 몇 줄이라 알릴 거리로 보이지 않습니다. 그런데 고객 쪽에서 작은 변경인지를 정하는 것은 코드의 크기가 아니라 그 동작이 사내 절차에 박혀 있는지입니다. 매일 쉰 명이 누르는 버튼이 옮겨 가면 그날 문의가 마흔 건 들어오고, 그중 몇 건은 제품이 고장 났다는 신고로 접수됩니다. 크기 기준은 우리 쪽 작업량이 아니라 고객이 다시 익혀야 하는 동작 수입니다.