[PRODUCT] 서비스 기획자가 디자이너, 개발자와 협업하는 방법

[티끌] 사이드 프로젝트 협업 방식

안녕하세요. 티플의 서비스 기획자 최윤아입니다!
오늘은 티끌 팀이 소통하는 방식에 대해 알려드리려고 하는데요! 사이드 프로젝트로 진행하는 팀 치고 소통이 굉장히 많은 팀이기 때문입니다. 기능 하나, 뷰 하나를 짤 때 운영부터 기획, 디자인, 프론트와 서버에 이르기까지 어떻게 의사결정이 이뤄지는 지에 대해 소개해드리려고 해요🤓

---

 

🚀 애자일로 운영되다. (feat. 운영 방법론)

IT 분야를 지망하고 계신 분들이라면 다들 애자일 방법론에 대해 아실테지만 사이드 프로젝트는 애자일을 적용시키기는 매우 어려운 환경입니다. 모두의 1순위가 프로젝트가 아니기 때문에 여러 번의 사이클을 돌기 어렵죠. 특히, 이미 진행된 개발 결과물에 대해 그것을 뒤집기는 더더욱 아쉬움이 남죠🥹

애자일 방법론 (출처 : The Agile Development Process for Mobile Apps, Krasamo)

 

🤔제가 생각하는 애자일이란?
일단 최소 기능 개발을 중심으로 작업을 시작하고, 프로젝트 진행 중에 유저 피드백, 데이터 등을 통해 요구사항을 추가해나가는 방법론이라고 생각합니다:)

그러나 티끌은 그것을 해내고 있습니다🫨

저번 글을 읽고 오신 분들은,
티끌이 초기 론칭에 최소 기능만을 담은 MVP를 출시했다는 사실을 알고 있으실 거예요!
 

첫 사이클의 목적은 ‘신규 유저의 챌린지 신청까지의 경험’을 최적화하는 것이었는데요. 지금 진행되고 있는 사이클의 목적은 ‘새로운 기능을 통해 가입한 유저의 리텐션을 높이자!’입니다.
(새로운 기능은 열심히 개발하고 있으니 9월 초에 만나보실 수 있을 거예요🤩)

---

그렇다면, 지금 진행되고 있는 일들의 세부 목표는 언제 정해졌을까요?

“바로 BETA 론칭 이후입니다🙌 “

그러나 한 사이클의 목표를 달성하기 위해, 세부 기획을 하다보면 근거와 논리가 뒷받침된 정말 좋은 아이디어들이 많이 생각 나는데요.  이런 아이디어들을 모두 기능으로 구현할 수는 없습니다. 조금 더 정확하게 말하면 불가능하다기 보다는 ‘다른 기획과 우선순위가 동일한가?‘를 생각했을 때, 아니라는 답이 나오게 되죠.

기획 단부터 볼륨이 커지게 되면, 뒤따르는 명세, 디자인, 뷰, API까지 후속 작업에 리소스가 많이 들 수 밖에 없습니다. 모두가 24/7 올인할 수 없는 상황에서 이러한 운영은 팀 차원에서도 효율성을 저해한다고 생각했습니다.

그래서 저희 기획팀은 아래 사진과 같은 ‘언젠가 보관함’을 만들어둡니다.

언젠가 보관함, 티클러 파일 (GTD)

언젠가 보관함은 📂티클러 파일📂이라고 표현되는데요. 이름이 티끌과 비슷하죠? GTD라는 책에 나오는 2분 프로세스에서 찾아볼 수 있는 개념입니다. 이렇게 언젠가 파일을 만들어두게 되면, (1)좋은 기획을 버리지 않으면서 (2)서비스 정체성을 가져갈 수 있게 됩니다.😆

처음에는 좋은 아이디어들이 리소스의 부족으로 실현되지 못 하는 것에 무력감을 느끼기도 했는데요. 티끌의 기획 팀은 기획을 위한 기획이 아니라, 프로덕트의 성공을 위한 기획을 하고 있기 때문에 훨씬 더 가치 있는 일이라고 생각하고 있답니다☺️

---

 

🚀 프로젝트의 단계별 목표를 설정하다. (feat. 사이클과 스프린트)

티끌의 전체 프로젝트는 어떻게 굴러가고 있을까요? (돌 굴러가유~)
대략적으로 아래 4가지 단계를 거칩니다!
 

1. 최상위 목표 설정
2. 최상위 목표 도달을 위한 사이클 분배
3. 각 사이클의 목표 설정
4. 스프린트 별 세부 목표 설정

티플은 우선 큰 관점에서 프로덕트의 목표라고 할 수 있는 부분을 정의해둡니다.
 

• 다운로드 수 증가
• 신규 유저의 UX 최적화
• 기존 유저의 챌린지 참여율 증가
• 유저 간의 상호작용 확대

