좋은 배포란 무엇일까?
제품 공개를 준비하는 PM의 7가지 업무 순서
배포란 조직이 내부적으로 개발한 제품을 사용자 앞에 풀어놓는 것(Release)을 말합니다.
PM은 한해 적으면 3-4번에서, 많게는 20번-30번까지도 제품을 배포합니다. 이런 배포는 비행기의 이륙과 유사한데요. 1) 다양한 전문가들이 정해진 절차를 따른다는 점, 2) 배포 자체보다 이후 과정이 중요하다는 점, 3) 그리고 무엇보다 실수하면 큰일 난다는 점에서 특히 비슷합니다.
이번 챕터에서는 꼼꼼한 배포를 위해 챙겨야 할 7가지 단계를 이야기해 보겠습니다. 단계마다 PM의 주의사항도 다루겠습니다. 단계 별 예시로는 "배달의 민족 PM이 배민커넥트(배달 기사님 앱)에 레벨 시스템을 도입하는 상황"을 상상해보겠습니다.
[배달 기사 레벨 시스템이란?] :
배달 기사가 매일 정해진 횟수 이상의 배달을 수행하면 1-5 레벨을 달성하고 높은 레벨의 배달기사에게는 추가적인 보너스 포인트를 지급
1. 지표 세팅
지표부터 세팅합니다.
PM은 배포 직후부터 지표를 매일 추적해야합니다. 이때 2가지 지표가 필요합니다. 첫째는 목적 지표입니다. 프로젝트가 달성해야 할 핵심 목표를 다음날부터 일단위로 관찰할 수 있도록 준비합니다. 둘째는 가드레일(안전선) 지표입니다. 변화에는 늘 부작용이 따르게 마련입니다. 걱정되는 지점을 예측하고 부작용이 가드레일 안에 들어오는지 체크합니다.
예를 들어 [배달 기사 레벨 시스템]을 도입한다면 배달을 많이 하는 기사님을 확보할 목적일 겁니다.
프로젝트의 목적 지표로는
1) 기사의 활동성 증가
2) 출근 기사 수 증가
3) 레벨 별 달성 비중
등을 확인합니다.
가드레일 지표로는
1) 저활동 기사 이탈률
2) CX 인입건수
3) 보상 지급액
등을 살펴볼 수 있습니다.
목적 지표를 달성하면서, 부작용이 가드레일 안쪽에 있다면 성공적인 결과라 하겠습니다.
2. 시나리오 작성
배포 후 예상되는 시나리오를 써봅니다.
대부분의 배포는 PM이 예상한 대로 흘러가지 않습니다. 돌발 상황이 자주 생깁니다. 이럴 때 미리 예상했냐, 안 했냐로 대응의 속도가 달라집니다. PM은 배포 직전 동료들과 회의를 하고, 새로운 기능으로 인해 발생할 수 있는 모든 케이스를 상상해 봅니다. 특히 부정적인 상황을 예측하고 대응 플랜을 짜는 것이 중요합니다.
[배달 기사 레벨 시스템]을 배포할 경우 아래와 같은 문제 상황이 발생할 수 있습니다.
기사들의 활동성이 예상만큼 증가하지 않는다.
저활동 기사들이 불만을 품고 대거 이탈한다.
보상 지급액이 폭증하여 재무 부담이 커진다.
PM은 개별 시나리오에 맞게 대응책을 짜두고 관찰 즉시 대응합니다. 아래와 같은 방식을 쓸 수 있습니다.
기사들의 활동성이 예상만큼 증가하지 않는다.
→ 보상 지급액 조정 (1-3단계)
저활동 기사들이 불만을 품고 대거 이탈한다.
→ 저활동 기사 전용 혜택 추가
보상 지급액이 폭증하여 재무 부담이 커진다.
→ 보상 달성 난이도 조정 (1-3단계)
시나리오를 미리 생각해 두면 제품이 초기 시행착오를 줄이고, 사용자들 사이에 빠르게 정착할 수 있습니다.
3. 공지사항 & 패치노트 작성
제품 이해도가 높은 PM이 직접 공지사항 혹은 패치노트를 작성합니다.
작성 시에는 2가지 점을 주의합니다. 첫째, 짧고 이해하기 쉽게 씁니다. 사용자들은 대부분 글을 전혀 읽지 않습니다. 제목만 (혹은 이미지만) 스르륵 넘기더라도 대강 어떤 내용이구나 이해할 수 있을 정도로 쉬워야 합니다. 둘째, 어투에 조심합니다. 특히 예시를 든 것처럼 사용자들의 ‘돈’과 관련된 기능의 경우 건조한 어조로 쓰는 것이 낫습니다.
배포 이전에 공지부터 업로드하는 경우도 있습니다. 공지사항을 통해 사용자들의 반응을 관찰할 수 있기 때문입니다. 예를 들어 [배달 기사 레벨 시스템]을 공지할 경우 각종 커뮤니티에서 기능에 대한 긍정/부정 의견이 올라올 수 있습니다. PM은 사용자의 목소리를 세세하게 관찰하고 배포가 어떤 방향으로 흘러갈지 예측한 뒤 대비할 수 있습니다.
4. 유관부서 검토
유관부서로부터 확인을 받아야 합니다.
특히 CX / PR / 대외협력처럼 제품 배포 후 사용자들의 피드백을 정면으로 받는 부서들이 세부사항까지 알고 있어야 합니다. 필요할 경우 법무검토까지 받아 사고에 대비합니다. 이들 부서는 회사 외부자의 시각에서 새로운 기능의 부작용에 대해 강한 반대 의견을 내줍니다. PM입장에서는 번거로울 수 있지만 아픈 예방주사와 같다고 보면 됩니다.
예를 들어 [배달 기사 레벨 시스템]을 도입한다고 할 경우, PR팀에서는 ‘기사님들을 등급화하는 것은 차별입니다’라며 반대의견을 낼 수 있고, CX에서는 ‘레벨이 너무 복잡해서 이해하기 어렵습니다’라며 개선을 요청할 수 있습니다. 사내 레드팀의 역할을 존중하고 이들의 목소리를 수용할 때 안정적인 배포가 가능합니다. 이들을 외면하면 기껏 힘들게 만든 프로젝트가 전면 백지화 될 수 있습니다.
5. 큐시트 작성
배포 큐시트(순서)를 작성합니다.
IT제품의 배포는 버튼 하나 딸깍하면 될 것 같지만 의외로 꽤 많은 절차가 필요합니다. 여러 부서가 순서에 맞게 진행합니다. 특히 복잡한 기능을 배포할 경우 순서가 꼬이는 것이 큰 사고로 이어집니다. PM은 각 부서의 담당자들이 자기가 전담한 기능 배포에만 집중할 수 있도록 큐시트를 만들고 공표합니다. 아래와 같은 형태입니다.
[배달 기사 레벨 시스템 배포 큐시트]
1단계 : 계정 서버 배포 (5월 20일 오후 1시)
2단계 : 버티컬 서버 배포 (5월 20일 오후 2시)
3단계 : 관리자 템플릿 등록 (5월 20일 오후 2시 5분)
4단계 : 버티컬 클라이언트 배포 (5월 20일 오후 2시 10분)
5단계 : 프로모션 페이지 오픈 (5월 20일 오후 2시 15분)
6단계 : 공지사항 페이지 오픈 (5월 20일 오후 2시 15분)
큐시트를 만들어두면 배포 중간에 사고가 나더라도 빠르게 중단할 수 있습니다. 배포 시에는 PM이 앞단계가 완료된 것을 확인하면 뒷단계로 넘어갑니다. 중간에 사고가 나서 중단했다면 뒷단계 동료들에게 신속히 전파합니다.
6. 사내 공지
PM은 배포 후 제품의 대표로서 배포 사항을 사내에 적극적으로 전파합니다.
사내 공지는 아래 내용을 담고 있으면 됩니다.
배포 주제
배포 내용 요약 (1줄 이내)
배포 목적(기대 효과)
제품을 만든 사람들
앞으로 관찰할 방향
[배달 기사 레벨 시스템]을 예시로 들면 아래와 같이 작성합니다.
경축 [배달 기사 레벨 시스템] 배포
이제 기사님들이 레벨에 따라 더 많은 보상을 받을 수 있습니다.
더 많은 기사님들이 우리 플랫폼에만 집중해도
충분한 업무 환경을 제공합니다.
하루 10건 이상 배달하는 핵심 기사님들을
현재 일 50,000명 수준에서
향후 일 80,000명 수준으로
끌어올리려 합니다.
서비스 기반 튼튼하게 만들어주시는 AA, BB, CC ….
(중략) 살뜰하게 QA 해주신 DD, EE, FF 감사합니다.
앞으로 고객에게는 더 안정적인 배달 품질을,
기사님들에게는 더 많은 수익을 전달할 수 있도록
일단위로 향후 2달 동안
꾸준히 체크하며 튜닝하겠습니다.
사내공지에는 2가지 목적이 있습니다. 하나는 최대한 많은 동료들에게 변화를 알리는 목적입니다. 이 단계에서 배포 중 실수나 다음 단계 업무의 실마리가 빠르게 발견되기도 합니다. 다른 하나는 구성원들의 사기를 진작하는 목적입니다. 동료들이 업무에 효능감을 느낄 수 있도록 소위 ‘샤라웃’해주는 것도 중요합니다.
7. 지표 확인 후 튜닝
배포 후 일단위로 지표를 공개하고 튜닝합니다.
배포에 대한 사내공지가 이루어지면 동료들이 성과를 궁금해합니다. PM은 바로 다음날부터 미리 세팅해 둔 지표를 투명하게 공개하고 추적해야 합니다. (설령 지표가 안 좋더라도 그대로 공개합니다.) 지표가 생각해 둔 시나리오 안에 있는지, 앞으로 어떻게 대응할 것인지도 알립니다. 모든 상황을 예상했다는 듯 행동하면 동료들이 안정감을 느낍니다.
지표 공유는 서비스가 의도한 대로 정착할 때까지 계속됩니다. 처음 2-3일은 PM이 출근 직후 전날 지표를 공개하고 코멘트하며, 이후에는 일주일 단위로 체크합니다. 이 과정을 거치면 프로젝트 회고(Retrospective)를 위해 따로 준비할 것도 없습니다. 매일 단위로 관찰한 일지를 종합하여 3주 뒤 회고자료를 준비합니다. (회고에 대해서는 다음 챕터에 다루겠습니다.)
이상 7단계를 거쳐 합리적인 배포가 이루어집니다.
아무리 잘 만든 드라마도 결말이 이상하면 졸작이 됩니다. 배포도 마찬가지입니다. 동료들이 프로젝트를 완성했다면 이때부터 PM의 임무는 제품이 이륙할 때까지 관찰하고 조율하는 것입니다. 시장으로 날아오른 제품이 사용자들에게 비로소 인정받는 순간 PM은 그제야 시선을 동료들에게 돌리고 프로젝트의 회고를 준비할 수 있습니다.
cc. yve.atelier