초기 스타트업 서비스 개발팀의 효율적인 업무 프로세스에 대하여

초기 스타트업 서비스 개발팀의 효율적인 업무 프로세스에 대하여

MyVenus 서비스 로고입니다.

인도네시아 / 동남아 현지를 중심으로 운영 중인 MyVenus 뷰티 플랫폼 서비스는 한국인 멤버로 팀을 이루어 진행하였습니다. 운영은 인도네시아의 현지 팀이 따로 있으며 한국의 팀은 서비스의 기능 단위 제품을 주로 생성하는 담당을 하고 있습니다.

 

한국팀에서 저는 프론트엔드 포지션을 맡아 서비스 앱, 서비스 웹, Admin 웹/앱 등등 서비스를 운영하고 필요한 운영 유지보수/새로운 피쳐 개발/프로젝트 등등을 참여하고 발전시켰습니다.

 

물론 서비스의 하나의 새로운 기능이 나오기까지 물론 프론트엔드 개발자인 저 혼자서 뚝딱 만들어내고 있지 않고 있습니다. 하나의 서비스 기능 단위 제품을 생성하기 위해서 기획/디자인/개발/QA 단계를 거쳐 생성합니다. 즉 지금 현재 제가 속한 한국팀은 이 단계를 거치기 위한 소수의 팀이라고 말하고 싶습니다.

 

MyVenus - Aplikasi Perawatan Kecantikan Terlengkap & Terpecaya #1 di Indonesia

 

간단하게나마 서비스 론칭 후 1년 넘게 우여곡절을 통해 팀이 기능 단위 개발 / 운영 유지보수 개발을 더 효율적이고 빠르게 하기 위한 고찰을 정리하여 기록하고자 합니다.

 

저희 한국팀은 그로스 프로덕트팀이라고 부르고 있습니다. 그로스 영어로 성장입니다. 성장하는 서비스를 만들고자 하는 취지로 이름을 지었습니다.

 

• PM (기획 / 일정 관리 / 일손이 부족하면 프론트엔드 개발 가능) - 1명
• 디자이너 - 1명
• 프론트엔드 개발자- 1명
• 백엔드 개발자 - 2명

 

현재는 이렇게 팀이 이루어져 있습니다.

 

 

 

 

 

전체적인 팀 업무 프로세스

---

-> 사내 운영진/경영진과 한국의 프로덕트팀과의 회의를 통한 서비스 발전을 위한 기능 제품 생성 진행 결정
-> PM의 기획 시작
-> 완성된 기획안을 통한 디자이너 / 개발자 Team 회의 및 검토
-> 확정된 기획안 디자이너에게 전달 및 디자인 안 제작 진행
-> 확정된 기획안 / 디자인안 개발자에게 전달 및 개발 일정 산정
-> 개발 시작
-> 개발 완료
-> QA 테스트 진행을 위한 스테이징 환경에 개발 완료된 버전 배포
-> PM 기능 단위 QA 테스트 + 디자이너 디자인 QA 테스트 동시 시작
-> QA 테스트 완료
-> QA 테스트 결과 개발자에게 전달
-> QA 테스트 결과 검토 및 QA 테스트 결과 사항을 토대로 한 재개발 시작
-> 2차 QA 테스트 시작... 3차 QA 테스트... (반복)
-> QA 테스트 통과 완료
-> 프로덕션 환경에 배포
-> 운영진 / 경영진 업데이트된 기능 피쳐 프로덕션 배포 공지

위의 같이 저희 팀이 하나의 프로젝트 단위 / 새로운 피처 단위의 기능 제품을 뽑아내기 위해 거치는 프로세스입니다.

런칭 초기에  여러 가지 불편한 점과 효율적이지 못한 프로세스를  많이 겪으며 발전시킨 형태입니다.

 

 

 

 

 

1.  사내 운영진/경영진과 한국의 프로덕트팀과의 회의를 통한 서비스 발전을 위한 기능 제품 생성 진행 결정

 