이런 것들이 목표가 될 수 있겠죠?
사이클은 큰 단위에서의 구분이고, 스프린트는 실제 일의 진행 단위라고 생각해주시면 될 것 같아요! 팀 마다 다르겠지만 티끌은 하나의 큰 사이클 안에서 여러 스프린트가 돌아가고 있는 중입니다. 지금 진행되고 있는 사이클의 예시를 살짝 가져와봤습니다🙌 

1. 최상위 목표 설정

✔️ 최상위 목표 : 다운로드 수 500 모으기

2. 최상위 목표 도달을 위한 사이클 분배

✔️사이클 1 : BETA 버전 배포 | 사이클 2 : 정식 론칭 | 사이클 3 : 업데이트

3. 각 사이클의 목표 설정

✔️ 사이클 3 목표 : 가입한 유저의 지속적인 서비스 사용 경험 개선

4. 스프린트 별 세부적인 목표 설정

✔️ 스프린트 1 목표  : 서비스 내 자유도를 높이기 위한 챌린지 요일 커스텀 로직 개선

이렇게 체계적으로 목표가 설정되었다면, 팀의 구성원들이 지속적으로 인지하게 하는 것도 계획만큼이나 중요합니다.
허울뿐인 목표는 실질적으로 필요없는 것이니까요!
 

회의 시간에 리마인드한 1차 론칭의 목표

위에 있는 이미지는 저희가 첫 론칭을 준비할 때 티플이 계속 리마인드했던 목표입니다. 첫 론칭이 이뤄지기 직전, 기획, 디자인, 개발 그리고 마케팅 단의 각자 욕심이 있다보니 조금 더 완벽하고, 보기에 좋은, 내가 해보고 싶은 것들에 리소스가 들어가는 상황을 파악하게 되었습니다. 그러나 티플은 처음부터 완벽한 프로덕트는 없다고 생각했습니다.

그러면 우리가 처음에 정했던 목표를 달성하는 데에 ‘내가 하고자 하는 작업이 임팩트가 있는가 아닌가’를 매순간 판단해야 했죠. 그래서 저희는 첫 론칭을 앞두고 이번 사이클의 목표, 그리고 다음의 목표를 리마인드하는 시간을 가졌었습니다!

이렇게 1-4번까지 팀의 모든 구성원이 합의한 목적 설정이 완료되고 나면, 이제는 시작을 위해 4. 세부적인 목표를 ‘이행’하면 됩니다!

---

 

🚀 기획자는 모두와 같이 일한다. (feat. 와이어프레임, 화면 설계서)

 

위에서 잠깐 언급 드렸다시피, 애자일 방법론은 소통이 굉장히 많이 필요한 운영 방식입니다. 특히, 프로덕트 매니저는 돌아가는 모든 일을 파악하고 align을 맞춰야 하죠.
 
그리고 항상.. '리소스 한계'에 부딪히죠..

PM 도전기 : 절망편🤣

결코 피할 수 없는 '개발 리소스 한계와 시간 제약'이라는 아주 큰 골칫거리를 해결하기 위해 티플은 문제에 정면 돌파하기로 했습니다. '안 되면 될 때까지 최선의 대안을 찾는 것'이 티플의 해결 방식입니다.
그 과정에서 개발팀은 리소스를 줄이며 기획 의도를 구현할 수 있는 방법을 찾아내고, 기획 팀은 개발의 볼륨을 줄이기 위한 방법들을 공부하게 되었습니다😉
 

이제 진짜 일하는 방식을 보여드리겠습니다!

 

티끌 팀의 협업 中 기획 프로세스
➡️ 데이터, 리서치 분석 > 아이데이션 > Lo-Fi 버전 와이어프레임 공유 > 피드백 수렴 > 기능 구체화 > 피드백 수렴 > Hi-Fi 화면 설계서(와프+명세서) 전달 > 구현 로직 및 구조 공유

간략하게 쓰려고 했는데도, 단계가 굉장히 많죠? 🤣
최종 단계가 끝났을 때 개발을 시작하는 것이 아니라, 기획의 첫 단추부터 같이 개발자와 공유하면서 틀을 잡아나가는 구조입니다. 그렇게 되면 디자인, 개발팀이 미리 새로운 페이지에 대한 구조를 파악하고 업무를 계획할 수 있거든요!🤓

물론, 팀 상황에 따라 기획이 완벽하게 된 후에 디자인, 개발에게 넘기는 워터폴 방식도 유용하다고 생각합니다. 그러나 모든 팀원의 의사소통과 기획 참여율이 높은 티플에서는, 위와 같은 단계를 거치는 것이 오히려 실제로 일을 시작했을 때 작업에 부스트🚀를 달 수 있는 방법이었습니다!

티플은 자신이 하고 있는 일이 서비스 전체에 어떻게 종속되어 있는 지를 충분히 이해하고 의견을 적극적으로 내는 팀입니다. (😚뿌듯_자랑)

---

✏️1. 데이터 / 유저 리서치 분석

티플은 세부적인 task들을 설정할 때 크게 2가지 소스를 활용합니다.

UT와 GA 데이터를 통한 분석

