신입 PM 첫 1년 생존기 - (2)
프로덕트 매니저로 커리어 전환 경험담
기획 - 디자인 - 퍼블리싱 - 개발 - QA - 배포 - 모니터링
PM의 업무 플로우는 보통 이렇게 이루어져있다.
기획
1. 대부분의 회사가 그렇겠지만 보통 유관부서에서 요청이 온다. “기획전을 더 편하게 등록하고 싶어요. 등록하는 데 워크 로드가 너무 많이 심해요.“ 그렇게 프로젝트가 시작된다.
2. 유저 인터뷰를 해서 어떤 점이 문제인지 파악해야 한다. 이 때 가장 어려운 것은 ① 나는 저 업무를 해본 적이 없어서 무엇이 이슈인지 이해하기 어렵고 ② 요청자도 무엇을 원하는 지 정확히 모른다!! 말로는 A를 요청했지만 실제로 원하는 건 B 였던 경우가 많다. 문제가 무엇인지 정의를 잘 해야 잘못된 길로 빠지지 않고 “진짜 문제”를 풀 수 있다. 구체적으로 질문을 해야 구체적인 대답을 얻을 수 있다. 어떤 상황에서 사용 하는 지, 목적은 무엇인 지, KPI는 무엇인 지 등 사용하는 단계를 구체적으로 이해해야 한다.
3. 기획전 등록하는 데 시간이 오래 걸리는 이유가 여러가지라고 하자: ① 세팅 할 게 많다 ② 디자인 및 퍼블이 오래 걸린다 ③ 구조가 복잡하게 되어있다. 이 중에 어떤 문제를 해결할 것인가? 어떤 것이 가장 시급한지, 혹은 가장 빠르게 해결할 수 있을 지, 혹은 수정했을 때 파급력이 클 지 등을 고려해서 우선순위를 정한다. 구조를 바꾸는 것은 아주 큰 일이기 때문에 제일 후순위로 진행할 수 도 있으나, 반대로 구조를 바꾼 다음에 다른 것을 개선하자고 방향을 잡을 수도 있다.
4. 세팅 할 게 많다는 것을 문제로 잡았다고 하자. 그러면 이것을 어떻게 해결할 것인가? 방법은 여러가지가 있다. ① 기획전 템플릿을 만들어서 불러오게 할 수도 있고 ② 기획전 세팅을 자동화 할 수도 있다. 이 중에 현재의 서비스 구조와 가장 잘 맞는 것이 어떤 것이며, 문제를 해결하는 데 가장 도움이 될 것인 지, 추후 추가 개선을 진행한다고 할 때 이슈가 없는 지 (확장성) 등을 고민하여 방향성을 결정한다.
5. 큰 정책을 정리한 다음, 세부적인 사항을 정의한다. 사내 직원이 사용하는 어드민 화면이나 고객이 접하는 플랫폼의 인터랙션을 구체적으로 기획한다. 데이터를 어떻게 저장할 것이고, 어디에 있는 데이터를 사용하여 노출할 것인지도 정의 해야한다. 이에 대해서는 나중에 더 구체적으로 이야기하고자 한다.
디자인
1. 이렇게 기획이 끝났으면 디자인이 필요하다. 사내 직원이 사용하는 어드민 화면은 기능에 초점을 두기에 보통 디자인을 하지 않는다. 다만 고객이 보는 화면은 서비스의 품질에 매우매우 중요한 역할을 하기에 디자인을 꼭 한다.
2. 디자이너에게 요청을 할 때는 꼭 필요한 컴포넌트를 위주로 설명하는 것이 좋다. ‘고객이 클릭할 수 있도록 Call To Action 버튼을 추가해주세요,' '8자 정도의 문구가 들어갈 거에요. (문구 예시 함께 전달),' '요소 중 버튼이 가장 눈에 잘 띄었으면 좋겠어요,‘ ’원 뷰에 버튼이 들어와야 해요‘ 와 같이 기능이나 flow에 필수적인 영역을 위주로 이야기하면 UX/UI 디자이너가 더 궁금한 것을 물어보고 초안 작업을 해 줄 것이다.
퍼블리싱
1. 디자인이 영역에 맞게 노출되거나 특정한 액션을 하기 위해서는 퍼블리셔의 작업이 필요하다.
① HTML (HyperText Markup Language)는 웹페이지의 구조를 나타낸다. 예를 들어 <h1> 태그는 제목을, <p> 태그는 문단을 의미한다.
② CSS (Cascading Style Sheets)는 색상, 글꼴, 레이아웃, 여백 등 시각적인 요소를 더해준다. 예를 들어 font-size: 21pt는 글씨 크기를 21pt로 바꿔주고, color:blue 텍스트를 파란색으로 변경해준다.
F12를 눌르면 현재 페이지의 HTML과 CSS 영역을 볼 수 있다.
2. 처음에는 퍼블이 필요한 영역과 필요 없는 영역을 알기가 어려웠다. 그럴 경우 디자이너, 퍼블리셔, 개발자에게 물어봐서 확인하는 게 가장 정확하다.
개발
1. 개발에 들어가기 전에 디자인과 퍼블리싱 작업이 끝나있어야 한다. 그러나 개발 중 수정사항이 있어 필요하다면 개발 중 디자인과 퍼블리싱을 다시 작업하기도 한다.
2. 기획을 하는 과정에서 궁금한 것이 있으면 개발에게 문의를 한다. 현황 파악을 요청하기도 하고, 초안을 들고 가 가능할 지를 논의하기도 한다. 최종적으로 개발에 들어가기 전에 개발자들과 기획 리뷰를 진행한다. 나는 이 순간이 아직 무서운데(덜덜) 내 기획서를 상세하게 설명하면 개발이 날카로운 질문을 한다. 분명 엄청 구체적으로 적었다고 생각했는데 미흡한 부분이 있거나, 아니면 구조적으로 불가한 경우에는 다시 논의를 하게 된다. 기획 리뷰 후 기획서가 업데이트 되면 개발 일정을 잡고 개발에 들어간다.
3. 완벽한 기획서는 없다. 개발 중에 개발자들의 질의 사항에 따라 업데이트 하기도 하고, QA 중에 변경되기도 한다. 따라서 변경 사항을 버전에 맞게 꾸준히 업데이트 해줘야 한다.
4. 대부분의 서비스는 웹과 앱을 혼합해서 사용하고 있다. 어느 영역이 웹인지는 개발자들에게 물어보는 게 정확하다.
QA
1. 내가 기획한 대로 개발이 되었는 지 확인이 필요하다. 간단한 것은 기획자가 하기도 하지만, 큰 프로젝트 같은 경우에는 QA와 함께 테스트를 진행한다. QA와 함께 하는 경우 별도로 리뷰를 진행해서 어떤 것을 체크해야 하고, 어떤 부분을 특별히 유심히 보아야 하는 지 전달한다.
2. QA는 가장 꼼꼼해야 하는 업무인 것 같다. 기본적으로 정의된 기획 요소가 존재하는 지 확인하고, 정상적으로 작동하는 지 확인한다. 유저가 서비스를 어떻게 사용할 지 알 수 없기 떄문에 정상적이지 않은(?) 예외 케이스까지 테스트 하는 것이 좋다. 또한 같은 기획전 페이지이더라도 PC, mWeb, App에서 다 작동하는 지 확인해야한다. 보통 Test Case를 작성하고 그에 따라 테스트를 진행한다. QA가 테스트 하는 경우 Test Case를 기획이 보고 피드백을 주기도 한다.
3. QA를 하는 데 가장 어려운 건 세팅인 것 같다. 가장 오래 걸리기도 하고 복잡하다. ‘구매 이력이 있는 회원 번호’가 필요하다고 할 때 직접 테스트 환경에서 계정으로 로그인하여 구매 이력을 만들 수도 있고, 개발자에게 DB 보정을 요청할 수도 있다. 어떻게 하면 세팅을 최소화하면서 모든 케이스를 확인할 수 있을 지 머리를 써야한다.
배포
1. 여태까지는 테스트 환경에서 서비스가 잘 작동했는 지를 확인한 것이다. 실제 운영에 배포해야 고객들에게 서비스기 오픈된다. (두근두근) 운영에 배포할 때에도 한 번 더 간단하게 테스트를 진행하는데 이 때는 약식으로만 진행하고 운영 후 모니터링을 한다.
2. 웹 사이트 배포와 앱 배포가 있다. 웹사이트는 배포하는 즉시 반영되며, 필요 시 언제든 수정 및 재배포가 가능하다. 어떤 유저가 들어오던 동일한 버전의 웹사이트로 유입된다. 반면 앱은 구글 플레이 스토어(aos) 혹은 애플 앱 스토어(ios)에 등록 후 심사를 받아야 해서 배포가 훨씬 까다롭다. 앱을 배포하더라도 사용자가 직접 다운로드하거나 업데이트 하지 않으면 이전 버전으로 계속 노출된다. 여러 버전을 혼재하여 사용하기에 이전 버전에 대한 호환성 유지와 관리가 필요하다.
참고로 앱 스토어에 들어가면 앱 버전 기록과 업데이트 내역을 확인할 수 있다.
모니터링
1. 테스트 환경에서도 운영 환경에서도 QA를 했으나, 서비스를 오픈한 후에 미처 확인 못한 이슈가 종종 튀어나온다! 따라서 운영 배포 이후에는 수시로 모니터링을 하면서 추가 결함을 발견하고 수정해나간다. 특히 규모가 큰 프로젝트라면 결함 및 이슈 해결을 하나의 프로젝트처럼 진행하기도 한다. 긴급도에 따라서 바로 수정 배포하는 경우도 있고 운영하며 해결해 나가는 경우도 있다.
2. 개발 혹은 QA 중에 이슈를 발견했더라도 그냥 배포를 하는 경우가 있다. 배포 오픈 일이 고정되어 있거나 결함이 크지 않은 경우에는 배포 후 추가로 개발을 진행하기도 한다.
처음에는 업무 프로세스가 한 눈에 들어오지 않아 더 헷갈렸는데. 조금이나마 궁금증을 해소해줄 수 있으면 좋겠다. 물론 회사마다 업무 방식이 모두 달라서 이게 정답이라고는 절.대. 말 할 수 없다. 다음에는 조금 더 구체적으로 그래서 어떻게 기획을 하는 지 이야기하고자 한다.
