PM 성장기 - 2022년 9월호
월간 성장기를 작성한다고 해놓고 이런 저런 일로 7개월만에 성장기를 쓰게 되었다...ㅎㅎ 반성 또 반성
오랜만에 글을 작성하는 터라 그간 있었던 일과 성장한 것들을 능축해서 적어보고자 한다.
6개월간 하던 프로젝트가 끝났다.
이렇게까지 길어질 일은 아니었으나 기획을 진행하는 과정에서 목표의 변경이 자주 일어나면서 기획의 변경이 잦아지면서 많은 시간이 소요되었고 프로젝트 마지막에는 수많은 스펙아웃이 일어났다.
대규모 프로젝트든, 소규모 프로젝트든
프로젝트의 목표는 무엇인지 어떤 지표를 볼 것인지 명확하게 잡고 가야한다는 걸 뼈저리게 느꼈다.
무엇보다 큰 규모의 프로젝트를 진행하면서 대략적인 기능들을 정리하고 전달하는 법, 일정을 관리하는 법, 촉박한 일정에도 프로덕트의 완성도를 높이는 방법을 배웠다.
촉박한 일정으로 QA가 중단 되었다.
QA 일정과 함께 개발이 이루어지면서 QA 원활하게 되지 않았다. 결국은 QA를 중단하고 개발 완성도를 높이기로 했다. 알바생분들을 고용하면서 QA를 진행했었는데 개발이 덜 되어 QA를 진행할 수 없었으니 리소스가 낭비 되어 아쉬웠다.
PM이 TC를 쓰면서 배우게 된 것
뜻하지 않게 TC를 쓰게 되었다. 처음에는 QA 매니저도 있는데 PM이 왜 TC까지 써야 하나 답답했지만 오히려 배울 수 있는 것이 많았다.
1. CASE 정의 - 같은 화면이더라도 케이스 별로 보이는 것이 다 다르다. 무작정 화면을 그리기보다는 어떤 케이스가 있을지 정의하는 것이 중요하다는 것을 알게 되었다.
2. 기획서에서 놓친 부분을 채우기 - 유저가 되어 플로우를 상상하면서 TC를 작성하였다. 기획서에서 정의 되지 않았던 화면 이동, 정책을 발견할 수 있었다.
3. 특수 케이스를 효율적으로 QA 할 수 있는 방법 - 특수한 케이스를 확인하기 위해 조건을 셋팅하는 것이 어려웠다. 바로 확인하기 어려워 개발자가 데이터를 변경해주어야 하는 경우도 많았기 때문에 특수 케이스를 따로 정리해 개발자들에게 이슈를 전달하는 방법을 효율화 할 수 있었다.
4. 버그리포트를 효율적으로 관리하는 방법 - 대규모 업데이트를 진행했기 때문에 QA를 도와줄 알바생들을 고용했다. 버그를 발견하면 QA매니저와 PM에게 전달하는 방식, 그리고 그걸 jira 티켓으로 생성하여 개발자에게 전달하는 방식을 효율화 할 수 있었다.
테스트 케이스 별로 ID를 정리하고 vlookup 함수를 사용하여
버그를 리포트하면 자동으로 재현방법, 기대효과가 딸려오게 하여 jira 티켓을 생성할 때 굳이 기획서를 찾아보지 않아도 되게 했다.
DATA TAXONOMY를 처음부터 정의할 수 있었다.
기존 버전의 앱에 지표가 없었기 때문에 Amplitude, Braze, Appsflyer 지표를 처음부터 설계하고 지표 체계를 만들었다. 특히 같은 화면이지만 상태값이 다른 경우, 같은 버튼이지만 화면이 다른 경우가 많았기 때문에 다른 사람들도 쉽게 어떤 화면의 어떤 버튼인지를 인지할 수 있도록 네이밍 컨벤션을 정리했다.
불필요한 지표를 넣지 않기 위해 이게 정말 필요한 지표인지 무엇을 보고 싶은 건지 정리하며 지표를 기획했다.
스펙아웃 된 건들을 효율적으로 관리할 수 있었다.
일정이 촉박하다보면 스펙아웃이 잦게 일어나고, 어떤 이유로 스펙아웃 됐는지, 심하게는 어떤 게 스펙아웃이 되었는지를 잊게 된다. 따라서 스펙아웃 된 건들을 따로 작성하였고 배포가 끝나고 차례차례 개발을 진행하였다.
배포 후 주요 지표와 VOC를 관리하였다.
대시보드를 만들어서 우리 프로젝트에 가장 중요한 지표인 업데이트율(강제 업데이트가 없었다 ㅜ)과 발송률응 확인했다. 다른 팀원들도 성과를 공유할 수 있도록 하였다.
그 외에 버그나 유저 보이스를 효율적으로 수집하기 위하여 세일즈, 오퍼레이션 분들이 쉽게 전달하고 쉽게 아카이빙할 수 있는 구조를 만들었다.
slack 워크플로우 빌더를 이용하여 슬랙에 버그 내용을 올리면 자동으로 스프레드 시트에 공유 되어 jira 티켓과 연결하여 관리할 수 있도록 했다.
