Introduction
프로젝트 “밍글”의 백엔드 리더이자 부리더로써 프로젝트를 진행하며 다양한 직군과의 협업 및 커뮤니케이션 경험을 쌓을 수 있었다.
백엔드 개발자 사이의 소통, 백엔드와 프론트엔드의 소통, 개발자로써 기획자(비개발자)와의 소통 그리고 디자이너와의 협업과 소통을 하며 겪었던 어려웠던 점과 해결했던 사례를 적어보고자 한다.
마지막으로, 소통 방식에 대한 고민 그리고 현재의 협업 방식에 대해 고민했던 과정을 적어보고자 한다.
다양한 직군과의 협업 및 얻은 점
“밍글”은 현재 프론트엔드 4명, 백엔드 4명, 디자이너 1명, 기획/마케터 2명 총 11명으로 이루어져 있습니다.
백엔드 개발자이자 부리더로써 초기 시장 조사, 요구사항 분석, 프로토타입 제작, 백엔드 개발 및 배포까지 하는 전체적인 프로세스를 담당하였고, 현재 지속적인 모니터링과 추가 기획 및 개발을 하고있습니다.
Cross-functional 한 팀이었기에 개발자들도 기획에 참여하며 프로덕트에 대해 높은 이해도를 가지고, 자신이 해야하는 일에 대한 명확한 이유와 동기를 얻을 수 있었습니다.
이 과정을 경험하면서 각 개발 파트별 파트장들과 디자이너, 마케터와의 매주 회의를 통해 위 프로세스를 거치며 앱을 기획해 나갔고,
이에 기획자 및 디자이너와의 협업, 프론트 개발자와의 밀접한 협업을 통해 각 분야와 그들의 입장에 대해 더 자세히 알아갈 수 있었습니다.
예를 들면, 디자이너님과의 협업을 통해 UX, UI적인 부분을 많이 알 수 있었고, 또 프론트엔드와 디자이너가 협업하는 모습을 보며 디자인을 실제 프론트엔드 앱으로 구현하는것의 어려움을 볼 수 있었습니다.
또한 프론트엔드와 협업하며 백엔드와 프론트엔드가 어떻게 연결이 되고, 이러한 화면에서는 어떻게 API를 짜야 하며, 화면 별로 어떠한 부분을 API로 채우거나 프론트엔드에서 처리하는지에 대한 이해,
그리고 어떠한 API Response를 내려주는게 좋을지 계속 꾸준히 소통해가며 전반적인 이해도를 쌓을 수 있었습니다.
위와 같은 협업 경험을 통해 PM분들 뿐 만 아니라 소프트웨어 엔지니어나 프로덕트 디자이너와도 원활한 소통을 할 수 있었고, 또한 새로운 기능을 기획할 때도 협업 경험을 통해 얻은 지식을 토대로 PM, 개발자,디자이너의 입장을 생각해보며 기획하는데 도움이 되었습니다.
예비 신입생 게시판 기획
신입생 게시판 관련 기획 도중 위와 같은 협업을 통해 얻은 인사이트와 커뮤니케이션 역량을 토대로, 프론트엔드, 백엔드, 기획자, 그리고 사용자의 입장을 모두 고려해 기능을 설계하고 설득해 모두에게 합리적인 결과를 도출해냈던 사례를 적어보고자 합니다.
기획자 사이에서의 초기 기획은 현재 게시판 카테고리의 탭 중 잘 쓰이지 않는 탭을 예비 신입생 탭으로 임시적으로 바꾸는 것이었습니다 (프론트엔드 변경 필요). 그리고 신입생들은 그 카테고리에 대한 접근만 가능하며, 재학생들이 사용중인 다른 카테고리 탭은 접근이 불가능하게 하는 방안이었습니다.
하지만 이는 개발적으로 프론트엔드의 UI 변경, 즉 프론트엔드의 카테고리 UI 변경 및 권한 별 서버에서 내려주는 응답값으로 다른 카테고리 탭의 접근을 막는 화면을 개발해야했습니다.
그렇게 된다면 유저들까지 앱 업데이트를 해야 적용이 될 뿐만 아니라 현재 유지중인 카테고리 탭의 변경을 통해 유저들의 혼란을 빚을 수 있는 안건이이었습니다.
또한, 프론트엔드의 개발 기간이 백엔드에 상대적으로 긴 점을 고려해 최대한 프론트엔드의 변경을 피하고 싶었습니다.
이에 저는 게시판에서 신입생을 위한 탭을 따로 만드는게 아닌 신입생들이 자유롭게 기존 게시판에 글을 게시하되, 신입생들에겐 신입생들의 글들만 보이게 하는 방법을 제안했습니다.
이 방법은 기존 백엔드 API의 응답값만을 바꿔 기능을 구현함으로써 유저들의 불편을 초래하지 않을 뿐만 아니라, 커뮤니티를 더 활성화 시키고 기존 유저들의 높은 접근성으로 인해 신입생들끼리가 아닌 선배들의 조언도 더 쉽게 받을 수 있음으로서 모두가 윈윈 할 수 있는 의견으로 팀원들을 설득했습니다.
이와 같이 저는 여러번의 기획 회의에서 백엔드,프론트엔드 개발적 지식 그리고 유저 입장, UX등 다양한 근거와 함께 논리적으로 커뮤니케이션 하고 설득을 하는 과정을 거친 적이 있습니다. 이에 개발자, 개발 기간, 앱 자체, 그리고 유저들 모두에게 합리적인 결과를 도출 해냈습니다.
소통 방식에 대한 고민 그리고 현재의 방식
협업을 하면서 어렵고 고민됐던 부분은, 어떻게 하면 회의와 의사결정을 더 효율적으로 진행하는가 였습니다.
처음 프로젝트를 시작할때는 운영진(회장,부회장 + 개발 파트별 파트장)들이 곧 기획자였습니다. (즉 회장, 부회장(나, 백엔드 파트장), aos 파트장, ios 파트장)
이때는 앱 자체를 기획해나가는 시기였기에 개발의 관련된 기획 회의들이 주를 이루다보니 운영진들끼리 개발 미팅 겸 기획 미팅을 진행했습니다.
이렇게 정해진 개발 사항이나 데드라인 등은 각 파트별 개발 미팅에서 파트장들이 전달하였습니다.
하지만 앱을 출시하고 기획자 및 마케터의 필요성을 느껴 추가로 영입 한 후, 앱의 개발을 위한 기획보다는 비개발적인 기획 회의도 많아졌습니다.
이에 기존에 운영진 미팅을 기획 미팅으로 하게 된다면, 비개발적인 기획 회의에 참여하지 않아도 되는 각 파트별 파트장들이 비개발적인 요소에도 시간을 뺏기게 됐습니다.
이에, 기존 운영진 미팅과 기획 미팅을 분리하고자 했습니다.
이제는 기존 운영진 미팅때는 개발에 관련된 안건을 얘기하고, 기획 미팅때는 기획자/마케터/디자이너가 함께 홍보 방안이나 신규 서비스, 비즈니스 모델 등을 상의했습니다.
하지만 기획 미팅에서도 위에 언급했던 신입생 게시판 같은 개발쪽의 고려가 필요한 안건이 나오고, 이와 같이 기획자 , 마케터, 디자이너끼리 회의를 하고 결정된 사안은 개발자와의 추가적인 소통을 야기합니다. 만약 새로운 기획이 개발적으로 반려된다면 다시 처음부터 기획을 해야합니다.
하지만, 이를 방지하기 위해 개발자가 기획 회의에 항상 들어가는것은 개발자 입장에서 시간 소요가 큽니다.
그럼에도 불구하고, 이러한 점을 감수하더라도 한 회의에서 개발을 고려해 기획 안건을 함께 얘기하는게 더 효율적일거라 판단해, 이에 현재 밍글에서는 리더 및 부리더(저)와 기획자, 마케터와 함께 매주 기획 회의를 진행하고 있습니다. 개발자 입장이 고려되어야 하는 기획 안건을 함께 조율하기 위해서입니다.
그리고 여기서 결정된 사항들을 개발 파트별 팀장들이 모이는 개발 미팅에 전달합니다. 개발 미팅에서는 새로운 기능에 대한 API Spec을 맞추고, 개발 기간을 정합니다.
각 파트별 팀장들은 개발 미팅에서 결정된 사항들을 각 파트별 팀원들에게 전달합니다. 그리고 팀원별로 개발 업무를 분담합니다.
마무리
백엔드 개발자 사이의 소통, 백엔드와 프론트엔드의 소통, 개발자로써 기획자(비개발자)와의 소통 그리고 디자이너와의 협업과 소통을 하며 배운 점과 이를 통해 신입생 게시판 기획 문제를 해결했던 사례,
그리고 소통 방식에 대한 고민 그리고 현재의 협업 방식에 대해 고민했던 과정을 적어보았습니다.
이와 같이 프로젝트 “밍글”을 통해 팀으로서 하나의 프로덕트를 처음부터 만들고 꾸준히 유지 및 업데이트를 하며 협업 능력 및 커뮤니케이션 역량을 쌓을 수 있었습니다.
이러한 값진 경험이 현업에서 어떻게 응용될 지 궁금하고, 큰 도움이 되길 바라며 이번 글 마치겠습니다.
감사합니다.