1️⃣사이클 목적 달성을 위해 꼭 필요한 최소 기능
2️⃣유저 인터뷰나 GA 데이터에서 비롯된 부가 기능
 
그래서 하나의 사이클에서는 1️⃣을 기반으로 먼저 디자인, 개발팀과 소통한 후 작업을 진행하고 2️⃣의 데이터를 활용해 요구사항들을 추가합니다!
 

.    .   .

 

✏️ 2. 아이데이션

앞단계에서 나온 페인포인트나 니즈, 개선 사항들을 해결하기 위한 아이데이션을 진행합니다.
주로 회의를 하면서 아이데이션을 진행하고, 레퍼런스를 참조합니다.

간략하게 그려보는 아이데이션 노트

사실 이 아이데이션 과정이 제일 막연하고 시간이 오래 걸리는 일이기도 합니다. 단순히 좋은 아이디어가 아닌, 서비스 그리고 스프린트 목표와 맞는 기능을 만들어내야 하기 때문이죠. 가끔 논리의 오류에 빠져 단순한 문제에서 헤매기도 합니다.🫠
 
그래서 티플은 이 단계에서 어떻게 표현될 지에 대한 생각을 최소화 하고, 문제를 정의하고 해결하는 과정에 집중합니다. 최상위 문제가 프로덕트 방향성과 맞는 지를 생각한 후, 제대로 정의해두면 그 안에서 생기는 수많은 아이디어들은 적어도 길을 잃지 않게 됩니다.🤓 이 과정에서 큼지막한 기능들의 우선순위를 정하고 다음 단계로 넘어갑니다.

 

.    .   .

 

✏️3. Lo-Fi 와이어프레임 공유

초기에 디자인, 개발팀의 이해를 돕기 위해 매우 간단한 형태의 와이어프레임을 만들어 소통합니다. 매우 대략적으로 기능의 의도와 볼륨을 설명해서 디자인, 개발 팀이 리소스를 확보할 수 있게 돕습니다. 화면을 구성하는 UX writing이나 기능의 구체성은 생각하지 않고 아이디어를 직관적으로 표현합니다.

.    .   .

 

✏️4. 기능 구체화

그 후, 아이디어에 지나지 않았던 기획들을 실제로 ‘구현 가능하게’ 만드는 과정을 진행합니다.

피그잼을 통한 기능 정의 과정

해당 단계에서는 기능 명세서를 작성하기 위해 개발팀과 깊게 얘기하며 다양한 케이스를 생각해봅니다. 이 과정에서 리소스의 부족으로 제거되는 기능들도 많지만🤣 개발팀이 적극적으로 대안을 제시해줘서 ‘오! 이게 되네?’하는 부분들도 많답니다 ㅎㅎ 소통하는 개발자와 같은 팀이 되는 것은 정말 행복입니다!! 정리된 기능들은 아래 최종 화면 설계서에 포함됩니다!

.    .   .

 

✏️5. Hi-Fi 화면 설계서

마지막으로 앞단의 디자인, 개발팀과 논의된 사항을 정리해 구현 가능한 문서로 작성하여 공유합니다. 모두가 합의된 사항에 대한 명세서이기 때문에 훨씬 이해가 빠르고 작업이 효율적으로 진행될 수 있습니다!

최종으로 공유되는 화면 설계서

사실 이렇게 프로세스가 잡히기 까지는 많은 시행착오들이 있었는데요. 거듭 얘기하듯 그 과정에서는 팀원들과의 활발한 소통과 협업이 절대적으로 중요하게 작용했다고 생각합니다.
 
 
이외에 유저 플로우 차트나 데이터 구조도 같은 부분도 문서로 작업하는데요. 이런 문서들은 '업데이트'의 개념이라 사실 매 스프린트마다 진행되지는 않습니다. (사실 해야하는 게 맞습니다..^^) 큰 볼륨의 기능이 들어가거나 제거되었을 때, 시간을 내서 작업하는 것 같아요. 중간에 몇 가지 문서가 빠져도 기획한 대로 디자인되고 개발될 수 있는 것은!! 팀원 모두가 프로덕트에 대해 충분히 이해하고 작업을 시작하기 때문인 것 같습니다.
 
 

---

티끌 기획자의 입장에서 디자이너, 개발자와 협업하여 기능을 구체화하는 과정을 보여드렸는데요! 이외에도 티플은 팀 내에서 정말 다양한 커뮤니케이션과 협업을 하고 있습니다. 다음 글에서는 티플 전체가 소통하는 방식, 사용하는 툴, 커뮤니케이션 룰에 대해 자세히 다뤄보도록 하겠습니다.
지금까지 티끌의 서비스 기획자 최윤아였습니다.😻



⬇️ 지금 구글 플레이 스토어에서 티끌 다운 받기!
https://play.google.com/store/apps/details?id=com.team7.tikkle&hl=ko-KR

📩 Contact : dudusiz3368@gmail.com
📲 SNS : https://instagram.com/dudu_siz.v3