주변 개발자와 디자이너들을 보면, 대부분 실무에 가까운 경험을 쌓기 위해 많은 노력을 기울이고 있다. 개발자는 테스트 코드 작성과 리팩토링을 통해 코드의 품질을 높이고, 디자이너는 사용성을 고려한 디자인 시스템을 구축하며 효율적인 디자인을 위해 힘쓴다.
그렇다면 대학생 PM은 어떻게 실무에 가까운 경험을 쌓아갈 수 있을까?
나는 지난 겨울방학 프로젝트 이후 팀원들과 함께 사이드 프로젝트를 이어가며 여러 방법들을 직접 활용해보았고, 이번 글에서 그 경험을 공유해보려 한다!
1. PRD, 기능명세서 그리고 화면명세서
우선 PRD(Product Requirements Document)는 제품에 반영되어야 할 요구 사항을 담은 가이드라고 할 수 있다. 구글의 프로덕트 매니저인 Omar Eduardo는 2020년에 PRD 작성법에 대한 블로그 글을 발행했다. 이 글에서는 요구 사항의 "WHY"를 기반으로 문서를 작성하는 방법을 강조하며, 구성요소는 아래와 같다.
PRD의 7가지 구성 요소
- 제품 개요
제품의 목적과 문제를 요약하며, 설문조사, 지표 등의 데이터로 필요성을 뒷받침한다. - 비즈니스 목표 및 지표
제품 개발의 비즈니스 목적과 기대 성과, 주요 지표(KPI)를 제시해 목표를 명확히 한다. - 핵심 고객 정의
제품을 사용할 주요 사용자 그룹과 그들의 문제를 명확히 정의한다. - 핵심 사용자 여정 및 유저 스토리
제품이 사용자 요구를 충족하는 과정을 정의하고, 유저 스토리로 구체적인 사용 시나리오를 표현한다. - 기능적 요구 사항
필수 기능을 Must/Should/Could Have로 구분해 우선순위를 정하며, 팀원과 협업하여 정의한다. - 프로젝트 일정 및 배포 계획
출시 일정과 팀 간 협업 일정을 설정한다. - 기타 참고 문서
와이어프레임, UX 리서치, 참고 자료 등을 첨부해 개발 참고 자료로 활용한다.
유저 스토리는 특히 사용자 중심으로 기능을 설계하고 개발하는 데 유용하여, 서비스 품질을 크게 향상시킬 수 있다고 한다.
여러 요소를 포함하면 의사소통이 더 원활해지는 것은 맞지만, 단기간에 진행하는 프로젝트의 경우 세부 기획을 빠르게 마쳐야 하기 때문에 난 기능만을 구체적으로 정의한 기능명세서를 주로 활용한다.
마지막으로 화면명세서는 내가 만들어낸 용어지만 꽤 직관적이라고 생각한다.
비슷한 용어로 화면설계서(Wireframe)가 있다. 화면설계서는 개발을 시작하기 전에 서비스의 기본 구조와 레이아웃을 시각적으로 표현하여, 각 화면의 기능과 구성 요소를 직관적으로 이해할 수 있도록 돕는 문서이다.
반면에 화면명세서는 디자인이 완료된 이후, 최종 화면을 기준으로 로직을 세분화하고 시각적으로 전달하는 역할을 한다.
제일 중요한 것은 기획자가 생각한 화면의 전환, 각 버튼의 상태 값들, 각 화면이 가질 수 있는 "모든" 상태 값을 쓰는 것이다. 즉, 각 화면에서 나올 수 있는 모든 케이스를 정리하는 것이다.
실제로 프로젝트에서 화면명세서를 이용해보니, 개발자들의 질문이 이전해 비해 많이 줄어들었다. 또한, 기획자인 나도 이를 통해 예외 처리를 다시 한번 검토할 수 있어 기획을 더 탄탄하게 다지는 계기가 되었다고 생각한다!
2. QA
QA는 Quality Assurance의 약자로서 '품질보증'이라는 뜻을 가지고 있다.
QA는 단순 기능 체크만 하는 것이 아니다.
온전한 QA는 단순한 기능 점검을 넘어서는 역할을 한다. 다양한 테스트 방식을 활용해 소프트웨어의 품질을 보증하는 것이 QA의 핵심이다. 즉, QA는 요구사항 도출 시점부터 최종 결과물이 완성될 때까지 소프트웨어 라이프사이클 전반에 걸쳐 지속적이고 다각적인 방법으로 수행되어야 한다!
대부분의 IT 회사는 QA 전담 팀을 운영하며, 프로젝트 초기 단계에서부터 QA 담당자가 참여해 프로젝트의 방향성, 목표, 클라이언트 요구사항을 명확히 점검한다고 한다.
개발자들도 나름대로 기능 구현 후 테스트를 진행하지만, 빡빡한 일정 때문에 주로 몇번 시도해본 뒤 다음 기능 구현으로 넘어가는 경우가 많다. 그래서 QA에서 다양한 경우의 수를 반복적으로 테스트해보는 것이 중요하다.
하지만 대학생 팀에서는 별도의 QA 전담 팀을 두기 어렵기 때문에, 보통 PM이 이 역할을 맡게 된다. 나는 QA를 다음과 같은 3단계에 걸쳐 진행하였다.
1단계 : 개발자에게 체크리스트를 제공하여 1차 점검을 맡긴다. 이 단계에서는 기능 구현의 완성도에 중점을 두고, 개발자가 스스로 문제를 파악하도록 돕는 것이 목적이다.
2단계 : 기능 QA와 디자인 QA로 나누어 진행한다. 기능 QA에는 PM, 프론트 개발자1, 백엔드 개발자가 참여하고, 디자인 QA에는 디자이너와 프론트 개발자2가 참여한다. 이 단계에서는 대면 체크를 통해 다양한 예외 상황을 논의하고 고민하는 시간을 가진다.
3단계 : QA 결과를 바탕으로 버그 리포트를 작성하고, 이를 반영한 개발 기간을 거친다.
이런 사이클을 유지하며 점차 버그를 줄이고 요구사항을 반영하려고 노력하고 있지만, 대학생 팀의 여건상 즉각적인 수정이 어렵다고 느낄 때도 많은 것 같다. (기능1을 수정 중이던 중 잘되던 기능 2가 갑자기 오류가 발생하는 경우 등..) 그럼에도 QA 과정이 프로젝트의 퀄리티를 높이는 가장 효과적인 방법임은 분명하다고 생각한다!
사실 오늘 소개한 두 가지 방법 모두 이미 팀에서 시행 중이거나, 한 번쯤 들어본 내용일 수 있다. 또한 여러 강연이나 세미나에서도 학부생 수준과 현업은 큰 차이가 있다고 강조하니, 실무와는 다소 거리가 있을 수도 있다..
그럼에도 우리 팀에 맞게 시행착오를 거쳐가며 다양한 방법을 시도해보는 것은 현업에서도 중요하다고 생각한다! 개발이 막바지에 이른 지금, 다음에는 출시 여정을 담아보겠다 :)