10년 차 PO가 알려주는 프로젝트 선정부터 배포까지

본인이 속한 조직에서 서비스나 도메인을 담당하는 PO가 되면 자연스럽게 많은 프로젝트를 선정하고 배포하게 된다. 여기서 프로젝트란 기업마다 부르는 명칭이 다를 수도 있지만, 보통 현재 발생하고 있는 문제를 해결할 수 있거나 서비스를 성장시킬 수 있는 과제를 의미한다.

예를 들어, 커머스에서 고객의 객단가가 너무 낮다는 문제가 있다면 이를 개선하기 위해, 1) 크로스셀링 2) 업셀링 3) 주력 상품 변경 등 다양한 아이디어를 도출할 수 있다. 여기서 도출된 각각의 아이디어가 하나의 프로젝트가 된다. 이처럼 프로젝트는 거창하거나 대단한 기능만을 의미하는 것이 아니라 작은 단위의 기능 배포도 포함하는 개념이다.

이번 글에서는 이러한 프로젝트를 어떻게 발견하는지, 진행 여부 결정과 고객에게 배포하게 되는 일련의 과정을 세세하게 설명하려고 한다. 현직에 있는 많은 PO들은 이 과정이 익숙하겠지만, 이제 막 시작한 주니어 PO나 프로젝트를 아직 진행해 보지 못한 기획자라면 늘 첫 시작이 어려운 법이다. 이 글을 통해 프로젝트 과정을 미리 이해하고 활용할 수 있길 바란다.

프로젝트 발굴 TIP

맨 처음 도메인을 담당하게 되면 이를 어떻게 성장시킬지에 대한 고민이 시작된다. 첫 단추로 도메인을 성장시키기 위해 필요한 방향성과 전략을 정의했다면, 이제 우리의 방향성에 맞는 프로젝트를 발굴해야 한다. 내가 프로젝트를 발굴하는 방법은 1) 백로그(Backlog) 2) VoC(Voice of Customer) 분석 3) 데이터 분석 4) 아이데이션(Ideation) 등이 있다.

1) 백로그(Backlog)

신규 도메인이라면 아직 백로그가 없겠지만, 기존에 있던 도메인을 담당한 경우라면 아직 진행하지 못한 요구사항이나 아이디어가 정리된 백로그(개발 계획을 수립했지만 우선순위가 밀려 개발을 보류한 시스템)가 있을 것이다. 우선 백로그에서 방향성에 적합한 기존 요구사항, 아이디어가 있는지부터 살펴보자. 그리고 진행해도 좋을 만한 프로젝트가 있다면 체크해 놓는다.

2) VoC(Voice of Customer) 분석

다음은 VoC를 통한 프로젝트 발굴이다. VoC는 매일 보는 것이 좋다. 수시로 보면서 고객의 목소리를 들어야 한다. 이 과정에서 우리는 고객이 어떤 불편함을 느끼는지, 어떤 기능을 필요로 하는지 파악할 수 있다. 이렇게 파악한 내용을 별도 문서에 정리하고, 진행 프로젝트 선정 시 함께 검토해야 한다.

3) 데이터 분석

PO가 가장 많은 시간을 투자하는 부분이 바로 데이터 분석일 것이다. 다양한 유저 데이터를 분석하다 보면 많은 가설과 아이디어가 나온다. 이러한 부분은 따로 백로그나 별도 문서에 저장해 두는데, 바로 검증할 수 있는 가설이면 당장 시도해보는 것이 좋다. 바로 실행하기 어렵다면 문서로 남겨둔 후, 프로젝트 선정 시 이 문서를 함께 검토한다.

4) 아이데이션(Ideation)

아이데이션은 아이디어를 얻기 위해 하는 모든 활동을 말한다. 방법은 다양하다. 타사 벤치마킹을 하거나, 리서치할 수도 있고, 팀원들과 아이데이션 미팅을 진행할 수도 있다. 이 과정에서 다양한 의견 도출되는데, 이를 목록화하여 프로젝트 진행 시 검토한다.

위 4가지 방법을 통해 정리해 둔 요구사항, 아이디어, 다양한 기능들을 각각의 문서에 정리해도 상관없지만, 나는 하나의 문서로 관리하고 있다. 그리고 이 문서에는 프로젝트명, 배경, 목적, 기대 효과(정량, 정성), 작성자, 작성일자 등을 포함한다. 이렇게 해야 추후 프로젝트 선정 시 빠르게 내용을 확인하고 의사결정을 내릴 수 있기 때문이다.

프로젝트 진행 여부 및 우선순위 선정

앞서 설명한 방법으로 요구사항과 아이디어를 정리해 두었다면, 이제 프로젝트 진행 여부와 우선순위를 정하는 단계다. 이 과정에서 첫 번째로 ‘우리의 방향성과 잘 연결되는지’ 확인하는 것이 필요하다. 이는 PO의 생각에 따라 방향성이 달라질 수 있으므로, ‘우리가 가고자 하는 방향성’이 무엇인지 잘 정의되어 있어야 한다. 방향성을 잘 정의했다면 정리된 프로젝트를 살펴보고, 우리 방향성에 맞는 프로젝트 위주로 진행 여부를 체크한다.

