프로덕트 드리븐 개발
생산성을 극대화해보기 위한 시도
프로덕트 드리븐 개발이라는 타이틀은 임의로 붙인 가제입니다
스타트업에서 가장 중요한 건 속도인 것 같습니다. 검증되지 않은 비즈니스를 누구나 사용할 수 있는 서비스 만들기 위해서는 많은 시행착오가 필요합니다. 따라서 많은 시도를 하게 되고 때로는 공을 많이 들인 기능을 폐기해야 할 때도 있습니다. 스타트업에서의 에자일은 필수 불가결한 요소이지만 실질적으로 프로덕트를 개발하다 보면 전혀 에자일 하지 않은 경험을 하게 됩니다. 디자인 시스템을 통한 UI 컴포넌트화로 빠른 화면 구성이 가능하고 배포 자동화로 빠른 서버 배포가 가능하지만 그 과정 속 워크플로우의 개선 없이는 의사 결정에 있어서 지루한 핑퐁을 계속하게 되어 속도가 저하되는 경험이 계속되어 개선을 해보았습니다.
무엇이 문제일까?
전통적인 프로덕트 개발에서는 3가지 요소가 있습니다.
1. 기획자 (PM)
2. 디자이너
3. 개발자
구현하고자 하는 비즈니스를 기획자가 사용자의 요구사항을 분석해 기획 문서를 만들면 디자이너가 화면 구성을 그리고 그 화면대로 개발자들이 개발을 하는 워터폴 형태의 워크플로우입니다. 스타트업에서는 에자일 하게 프로덕트를 개발한다고 하지만 가만히 생각해보면 앞서 말한 워터폴의 형태를 빠르게 반복하는 것뿐입니다. 또 한 최종 단계에 있는 개발자에게는 기획자의 의도가 명확히 전달되지 않을 가능성이 큽니다. 그 이유는 제품에 대한 요구사항을 명확하게 정리하려면 해당 비즈니스의 도메인 지식이 누구보다도 풍부해야 할 테니까요. 그렇지 않은 상태에서 디자이너에게 간다면 프로덕트 개발은 가족오락관의 고요 속의 외침이 될 수밖에 없을 것입니다. 이렇게 요구사항이 제대로 전달되지 않는다면 기간은 반복하는 횟수와 추가로 발견되는 누락된 요소들에 의해 기하급수적으로 늘어나게됩니다.
흔한 프로덕트 진행 과정프로덕트 오너 (Product Owner, PO)
최근 많이 들려오는 단어이기도 하고 어떻게 보면 스타트업 전성시대인 최근 에자일에 대한 고민을 많이 하면 할수록 대두될 수밖에 없는 키워드인 것 같습니다. 도메인과 프로덕트의 정보가 가장 풍부 해고 개발적 지식이 풍부한 사람이 프로덕트의 요구사항을 직접 분석해 개발팀에게 전달하고 직접 화면 설계를 한다면 생산성을 향상함과 동시에 프로덕트에 대한 책임 소재를 명확히 할 수 있습니다. 프로덕트 디자이너와 마찬가지로 프로덕트 오너는 만들어지는 게 아니라 협업에 대한 깊은 고민에 많은 시도를 해본 베테랑인 경우가 대 다수이기 때문에 유니콘급 스타트업이 아니라면 확보하기가 쉽지 않은 인재이기도 한건 아쉬운 일입니다.
그래서 나름대로 만들어 본 프로덕트 드리븐 개발팀
프로덕트 드리븐 개발팀 만들기 준비물
- 디자인 시스템 / UI 라이브러리
- 지라 기반의 협업 환경
- Figma
- 도메인 지식이 풍부한 프런트엔드 개발자 x 프로덕트 개수 (!!)
디자인 시스템 / UI 라이브러리
PO가 요구사항을 정리해 와이어프레임을 그리기 위해 가장 중요한 건 디자인 시스템입니다. 디자인 시스템 없이 요구사항을 UX 디자이너에게 맡긴다면 가족오락관을 되풀이할 수 있습니다. 프로덕트 오너가 디자인 시스템을 이용해 최대한 빠른 와이어 프레이밍을 하여 최소 기능모델의 출시를 목표로 하고 UX는 최소 기능모델의 분석과 개선과 새 퍼널 설계에만 관여합니다. (UX도 블록 조립하듯 UI 라이브러리를 이용하게 되어 정량적/정성적 데이터 분석에 따른 가설/실험 설계에 집중할 수 있습니다)
디자인 시스템 구축기
https://brunch.co.kr/@fifthsage/3
지라 기반의 협업 환경
PO는 모든 요구사항 분석과 구현에 대한 커뮤니케이션은 지라 티켓에 모아둡니다. 추가 설명이 필요하거나 구조화된 문서가 필요한 경우 컨플루언스로 위키 화해 티켓에 연결합니다. 와이어 프레이밍 한 Figma링크도 티켓에 Designs 플러그인을 이용해 모아둡니다. 티켓에 할당된 주 담당자는 제품별 프런트엔드 개발자이며 서버 개발자는 API 관련 작업을 해당 티켓에 하위 작업으로 등록합니다.
티켓에 개발에 필요한 모든 정보들이 모여있음Figma
이 전에 작성했던 글을 통해 Figma로 UI 컴포넌트를 만들어 라이브러리화 하는 과정을 정리했듯이 빠른 와이어 프레이밍과 프로토 타이핑을 위해 필수적인 툴입니다. 담당자는 해당 와이어프레임과 프로토타이핑으로 UX를 이해합니다.
프로덕트 오너가 요구사항을 개발자에게 전달하기 위해 작성한 와이어프레임 및 프로토타이핑도메인 지식이 풍부한 프런트엔드 개발자
전담 PO가 없는 환경에서는 프런트엔드 개발자가 PO가 되는 것이 이상적이라는 개인적인 생각입니다. 사용자의 요구사항을 반영하는 최접점이 프런트엔드이고 실제로 개발을 하다 보면 백엔드에서 API가 내려와도 프런트엔드에서 시행착오로 인해 백엔드의 작업량이 늘어나는 경험이 비일비재하게 생기기 때문에 프런트엔드 개발자가 PO역할을 함께하는 것이 핑퐁을 줄일 수 있는 이상적인 포지션이라고 판단했습니다.
* 케어닥은 2,3,4번째 합류 멤버가 전부 개발자이기 때문에 이러한 시도가 가능했다는 생각이 들기도 합니다.
운영은 어떻게?
프로덕트 드리븐 개발의 개념도PO가 요구사항을 분석해 정리하지만 운영에서 일어나는 이슈들에 대한 대응도 분명 필요합니다. 비즈니스 로드맵에 따라 운영과 함께 기능을 준비해야 하는 경우도 다반사입니다. PO에 의해 요구사항이 분석되기 이전에는 매우 러프한 내용일 가능성이 큽니다. Planning 단계에서 러프한 기획 내용들을 notion에 문서로 정리하면 기획 회의를 통해 PO가 요구사항들을 분석하고 재정리해 앞서 이야기했던 지라 티켓으로 정리를 한 후 담당자를 배정하게 됩니다. PO는 프로덕트 전반에 대한 책임을 가지고 있으므로 개발이 완료되어 릴리즈가 되는 버전에 대해 전체 구성원들이 알 수 있게 알리는 역할도 수행합니다.
구성원들이 알기 쉽게 릴리즈 정보를 공지합니다.프로덕트 드리븐 6개월 그 이후
처음 이 워크플로우를 구상한 후 구성원들을 설득시키는 건 어렵지 않았습니다. (개발이 빨라진다!라고 했고 좋다!라고...) 가장 중요한 문제점은 전담 PO가 없는 상태에서 프런트엔드 개발자들이 과중한 역할을 수행할 수 있을가에 대한 걱정이었습니다. 과중이 되지 않는다 하면 거짓말일 테고 그나마 디자인 시스템을 선행해 놓고 계속 개선해 나간 것이 아무래도 많은 도움이 되었던 것 같습니다. 앱 배포에 있어서도 더욱 책임감이 생기는 것도 긍정적인 효과입니다. 또한 와이어프레임을 기다리는 (디자이너가 기획자와 핑퐁 하는 시간)이 줄어들고 각 PO가 제품별로 와이어프레임을 만드니 병목도 사라져 개발 속도는 확실히 빨라졌습니다. 정착이 되어감에 따라 조직 자체도 UI/UX포지션을 없애고 UI 디자이너를 프런트엔드 개발팀에 포함시켜 디자인 시스템 UI라이브러리에 대한 전반적인 관리를 맡김과 동시에 UX는 그로스팀으로 이동해 실험 설계 및 리서치로 완전히 분리해 운영 중에 있습니다. 아직도 해결해야 하는 협업 과제들과(프런트엔드와 백엔드 사이의 핑퐁) 이 워크플로우의 예기치 못한 부작용이 있을 수도 있지만 앞으로도 현행을 유지하며 빠른 성장에 기민하게 대응할 수 있을 것 같습니다.
밭을 만들어 무언가를 생산하려면 호미나 괭이만 가지고는 밭을 일궈낼 수 없습니다. 때로는 트랙터도 필요하고 소도 필요하지만 무엇보다 많은 자원들을 효율적으로 운영해야 생산성을 극대화할 수 있다고 생각합니다. 프로덕트 드리븐 개발이라는 가제로 많은 고민 끝에 운영 중인 워크플로우를 공유해 봤습니다.
