기능 출시에 앞서 우리가 준비해야 할 것
기능 가이드 문서를 제작하게 된 이유
특정 기능을 추가, 개선, 제거하는 등의 과정은 우리가 서비스를 담당하며 꼭 거쳐야 하는 단계 중 하나다. 중요한 건, 기능을 출시하며 우리가 고려해야 할 대상이 생각보다 많다는 것이다. 한 번은 한 달 동안의 준비 과정을 거쳐 새로운 기능을 서비스에 반영, 좋은 반응을 이끌어낼 수 있었는데 운영 담당자가 기능에 대한 문의를 계속 내게 확인하는 일이 있었다. 처음에는 익숙하지 않은 기능이기에 한번 더 확인하는 과정을 거친다고 생각했는데, 이후 세일즈 담당자 역시 고객사 미팅 전 해당 기능에 대해 자세한 설명을 요청하는 것을 보며 무언가 잘못되었다는 생각이 들었다.
기획 리뷰 등 주요 과정에 참여했고, 문서 등도 공유하며 업무에 참고를 요청했는데 왜 이런 일이 발생했을까? 당시 홀로 고민한 결과는 그럴듯한 이유에 다다르지 못했기에 기능 출시 후 대화가 늘어난 팀원 몇 명과 1:1 미팅을 진행해 자세한 이야기를 들을 수 있었다. 다만, 대화의 방향을 잘못 설정하면 ‘탓'을 하게 되는 상황이 발생할 수 있어 상대방의 입장에서 업무를 더 편하게 할 수 있는 방법에 초점을 맞춰 진행했다.
세일즈, 마케팅, 운영(CX) 업무를 하는 담당자들과 이야기를 해보니, 왜 홀로 고민했을 때 답을 찾지 못했는지 그 이유를 명확하게 알 수 있었다. 기획 문서는 나의 언어로 작성된 내용이 많기 때문이었다. 왜 만들어야 하는지, 주요 정책은 무엇인지, 어떤 일정에 따라 진행해야 하는지 등 기능을 어떻게, 잘 만들어야 하는지에 초점이 맞춰져 있어 막상 이 기능이 출시된 이후 각 담당자들이 어떻게 반응하고 활용해야 하는지에 대한 관점이 부족했다.
사용자를 위한 출시가 아니라, 우리 모두를 위한 출시라는 기준에서 나는 다시 한번 무엇을 챙겨야 하는지 생각하게 되었고 이를 통해 두 가지 방법을 업무에 활용할 수 있었다. 하나는 ‘모두를 위한 업무 매뉴얼 작성하기’에서 언급한 것처럼 담당자와 함께 기능 출시에 앞서 ‘업무 매뉴얼'을 작성하는 것이고 또 하나는 기능 릴리즈에 맞춰 내부에서 확인할 수 있는 지원 가이드를 제작하는 것이었다. 이번 글에서는 ‘지원 가이드'를 어떻게 활용하면 좋을지 정리하고자 한다.
영향을 받는 대상(사람) 정리
나는 보통 ‘스펙 문서'를 기능 개발의 출발점으로 활용한다. 이 기능을 왜 만들어야 하며, 목표는 무엇이고, 달성 여부는 어떻게 측정할 수 있는지, 개발 참여 인원과 대략적인 일정은 어떤지 확인할 수 있기 때문이다. 이 문서는 혼자 작성 후 공유하며, 논의를 거쳐 기능 개발의 기준으로 삼는다. ‘지원 가이드'를 제작하기 전, 스펙 문서를 다시 살펴보니 기능이 필요하다는 의견과 개발에 직접 참여하는 사람들의 의견은 자세히 담겨 있었지만 이후 어떻게 영향을 주게 되는지는 빠져있다는 사실을 알 수 있었다.
그래서 우선 ‘출발점’에서부터 이 기능으로 영향을 받는 대상(업무 관점에서)이 누구인지 함께 기록해보기로 했다. 당시 기준 내가 고려해야 할 대상은 크게 마케팅, 고객지원, 세일즈, 개발, 디자인, 기획으로 나눌 수 있었다. 그렇게 이 기능으로 인해 영향을 받는 기존의 기능이나 화면 등을 기록하는 것처럼 마케팅에서 이 기능은? 세일즈에서 이 기능은? 과 같은 맥락에서 작성을 시작했다. 그래야 기획을 하고, 디자인을 하며, 개발로 이어지는 과정에서 여유 시간을 활용해 기능 출시에 대한 구체적인 내용을 가이드로 제작할 수 있을 거란 생각이 들었다. 또 이런 노력은 기능의 사용으로 생겨나는 사용자 경험뿐 아니라, 기능을 사용하며 발생하는 이슈 등에 빠르게 대응하며 발생하는 사용자 경험을 더 적극적으로 관리하는데 도움이 될 수 있겠다는 생각도 들었다.
영향을 받는 대상이(사람) 필요로 하는 내용 정리
영향을 받는 대상을 정리한 다음 내가 준비한 건, 영향을 받는 사람들이 실제 ‘필요로'하는 정보를 정리하는 일이었다. 필요로 하는 정보를 기준으로 삼은 건, 앞서 언급한 것처럼 기존 기획 문서 등은 개발 관점에서 작성되어 다시 해석하는 과정을 거쳐야 하기 때문이다. 같은 기능이라 하더라도 각 업무 단위에 최적화된 내용이 없다면, 각자 담당하는 대상과 커뮤니케이션 등을 진행하는 데 있어 엇박자가 날 가능성이 높다.
고객지원 : 업무 매뉴얼을 별도 링크로 문서에 첨부하지만, 가이드에서도 어떤 접근이 필요한지 작성이 필요하다. 이 기능에 대해 어떻게 답변하면 좋은지, 이 기능으로 인해 발생 가능한 이슈나 문제는 무엇인지에 대한 내용이 있어야 한다.
영업 : 이 기능이 줄 수 있는 이점은 무엇인지 알고 있어야, 외부 미팅 시 상대방의 입장에서 설명할 수 있다. 가이드가 기능 단위로 잘 정리되어 있으면 이 문서만 봐도 어떤 내용을 먼저 제안해야 하는지 쉽게 구분할 수 있다.
마케팅 : 기능에 대한 콘텐츠 제작은 물론, 각 채널에 맞는 광고 소재로 어떻게 활용할 수 있는지 판단할 수 있다. 어떤 기능과 엮어 타겟에 따라 메시지를 전달할 수 있는지에 대한 정보로 쓸 수 있다.
기능 가이드 문서의 구성
문서의 구성은 다음과 같이 정리했다.
(1) 개요
(2) 배포 계획
(3) 기능 안내
(4) FAQ
(5) 담당자
(6) 참고 문서
먼저 개요는 기능 이름, 배포일, 설명 등으로 구성했다. 예를 들어 우리가 사용자의 입맛대로 콘텐츠를 저장할 수 있는 ‘컬렉션 기능'을 준비했다면, ‘컬렉션 기능'이 이름, 2022년 1월 10일이 배포일, 마지막으로 사용자는 콘텐츠 상세 화면에서 북마크 버튼을 통해 컬렉션에 특정 콘텐츠를 저장할 수 있다 는 설명이 된다. 컬렉션은 생성도 가능하지만, 삭제나 추가도 되고 이름을 변경할 수도 있는데 이런 내용은 ‘기능 FAQ’에 함께 기입했다.
배포 계획에는 언제, 어떤 시간에 어떤 방법(점진적 배포 등의 옵션이 포함될 수 있기 때문)으로 공개할 것인지가 포함됐다. 배포일은 슬랙 등에서도 공유할 수 있지만, 이 문서의 목적은 ‘필요에 의해' 언제든 확인 가능해야 한다는 것이라 배포 계획 역시 상세히 작성할 수 있었다.
이어 기능 안내에 대한 내용을 두 가지로 나눠 작성했다. 하나는 해당 기능을 어디서 확인할 수 있는지로 컬렉션을 기준으로 하면 저장하는 화면과 확인하는 화면으로 나눌 수 있다. 또 하나는 새롭게 추가되는 기능에 대한 정보를 어디에서 어떻게 알릴 것인지에 대한 내용이다. 예를 들어 상세 화면 진입 시 툴팁을 제공하거나, 자주 묻는 질문에 내용을 추가하거나, 앱스토어 스크린샷과 설명 등의 변경도 포함되었다.
기능 안내를 따로 작성한 이유는, 사용자에게 기능을 알리기 위한 소스를 쉽게 찾을 수 있도록 돕는 것과 더불어 사용자와 1:1 대화 또는 문의에 대한 답을 진행할 때 어디에서, 어떻게 발생한 문제인지 빠르게 파악하기 위해서였다. 이제 가이드 문서를 통해 마케팅 팀은 기능에 대한 핵심 내용과 필요 화면 등을 빠르게 확인해 블로그 게시글, 트위터 트윗 등에 필요한 내용을 작성할 수 있게 되었고, 고객지원팀 역시 매뉴얼과 함께 기능이 추가됨에 따라 파악해야 하는 내용을 문서 단위로 쉽게 파악할 수 있게 되었다.
FAQ를 가이드에 넣을지는 계속 고민했지만, 어차피 작성은 필요하고 기능 단위로 살펴보는 것이 이 문서의 목적이기에 함께 쓰게 되었다. FAQ만 따로 보는 것보다 문서에 포함된 다른 내용과 함께 보면 전반적인 흐름을 더 명확하게 파악할 수 있을 거란 판단도 있었다. FAQ는 기능을 사용하는 데 있어 발생 가능한 문제를 미리 확인할 수 있다는 측면에서 활용도가 높은 방법이기도 하다. 예를 들어 컬렉션 기능은 추가와 삭제가 기본적으로 가능하며, 이름 등을 수정할 수도 있는데 이런 내용을 FAQ 성격으로 풀어내 고객지원팀이 각 상황 별 어떤 식의 답변을 제공해야 하는지 참고할 수 있다.
담당자를 가이드 내 포함하는 것도 필요하다고 생각했는데, 문의 등에 바로 대응할 수 없는 상황이 생겼을 때 참여한 담당자를 빠르게 찾아 연락할 수 있는 용도로 활용할 수 있기 때문이다. 당시에는 대면 업무를 주로 했지만, 최근에는 비대면 업무가 많아져 담당자 이름과 역할 등을 꼭 포함해 바로 확인할 수 있도록 정리하고 있다. 또 다음 기능을 개발하는 데 있어 담당자가 변경되거나 빠졌을 경우 영향을 받는 내용을 확인하기 위한 목적으로도 중요한 역할을 할 수 있었다.
마지막으로 참고 문서는 필요에 의해 추가로 확인하면 좋은 내용을 정리하기 위해 생성했다. 실제 화면에 적용된(최종) 디자인 시안을 볼 수 있는 링크, 기능 개발 전 작성한 스펙 문서, 자주 묻는 질문을 전체 확인할 수 있는 링크 등이 포함되며, 이후 마케팅팀에서 작성한 콘텐츠 등도 추가했다.
가이드 문서의 활용과 효과
가장 큰 장점은 우리 각자가 기능 출시를 어떻게 받아들여야 하는지 생각해볼 수 있는 기준이 생겼다는 것이다. 기존에는 ‘개발 과정' 자체에 집중했다면, 이제는 개발 전, 후의 상황을 함께 고려할 수 있는 관점을 갖게 되었다는 점 역시 좋았다. 물론 처음에는 시간을 별도로 투자해야 하고, 문서에 넣어야 할 내용들의 기준을 잘 잡지 못해 어려움도 많았지만 다행히 문서를 주로 봐야 하는 사람들과 꾸준히 피드백을 주고받으며 개선할 수 있었다. 현재는 스펙 문서를 출발점으로, 가이드 문서를 마무리로 생각하며 각 단계에 포함해 활용하고 있으며 기능 단위로 계속 살펴볼 수 있는 중요한 문서 역할을 해주고 있다. 이 문서는 업무 매뉴얼과 사용자에게 안내할 ‘업데이트 노트'를 작성하는데도 많은 도움이 된다.
2023년 07월, 제 첫 도서가 출간되었어요. 제목은 ’10년 차 IT 기획자의 노트’입니다. 브런치 '기획자가 일하는 방법'을 시작하게 된 이유는 사수 없이 일하는 어려움을 저보다 조금 늦게 출발한 분들이 덜 느꼈으면 하는 마음 때문이었는데요. 같은 맥락에서, 9개 노트(기록)를 바탕으로 기획과 PM의 주요 업무를 어떻게 하면 좋을지 정리한 내용입니다. 아래 링크를 통해 자세한 내용을 확인하실 수 있어요!