이 과정에서 어떻게 체크해야 하는지는 각 기업의 프로세스에 따라 다르겠지만, 개인적 경험에 의하면 아래와 같은 순서로 결정하고 있다.

• PO가 1차 진행 여부를 결정
• 내부 공유(동료 PO 또는 상사)
• 개발 리소스 확인
• PO 2차 검토
• 이해관계자, 팀원들에게 공유
• 최종 확정

우선 PO의 판단하에 진행 프로젝트를 결정하고 위 단계를 걸쳐 확인 후, 최종 진행 여부를 확정한다. 최종 진행 여부를 결정했다면 다음으로 프로젝트의 우선순위를 결정한다. 이 과정도 프로젝트 진행 여부 결정과 거의 유사한데, 여기서 좀 더 고려해야 할 부분이 있다.

• 도메인 방향성과 얼라인(Align) 여부
• 프로젝트 기대효과(=얼마나 임팩트가 있는지)
• 프로젝트 당 리소스
• 리소스 대비 임팩트
• 이해관계자가 생각하는 중요성, 시급성

위 5가지 사항은 프로젝트 진행 여부 확정 시에도 동일하게 검토한다. 우선순위 선정 시 가장 고려해야 하는 부분은 ‘리소스 대비 임팩트’와 ‘이해관계자가 생각하는 중요성, 시급성’이다. 이유는 ‘리소스 대비 임팩트’가 큰 프로젝트를 먼저 진행해야 빠르게 성과를 내고, 결과에 따라 진행 프로젝트의 순서도 변경할 수 있기 때문이다.

또한 ‘이해관계자가 생각하는 중요성, 시급성’이 중요한 이유는 이미 원하는 배포 일정이 확정되어 있을 수 있기 때문이다. 예를 들어, 마케팅팀에서 요청한 프로젝트가 있는데 이 프로젝트 진행 시 필요한 광고나 제휴사와의 계약이 체결되어 있을 수도 있다. 그렇다면 광고 일정에 맞게 프로젝트도 정상 배포되어야 한다는 뜻이다. 이러한 부분까지 고려하여 우선순위를 선정하고, 프로젝트 진행 시기를 확정하는 것이 좋다.

기획서 작성

기업에 따라 ‘PRD(제품 요구사항 정의서)’ 등 다양한 용어로 불리지만, 이 글에선 기획서로 설명하겠다. 프로젝트를 선정하고 우선순위까지 결정되었다면 이제 프로젝트를 착수하게 된다.

프로젝트가 시작되면 가장 먼저 PO가 기획서를 작성하는데, 이 기획서에는 프로젝트를 하게 된 배경, 목적, 기대 효과, 가설, 성공 지표 등을 정의하고 기능적 요구사항을 세세하게 작성한다. 기대효과는 되도록 정량적으로 작성하되, 정량적인 수치가 없다면 정성적으로 기재해도 무방하다. 이러한 내용을 포함해 기획서를 작성한 다음 팀원들과 이해관계자들에게 리뷰를 진행한다.

디자인 및 개발 진행

기획서 리뷰를 통해 팀원들과 이해관계자들의 피드백을 반영 후 기획서를 최종 보완한다. 그다음 디자이너가 UI, UX 디자인을 진행하고, 개발 가이드를 만들어 개발팀에 공유한다.

물론 개발팀에 가이드를 전달하기 전, PO와 시안에 대해 충분히 논의하고 합의하는 과정이 필요하다. 종종 개발 리소스가 큰 프로젝트의 경우, 신중한 선택을 위해 기획서 리뷰 후 유저 리서치를 진행하기도 하고, A/B 테스트로 일부 가설을 검증한 후 실행에 옮기기도 한다. 이 부분은 기업, 팀, 프로젝트의 중요도에 따라 각 PO가 진행 여부를 판단하게 된다. 이제 개발자들은 디자인된 프로젝트를 가이드와 주요 정책을 고려해 개발에 착수한다.

QA

기업마다 QA팀이 따로 있는 경우도, 없는 경우도 있는데 나는 주로 QA팀과 협업을 진행했다. QA팀에선 기획서에 정의된 세부적인 기능과 정책 위주로 TC(Test Case)를 작성하고, TC에 맞게 우리 도메인 고객들이 주로 사용하는 기기, 브라우저에서 테스트를 수행한다.

개발 완료 전, QA팀에 협업을 요청하고 예상 배포 일정을 공유한다. 배포 일정 전에 테스트 지원 여부를 확인해야 하기 때문이다. 가능하다는 답변이 오면 QA 일정을 고려하여 배포 일정을 확정한다. 확정된 배포 일정에 맞춰 개발 완료 후 내부 테스트를 먼저 하고, 이후 QA팀에서 최종 테스트를 진행한다.

