<프로덕트 매니지먼트> 김영욱 저/ 챕터 5
PM의 업무
PM의 업무
-와이어프래임,프로토타입,목업
-프로덕트 백로그,에픽, 사용자 스토리
-우선순위 정하기
-MVP
1.와이어프래임, 프로토타입, 목업
PM이 충실도가 낮은 와이어프래임을 그리고, 디자이너가 목업과 프로토타입 완성한다. 와이어프래임을 그리는 과정에는 디자이너의 개입의 여지가 충분히 있으며, 어떤 형식으로 그려낼 지는 정해져있지 않다. 커뮤니케이션의 수단이며 쉽게 변형가능해야하므로, 기능의 우선순위가 잘 담기게 고려하되 노트에 손으로 그리거나 피그마를 사용하거나 일러스트를 사용하거나 피피티를 사용하거나 어떤 방식을 사용해도 문제가 되지는 않는다.
나는 와이어프래임을 그리면서 각 버튼과 이미지에 넘버링을 하고 디스크립션을 표로 만들어 옆에 두었었다. 그렇게 하면 소통하기 편리할 것이라 생각했기 때문이다. 허나 내가 그린 와이어프래임은 디자이너가 프로토타입의 형태로 다듬는 과정에서 버튼의 위치를 포함해 일부 플로우가 변경되는 경우도 잦았기 때문에 결과적으로는 디스크립션을 한 번 다시 작성하거나 그때 그때 개발자가 물어보는 내용에 답변을 드려야 하는 번거로움이 있었다.
와이어프레임은 기본적으로 레이아웃인데, 아이디어를 개념화하고 전달하고자 할때 가장 먼저 진행되는 작업이다. 때문에 모든 것은 확실하지 않고, 낮은 충실도로 시작해야 한다. 정확하지 않거나 세부사항이 많지 않다는 의미다. 전반적인 비전을 정의하기 위함이며 러프한 버전이다. 내부적으로 일부 피드백을 수집하면서 프로덕트의 형태를 정의해야한다.
목업은 모형을 의미한다. 목업은 최종 프로덕트가 실제로는 시각적으로 어떻게 보여야하는지에 대한 정적 디스플레이며, 색상, 타이포그래피, 폰트 및 스타일 같은 룩앤 필을 결정할 기회를 제공한다. 색상 및 버튼 모양, 사진이 추가된다. 브랜드 컨셉에 맞춰 모든 버튼의 형태가 발명되어야할 때도 있기때문에 디자이너가 충분한 시간을 쓸 수 있도록 한다.
프로토타입은 목업으로 만들어진 스태틱 디슬플레이다. 정적 화면에 인터렉션이 추가된 형태이다. 목업에 넘버링을 하면서 각 항목이 어떻게 움직일지를 충분히 기술했다면 개발자와 소통하는 데에 있어 프로토타입까지 제작할 필요는 없는 것 같다. 구두나 텍스트보다 더 명확한 소통을 위해 화면 간 이동을 직접 보여주기 위함이다.
개인적으로 작은 규모로 프로젝트를 하면서 느낀 가장 효율적인 방법은 이하와 같다.
우선 와이어프래임을 그리는 단계에 접어들었다면, 러프한 형태로 와이어프래임을 스케치해 개발자, 디자이너에게 공유한다. 화면상의 디테일은 수정될 것이기 때문에 아직 프론트 개발자가 작업을 시작할 순 없다. 다만 와이어프래임을 그리면서 정보구조도 IA를 함께 완성했다면 개발자들과 함께 어떤 데이터를 어떻게 처리해아하는 지를 확인할 수 있고, (나는 잘 모르지만) 개발단위에서 이 단계에서 밑작업을 시작하시는 경우도 더러 있었다.
전체 와이어프래임이 한번에 완성되기 전에, 섹션을 나눈다. 나눈 섹션에 순서를 매기고 하나씩 목업을 완성하도록 한다. 하나의 섹션은 하나의 플로우를 기준으로 하며, 3-6페이지가 적당하다고 생각한다. 첫번째 섹션이 목업으로 완성되어 나오면, 검토후에 기획자가 각 화면 요소에 넘버링을 하고 디스크립션을 작성해 개발팀에 전달한다. 그러면 개발이 시작될 수 있고, 이후 차례로 완성될 페이지들에 대해서도 누구 하나 손이 놀지 않고 동시적으로 작업하는 게 가능하다. 메일링크를 출시하기 전에 사용한 방법이고, 노션의 캘린더를 활용해 각 섹션별 디자인 마감기한, 개발 마감기한을 정해두고 진행했다.
허나 본격적으로 애자일하게 운영된 오노브의 지난 일년의 경우에는 위와 같이 진행하지는 못했다. 각 기능을 추가해 릴리즈 해야할 때 항상 시간이 충분하지 않았고, 주어진 시간 내에서 가능한 범위까지만을 소화하는게 목표였다. 오프라인 행사 시기에 맞춰 매번 온라인도 배포 했기 때문이다. 이를테면 인비테이션 기능을 추가한다고 했을 때, 기획 > 디자인> 개발 > 배포. 이렇게 이어달리기하듯이 배포날짜가 행사 일주일전에 맞춰지도록 움직였었다. 오프라인 상황이 조정되어 기획이 늦어질때마다 아찔했다.
2. 프로덕트 백로그, 에픽, 사용자 스토리
오노브를 하면서 개발자분이 노션에 백로그 페이지를 예쁘게 만들어주신 적이 있다. 이후 꾸준히 백로그에 내용을 생성하고, 완료로 옮겨 놓으며 매 회의에선 백로그 진행상황을 확인했다. PM이 제품을 성공적으로 시장에 출시하기 위해서는 계획 및 목표를 업무의 테스크 단위로 세분화해야하고, 이것이 백로그라는 이름으로 만들어진다. 우리는 하나의 백로그 페이지를 공유했기 때문에 생성되는 백로그 중에는 기획자가 해야하는 것, 디자이너가 해야하는 것, 개발자가 해야하는 것, 개발자와 디자이너가 함께 해야하는 것 등등 모든 항목이 존재했다.
백로그에는 사소한 수정부터 주요 기능까지 모든 영역이 포함된다. 일부 백로그 항목은 다음 스프린트에 선택되어 스프린트 백로그로 들어가며 티켓으로 관리된다. 오노브에서는 스프린트 백로그, 티켓이라는 용어를 사용하지는 않았고 ‘진행중’으로 표시했다.
에픽은 만들고자 하는 하나 이상의 프로덕트 기능을 포함한 그룹이다. 메일링크를 운영하다 중반기쯤에 큰 업데이트를 했는데 이때 새롭게 추가된 플로우(사용자 스토리)가 뭉텅이로 있었다. 이 뭉텅이가 에픽이라 칭해질 수있는 것 같다.
마지막으로 사용자 스토리는, 지난 챕터에서도 정리한 적이 있어 넘어가겠다. (사용자 입장에서) 나는 이러한 (필요, 욕구, 이익)을 위해 (행동) 하기를 원한다’ 는 형식을 따른다.
3. 속도
프로덕트를 출시하거나, 작게는 수정사항을 반영하는 일까지, PM은 각 업무가 얼마나 빨리 진행될 수 있는지를 알아야 한다. 개발자, 디자이너에게 소요되는 시간을 구체적으로 묻고 얻은 답변을 바탕으로 전체 계획을 짜는 게 일반적이다. 디자인의 경우에는 함께 일하고 있는 디자이너분과 합을 맞춘 지 2년이 되어가고, 속도를 어느정도 가늠할 수 있게 되었다. 허나 개발의 영역에서는 기능이 얼마나 복잡한지, 어떤 레벨의 기능인지 매번 파악하기 어렵기 때문에 절대적으로 개발자분들의 의견에 의존하여 속도를 추정한다.
팀으로 함께 하며 이때의 속도를 좀 더 정확하게 추정할 수 있는 방법이 있다. 스크럼의 진행률을 의미하는 벨로시티를 활용하는 것이다. 스프린트 계획 미팅을 할때, 모든 엔지니어에게 일을 하는 데 얼마나 걸리는지 물을 뿐 아니라 얼마나 어려운가를 등급을 만들어 답하게 한다. 1-5까지의 레벨이 있다면 일관되게 적용하여 레벨 2의 일인지, 3의 일인지를 알아낸다. (이때의 레벨이 스토리포인트) 그리고 각 스프린트가 끝나면 완료한 스토리 포인트의 양을 합산한다. 몇 번 스프린트를 수행하다보면 스크럼 팀의 벨로시티가 대략적으로 예측된다.
이를 번다운 차트로 만들어 관리할 수도 있겠지만, 그렇게까지 엄격하게 팀 내의 업무 속도를 측정하고 관리하는 것은 사이드 프로젝트에서는 무리가 있다. 오노브는 팀원 각각이 프로젝트 외의 일로 바빠 일의 속도가 지연되는 경우가 대부분이기 때문이다.
4. 우선순위 정하기 - 모스코/ 워킹 스켈레톤
책에서는 프로덕트 백로그 우선순위를 정하는 방법으로 네 가지를 배운다. 여기에는 그 중 우리 팀 내에서 적용해볼 수 있는 두가지를 정리하겠다.
1) 모스코 우선순위 정하기
-must have
이 기능이 없으면 런칭을 생각할 수 없다. 킬러 기능에 해당한다. 포함하지 않았을 경우의 최악의 시나리오를 떠올리면 이 곳에 들어가야하는지 아닌지를 구분할 수 있다.
-should have
필수는 아니지만 매우 중요한 가치를 제공한다.
-could have
나이스 투 해브에 해당하며, 충분한 자원을 가졌다면 할 수 있었을 것이지만 성공을 위해 꼭 필요하지는 않다.
-will not have
필요없다는 의미가 아니라. 이번 버전에는 포함되지 않을 것이라는 의미다.
2) 워킹 스켈레톤 우선순위 정하기
예시 이미지로 설명하는게 빠를 것 같아 처음으로 이미지를 첨부한다.
개념의 윤곽 정도가 아니고 실제로 실행할 수 있어야 하며 테스트도 함께 가능해야 한다. 필요한 사용자 스토리에 순위를 매기고, 주요 기능이 완전하게 동작하는 프로덕트의 형태를 갖고 있어야 한다.
메일링크를 런칭하기를 앞두고는 두 가지 방법론을 적절히 믹스한 형태로 노션에 표를 만들어 우선순위를 정했었다. 우선순위에서 밀렸던 기능은 런칭 이후 기능을 추가해 배포했다.
오노브의 경우에는 에자일을 이유로 위와 같은 우선순위를 정하는 일에 소홀했다. 당장에 필요하다고 생각되는 기능을 , 팀 내에서 나온 피드백과 아이디어, 이해관계자 (공간측)의 요청에 따라 추가했기 때문이다. 내년 상반기에 앱을 출시한다면 위와 같은 우선순위 차트는 꼭 필요할 것이다.
5. MVP
너무나 자주 입에 올리는 MVP다. 여기선 MVP의 오해를 풀고 정의에 다가가본다.
MVP는 해결할 가지가 있는 문제를 찾았는 지 알아내어 실패의 위험을 줄이고, 가장 중요한 가정을 빠르게 테스트해 사용자에게 피드백을 받는게 목적이다. 즉, 최대한 빨리 실패하고 배우는게 목적이라고 다시 말할 수 있다. MVP가 항상 최종 제품의 샘플 버전이나 저렴한 버전은 아니다! 특별한 기능이나 디자인을 테스트한느 것이 아닌 핵심 가치를 검증하는 데 필요한 최소한의 버전이다.
오노브가 내놓을 앱은 MVP로 정의되긴 어렵다. 브랜딩까지 구색을 맞춰둔 상태이며 잠재 사용자가 확보되어 있는 상태에서 하는 릴리즈다.
MVP의 목적은 판매가 아니라 학습이다. 최소 핵심 기능만 포함하여 시장에 내놓을 것이였다면, 이미 꽤 많은 거리를 걸어온 것 같다. 실제로 MVP는 확인하는 과정의 산물이지 반드시 최종물의 작은 버전이 아니다.
-----
이제 5챕터를 마쳤다. 오노브가 앱 런칭을 앞에 두고 MVP라도 만들어 수요를 확인해봐야 할지, 지금까지의 설문조사 결과와 현장에서 체감한 셀러들의 불편 사항, 앞으로 있을 인터뷰를 기반으로 바로 앱을 출시할지는 결정되지 않았다. 최소한의 기능만을 포함해 사용해보도록 하는 것을 팀내에서 논의해보면 어떨까? 디자인 요소는 제외하고 말이다.... 고민이 깊어지는 저녁이다.
