[PRODUCT] 사이드 프로젝트 운영하는 법2 (feat. 팀 문화)

안녕하세요. 티플의 서비스 기획자 최윤아입니다! 저번 글에서는 더 효율적인 협업을 위해 도입한 것들을 소개했는데요. 이번 글에서는 티플이 더 좋은 ‘팀 워크’를 이끌어내기 위해 어떤 문화들을 정립해나갔는 지 보여드리고자 합니다.

---

🚀 사이드 프로젝트 팀 내 구조 개편

티플은 모두가 책임감이 높고, 자신이 맡은 업무에 대한 오너십이 강한 팀이었기 때문에 사실 팀원들의 역할이 제대로 정의되어 있지 않았습니다. 단순히 기획자, 디자이너, 서버 개발자, 안드 개발자, 마케터라는 식으로만 이름이 붙어있을 뿐이었죠. 그래서 어떤 뷰에 대해 기능부터 UI 디자인 요소까지 얘기할 때는 모든 개발자들을 언급해서 다같이 얘기하기도 했어요.

물론 이러한 과정에서 팀 내 협력도가 높아지기도 했지만, 론칭을 위해 부스트를 달아야 하는 시점에서는 R&R을 명확하게 정의하고, 서로의 R&R에 대해 인지하는 것이 중요하다고 생각했습니다. 더불어, 마케터 희경님이 들어오게 되면서 ‘앱’ 위주로 흘러가던 팀의 업무 방식을 바꿀 필요성이 있다고 생각했습니다.

티플의 조직 구조 및 역할

그래서 위와 같이 크게 Gross-Part와 Dev-Part로 파트를 분할했습니다. 각 파트의 리드는 혜정님, 채현님이 맡아주시게 되었어요. Gross-Part는 시장과 유저를 연결하는 것에 초점을 두면서 프로덕트의 성장을 위한 전략들을 고민하는 파트로 정의했습니다. 반면에 Dev-Part는 프로덕트의 성장과 사용성을 위해 유저 관점을 반영해 개발하는 파트로 정의했습니다. 두 파트의 공통점은 바로 ‘유저’인데요. 서비스의 앞단이나 뒷단이나 모두의 업무의 우선순위가 ‘유저’가 되어야 한다고 생각했기 때문입니다.

이렇게 정의된 구조를 통해 적어도 ‘이 부분에 대해서는 누구한테 물어봐야 하지?’하고 고민할 필요가 없게 되었습니다.
더불어 협업이 필요한 업무에 대해 더 원활하게, 효율적으로 소통하는 팀이 될 수 있었습니다.

---

 

🚀 팀이 다같이 일하는 시간(feat. 커뮤니케이션 룰)

저번 글에서 살짝 말씀 드렸다 싶이, 티끌은 ‘사이드 프로젝트’이기 때문에 팀원 모두가 100%를 프로덕트 개발에 시간을 쏟기 어려웠습니다. 그렇다고 각자 개인 업무만 하게 되면, 최종 UI가 넘어가거나 API를 연동하는 부분에서 문제가 생길 수 밖에 없죠. 그래서 remote-work의 한계를 극복하기 위해 활성화 시간과 비활성화 시간을 정해두었습니다.

협업이 필요한 업무에서, 관련된 파트의 의사결정이 미뤄지게 되면 전체적인 프로젝트에도 영향을 끼칠 수 있기 때문이죠. 지금은 12시간으로 되어 있는 활성화 시간도, 각자 파트의 협업 필요 시간이 맞춰 ‘더 축소되는 한편 더 강화‘되었습니다.

티플의 협업 시간

저희 팀의 커뮤니케이션 룰 중에 특별한 점은 바로 ’아무도 일하지 않는 날‘이 있다는 건데요. 사이드 프로젝트로 진행하는 만큼 모두가 쉬는 날에는 ’해야 하는 일‘에 압박 받지 않고 푹 쉬었으면 좋겠다고 생각해 이러한 룰도 만들게 되었습니다. 더 좋은 생산성을 위해서는 더 좋은 휴식도 있어야 하겠죠?!

스프린트의 목표에 따라 유저 반응을 지켜보면서 데이터를 쌓아야 할 때는 쉬는 날을 화, 일요일 이틀로 늘리기도 하고 반대로 피드백을 토대로 새롭게 개발해야 하는 시기에는 축소하기도 하며 유동적으로 진행했습니다.

---

 

🚀 팀의 의사결정 과정 (feat. LP)