생각보다 테스트를 중요하지 않게 생각하거나, 대충 하는 경우도 있는데 배포 전 테스트는 정말 중요한 부분이다. 사용자에게 신규 기능을 배포했는데 배포 전보다 불편하거나, 오류가 발생한다면 많은 고객이 이탈할 수도 있기 때문이다. QA팀에선 정리된 세부 기능에 대한 최종 검증, 고객 입장에서의 전반적인 테스트를 하고, 결과에 대한 Sign-Off 신호를 보낸다. 드디어 고객에게 배포 가능한 상태가 되었다는 뜻이다.

운영 배포 및 모니터링

대망의 배포일! QA팀의 최종 확인이 끝났으니 일정에 맞게 배포하면 된다. 개발자가 실제 운영 서버에 배포되었다는 피드백을 주면 실제 서비스에 정상 배포가 되었는지, 웹, 앱(iOS, Android) 모두 꼼꼼하게 기능을 확인한다. 이상이 없다면 전사 공지를 통해 우리 서비스에 어떤 기능이 배포되었는지를 알린다.

이렇게 운영 서버에 배포하고 나면 한시름 놓게 되는데 사실 끝난 게 끝이 아니다. 배포된 기능을 우리가 기대했던 대로 고객이 잘 사용하는지, 고려하지 못한 부분은 없는지, 고객이 불편함을 느끼는 부분은 없는지 등 여러 데이터를 통해 모니터링한다. 이후 약 2주에서 4주가 지나면 성과분석을 통해, 프로젝트의 성패를 판단하고 문제가 있다면 해결을 위한 실행방안(Action Item)을 수행한다.

마치며

지금까지 프로젝트 발굴부터 진행 여부, 우선순위 판단, 기획서 작성, 프로젝트 착수 및 개발, QA, 배포까지 각 순서에 따라 어떻게 진행되는지 알아보았다. 진행되는 단계나 순서는 기업 내 가이드나 담당 PO의 스타일에 따라 다를 수 있으나, 대체로 비슷한 방식으로 진행된다. PO로 프로젝트를 진행하게 됐을 때, 이러한 프로세스를 참고하여 배포까지 차근차근 진행해 보길 바란다. 무엇이든 처음이 어려울 뿐, 하다 보면 익숙해져 과정도 자연스러워진다. 마지막으로 프로젝트 진행 순서에 따라 중요한 부분을 한 번 더 정리하며 글을 마친다.

1. 프로젝트 발굴

• 백로그, VoC, 데이터 분석, 아이데이션을 통해 발굴할 수 있다.
• 프로젝트 발굴 및 요청은 PO, 팀원, 이해관계자 등 누구나 가능하다.

2. 진행 여부, 우선순위 선정

• 진행 여부와 우선순위는 담당 PO가 1차로 검토하고 이후 내부 공유한다.
• 이 과정에서 각 프로젝트의 중요성과 시급성, 투입되는 개발 리소스, 리소스 대비 임팩트를 고려하여 진행 여부와 우선순위를 선정한다.

3. 기획서 작성

• 각 기업에 따라 부르는 용어나 작성해야 하는 문서가 기획서, PRD 등으로 다를 수 있으나 이 글에선 기획서로 정의했다. 기획서에는 배경, 목적, 기대효과, 가설, 성공 지표, 기능적 요구사항 등을 적는다. 기획서에 포함되는 항목도 기업이나 팀, PO 스타일에 따라 다를 순 있지만 대체로 위 내용은 포함하여 적는 것이 추후 성과분석 후 성패 판단 시에도 유용하다.
• 기획서 작성 후 팀원과 이해관계자에게 리뷰하여 최종 보완한다.

4. 디자인 및 개발 진행

• 이후 최종 정의된 기획서에 맞게 디자인이 나오면 개발을 착수한다.
• 개발에선 디자인 가이드, 기획서에 정의된 정책에 맞게 요건에 맞게 기능을 개발한다.

5. QA

• 고객에게 배포하기 바로 전 단계로 가장 중요하다. QA팀에선 기획서와 디자인 가이드를 확인하여 최종 테스트를 진행하고, Sign-Off 신호를 보내준다.
• Sign-Off 신호를 받으면 배포 준비가 완료된 것이다.

6. 운영 배포 및 모니터링

• 개발자에게 요청해 운영 서버에 배포하는 단계다. 준비한 프로젝트를 고객에게 선보이는 날로, 운영 서버 배포가 완료되면 제공하고 있는 플랫폼 종류(웹, 앱)에 따라 라이브 모니터링을 실시한다.
• 이후 주요하게 봐야 하는 지표를 꾸준히 모니터링하고, 배포 후 2주~4주가 됐을 때 전반적인 성과 분석을 진행하여 전사에 공유한다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.