하나의 새로운 기능이나 프로젝트를 진행하기 전에 운영진/경영진과의 회의를 통해 앞으로 개발이 필요한 새로운 피처 기능들과 프로젝트를 분기별로 결정하고 진행하고 있습니다.

 

분기별 회의 때 많은 결정이 이루어집니다. 저희 프로덕트 팀 또한 회의를 통해 이 신규 개발 진행이 필요하다고 생각하고 별말 없이 동의한다면 바로 회사의 PM분이 기획을 시작합니다.

 

 

 

 

 

2.  PM 기획 시작 -> 완성된 기획안을 통한 디자이너 /  개발자 전체 Team 회의 및 검토

 

기획안이 완성된다면 전체 Team 회의를 개최하여 함께 기획안을 검토하고 디자인의 방향성, 개발이 가능한지, 개발을 한다면 어떻게 설계하고 진행할 건지 많은 의견과 이야기가 오고 갑니다.

 

아주 중요한 시간이고 가장 집중해야 하는 시간입니다. 이때 정확히 짚고 넘어가야 추후 진행할 프로세스에 차질이 생기지 않을 수 있으며 2번 일하는 불상사를 예방할 수 있습니다. 특히 개발에서 있어 중요한 회의입니다. 설계, 기술의 구현 가능성 등등을 재보기 때문이죠.

 

이해가 안 가는 것이나 애매한 것들은 이때 바로바로 물어보고 컨펌을 받는 편입니다.

 

회의는 최대한 적게, 하지만 할때는 집중적으로 전투적으로

 

 

 

 

 

3.  디자인 안 제작 진행 -> 확정된 기획안 / 디자인안 개발자에게 전달 및 개발 일정 산정

 

전체 Team 회의 및 검토를 통해 기획이 확정되었으면 바로 디자이너가 디자인 제작에 돌입합니다.

프론트엔드 개발자는 디자인이 나와야 개발을 시작하고 일정을 산정할 수 있기에 그 사이에 저는 쌓여있는 개발 테스트들을 처리하거나 운영 보수 및 밀린 개발들을 처리합니다. 동시에 앞으로 개발한 기술 서칭 또한 진행합니다.

백엔드 개발자는 디자인 안이 바로 필요 없기 때문이 개발 일정을 산정하고 바로 작업에 들어갑니다.

 

디자인이 끝나면 프론트엔드 개발자인 저에게 디자인 안이 오게 되고 저는 바로 개발 일정을 산정하기 위해 최대한 많이 개발 업무 태스크를 쪼개고 쪼개 너 정확한 개발 일정을 산정합니다. 저희 팀은 업무의 효율을 위해 Jira라는 업무 관리 서비스는 이용합니다.

Jira | Issue & Project Tracking Software | Atlassian

 

 

 

 

 

4.  개발 시작과 개발 완료 -> QA 테스트 진행을 위한 스테이징 환경에 개발 완료된 버전 배포

 

최대한 일정산정대로 개발 일정을 맞추려고 노력합니다. 물론 SI 외주 프로젝트는 아니기에 데드 라인이 부담스럽게 정해져 있는 것은 아니지만 개발자 자신에게 데드 라인이 없다면 나태해지고 개발 속도 및 효율은 심리적으로 떨어지는 것은 사실이기에 일정을 꼭 지키려고 노력합니다.

 

개발이 완료되면 내부적으로 개발자 QA도 진행하며 PM / 디자이너 분들께 QA 테스트를 할 수 있도록 스테이징 환경을 준비하고 스테이징 배포를 진행합니다. 스테이징 환경 테스트는 웹 / 앱 둘 다 공통입니다.

QA 테스트를 위해서 테스트 플라이트를 이용해야한다. 안드로이드 APK 파일로 전달한다. 공지는 정해진 Slack에서 개인적으로 미리 정해둔 메세지 탬플릿으로 하는 편이다.

 

 

 

 

 