커뮤니케이션 만큼 중요한 것이 ‘어떻게 의사결정을 하느냐’인 것 같아요. ‘팀의 의사결정’에 대한 규칙은 의사결정권자가 누구인 지, 의사결정 시점이 언제인 지, 관련되는 후속 업무가 무엇 인지 등 모든 업무에 영향을 끼칠 수 있기 때문입니다. 초기에는 제가 팀 프로젝트를 경험하며 좋았던 룰들을 가져와서 아래 4가지를 공유했었는데요.

초기에 설명한 의사결정, 팀 규칙

프로젝트를 진행하면서, 지켜져서 좋은 것들, 지켜지지 않지만 노력해야 하는 것들, 혹은 우리 팀에 있을 필요가 없는 룰들을 같이 소통해가면서 조금씩 티플만의 규칙들을 만들어나가게 되었습니다.

아래와 같이 잘 되지 않고 있는 것들을 같이 얘기하고, 개선점을 찾아나가고 있어요.

회의에서 규칙에 대해 고민하는 티플

반면에, 규칙을 도입한 이후로 잘 되어가고 있는 것들도 있답니다! 개선해야 하는 부분 뿐만 아니라 우리가 지금 잘 하고 있는 것들을 명확하게 짚고 넘어가는 것도 팀 내에서 동기부여가 될 수 있는 좋은 방법인 것 같다고 느꼈습니다.

---

 

🚀 티플이 새로운 팀원을 받아들이는 방법

현재 팀 블로그를 쓸 수 있는 환경을 조성하는 것부터 인스타그램까지 다양한 방면으로 마케터 ‘희경님‘이 힘써주고 계시다는 걸 알고 계시죠? 사실 저희는 모두 ’마케터‘와 일 해본 적이 없어서 희경님이 처음 팀에 들어왔을 때 어..어떡하지,…어떠카지..하고 고민 했었답니다.

그 중에서도 가장 심각했던 게 바로 ‘회의 내용’이었어요. 마케터가 들어오기 전에는 앱 내 화면의 설계, 디자인, 그리고 구현 가능성에 대한 얘기들을 위주로 했었는데요. 이런 논의 과정이 회의에서 길어지는 게 ‘팀 전체 관점’에서 좋지 않다고 생각했습니다. 그래서 앱 내 화면이나 기능 등의 세부적인 얘기는 더 자주 스레드를 발행하고 댓글로 활발하게 논의하게 되었습니다. 대신에 회의에서는 프로덕트 전체, 그리고 팀 전체가 나아가야 하는 방향이나 목적, 업무 달성률 등을 초점으로 얘기하게 되었죠.

우리가 잘 모르는 ‘마케팅’이라는 분야에 대해 팀원 모두가 더 깊게 인게이지 하기 위해서
저희 팀은 ’셰어 스피치‘라는 문화를 도입했습니다.
사실 어디 유명한 저서에 나오는 멋진 문화같지만 그런 건 아니구요..ㅎㅎ 그저 우리 팀의 현 상황을 가장 잘 풀어낼 수 있는 전략이 무엇일까?를 고민하다가 나오게 되었습니다.

서로의 업무를 더 깊게 이해하고자 도입한 셰어 스피치

셰어 스피치를 도입한 이후로 저희는 회의를 끝내기 전에 각자의 분야에 대해서 2분씩 스피치를 하게 되었는데요.
각자의 관점에서 적용한 기술이나 고민하고 있는 지점들, 도입해보고 싶은 것들에 대해 자유롭게 얘기하면서 마케팅 뿐만 아니라 팀원들의 서로의 업무에 대해 더 자세히 이해하고 공감하게 되었어요. 안드로이드 개발자 유정님께서는 DP, PX와 같은 개념들을 공유해주시기도 했고, 백엔드 개발자 유정님께서는 CloudWatch, ELK와 같은 로그 수집 툴들을 도입하기 위한 고민들에 대해 공유해주시기도 했습니다. 티플 팀은 매주 셰어 스피치를 진행하며 서로의 전문 분야에 대해 공부하고 질문을 던지고 있는데요. 팀 내 결속력도 강화하고 프로덕트에 대한 이해 자체가 높아서 더 시너지를 낼 수 있게 된 것 같습니다.


티플은 앞으로도 우리의 발전을 위한 더 좋은 룰이나 문화에 대해 고민하는 팀이 될 것입니다!
지금까지 티끌의 서비스 기획자 최윤아였습니다.😻



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

티끌(Tikkle) | 나만의 소비 습관 챌린지 - Google Play 앱

 

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