굿닥, 개발 프로세스 대변경!

팀에게 권한과 책임을 최대한 부여한다!!!

내부 개발 조직에게 중요한 의사결정과 개발 방향성에 대한 권한까지 최대한 부여하기 위해서 내부 조직을 크게 변경했습니다.

기존의 개발 조직은 각 부서의 요청사항에 대해서 기획자들이 요구사항을 수집 정리하고, 이를 기반으로 최대한 빠르게 개발하는 형태를 유지하는 형태를 기본으로 운영되었습니다.

이 방식은 부서의 요구사항을 가능한 빠르게 반영하는 것에 목표를 두었지만, 실제 비개발자의 요구사항이 개발자의 관점에서 구현되면서 첫 기획과 완성 형태의 그림이 달라지는 차이를 계속 만날 수 있게 합니다.

그리고, 서비스를 실제 개발하고 있는 서비스 개발자들의 의견이 부서의 요구사항에 밀려서 구현에 채택이 안되거나, 실 부서와 협의하는 과정들이 공식화되지 못하는 부분들이 있었습니다.

굿닥에 데이터 기반으로 의사결정을 지원하기 위한 작업이 1년가까지 진행되었고, 수많은 지표들이 하나의 서비스로 모여지고 시각화되고 있습니다. 뿐만 아니라, 웹서비스의 비기능적인 리팩터링 팩터까지 상당 부분 데이터 중심으로 처리되고 있기 때문에 2018년 8월 대규모의 개발 프로세스를 변경했습니다.

이 변경의 핵심은 Business Developer의 입장으로 BD라고 불리는 각 부서의 업무 전문가가 비즈니스 서비스에 대한 기획을 제시하고, Business Owner인 기획자들이 서버, 앱, 웹, 디자이너들과 보다 긴밀한 서비스에 대한 협의를 나누고, 서로를 설득하고... 하나의 비즈니스를 효과적으로 운영할 수 있는 Squad라는 형태로 업무 조직과 개발 조직을 긴밀하게 구성하는 형태로 변화를 진행했습니다.

기대되는 효과는 비즈니스 운영을 하는 부서의 요구사항과 실 서비스를 개발하는 개발자 간에 서비스 초기 기획 시에 많은 대화를 진행하고, 기획 아이디어에 대한 세부적인 단계까지 Squad내부에서 토의하도록 하는 방법을 사용하는 것입니다.

가능하면, 의미 있는 서비스의 큰 방향성을 제시하는 전략의 의견을 심도 있게 고민하고, 서비스의 운영가치와 개발 내용의 순서들에 대한 권한을 최대한 존중하게 하는 방법으로 의미 있는 서비스에 대해서 Squad내에서 각각의 Sprint로 구분되는 타임박스를 2주 간격으로 운용하게 합니다.

Squad내에서의 의사결정으로 해야 할 것, 미루어야 할 것, 대응할 것 등을 주도적으로 결정하게 하는 이번 시도는 굿닥 내에서도 과거에 시도된 적이 있지만, 실제 마스터가 조율해주지 못해서 실패한 경험을 가지고 있습니다.

이번 절차 변경과 4개의 Squad로 구분되는 개발 구조의 변화를 통해서, 굿닥의 서비스 개발 조직이 좀 더 기민하고 재미있는 개발 조직이 되도록 변화합니다.

아마도... 3~4개월 정도 충분하게 진행시킨 후에.. 이 구조 프로세스 변경에 대한 결과가 리뷰될 것 같습니다.

각 단계별 세부적인 프로세스나 리뷰, 리팩터링, 토의와 의사결정 등이 세부적으로 정의되었는데... 의미 있는 개발이 즐겁게 진행되기를 기원합니다.

굿닥 서비스 개발 스쿼드 모두 파이팅!