5.  PM 기능 단위 QA 테스트 + 디자이너 디자인 QA 테스트 동시 시작 ->... -> QA 테스트 결과 검토 및 QA 테스트 결과 사항을 토대로 한 재개발 시작 -> 2차 QA 테스트 시작... 3차 QA 테스트... (반복) -> QA 테스트 통과 완료

 

저희 팀은 QA 테스트에 대하여 많은 고민을 과거해왔습니다. QA 테스트가 효율적으로 진행하지 못하여 시간을 빼앗기고 제대로 된 QA가 진행되지 못하여 이슈를 걸러내지 못해 실제 프로덕션에서 치명적인 이슈가 발생하거나 등등 많은 일들이 있었습니다.

 

특히 효율적인 QA을 진행하기 위한 환경 그리고 명확하지 않은 프로세스가 부족하여 시간을 낭비하고 있는 것이 가장 큰 이슈였습니다.

 

정리하여 3가지 정도 개선을 하였습니다.

 

1. 저희 QA 테스트를 빠르게 할 수 있는 개발 환경 구축을 우선적으로 하였습니다. Slack 메신저에 테스트를 위한 앱 APK 파일 혹은 테스트 플라이트 알림 공지 등 업무 채팅 메신저에서도 프로세스를 구축하였습니다.

 

2. 디자인에 대한 QA가 추가로 필요하다고 깨달았으며 PM분의 기능 단위 테스트 그리고 디자인적인 테스트를 둘이 동시에 진행하도록 프로세스를 정립하고 진행하도록 규칙을 정하여 바로바로 QA 결과가 나오도록 하였습니다.

 

3. PM분의 기능 단위 QA는 물론 디자이너분 또한 QA를 통해 발견한 이슈 사항들을 직접 바로 Jira의  업무 티켓이라는 것을 등록하여 개발자가 바로바로 QA 결과에 대해 대응할 수 있도록 하였습니다.

 

Jira는 업무의 효율을 진짜 높여준다. 사용해야한다.

 

 

 

 

 

6.  QA 테스트 통과 완료 -> 프로덕션 환경에 배포 -> 운영진 / 경영진 업데이트된 기능 피쳐 프로덕션 배포 공지

 

길면 QA 테스트 3차까지 가기도 합니다. 그래도 잘 정립된 프로세스 덕에 QA가 정확하고 빠르게 끝나 QA테스트를 하는 사람, 팔로업하는 개발자들 서로서로 편해진 것을 몸소 깨달았습니다.

 

QA 테스트가 최종 완료되면 프론트엔드 개발자인 저와 백엔드 개발자 분과 프로덕션 배포에 대한 간단한 회의를 통해 프론트단 / 백엔드단 동시에 프로덕션 배포 합니다.

 

Web과 다르게 App은 스토어 심사가 있어 스토어 심사 리젝 이슈 발생 / 심사 시간 등을 고려하여 진행합니다.

사내 전체 공지 채팅방에 미리 정해둔 메세지 탬플릿으로 항상 공지한다.

 

 

 

 

 

마무리하며...

---

견고하고 어느 정도 기반이 되어 있는 서비스 회사들은 위의 과정보다 더 치밀하고 더 깊이감이 있다는 것은 물론 사실입니다.

그래도 제가 지금까지 위의 같은 프로세스를 통해 IT 서비스의 회사가 어떻게 돌아가고 어떻게 돌아가야 하는지 직접 경험했다는 것이 개발자로서 매우 가치 있던 시간들이었습니다.

앞으로도 계속 팀의 프로세스를 발전시키고자 하는 것이 목표입니다. 이 경험들은 만약 미래에 팀이 와해되어도 다시금 이런 효율적인 프로덕트 팀을 단시간에 꾸릴 수 있다고 생각하게 되었습니다.

 

 

감사합니다!