Stories & Opinions
Category
- Opinions of Bass
Written by
이태양 대표
Date
Empty
안녕하세요. 이태양입니다.
Growth partner로 베이스인베스트먼트에 합류 후 두 달 가량이 흘렀습니다. 많다면 많고 적다면 적은 20개 팀을 만나보니 사업영역, 팀의 규모, 서비스 형태 등에 따라 다양한 고민거리가 있겠지만 심심찮게 올라오는 주제 중 하나가 바로 서비스 개발 방법론(?) 입니다. 지켜지지 않는 스프린트 일정, 적절한 MVP 스펙 정의, 기획자-디자이너-개발자 간의 커뮤니케이션 등 고객에게 멋진 제품을 제공해주기 위해 노력하면서도 함께 일하다 보면 문제가 생기기 마련이죠. 각각의 이슈에 대해서도 여러 가지 방법이 있겠지만 근본적인 해결을 위해 다음과 같은 비유를 들어 이야기하곤 합니다.
스타트업은 아직 시장에서 검증되지 않은 솔루션을 만들고 있고 이것은 한 치 앞도 보이지 않는 칠흑 같은 밤에 징검다리를 찾아 건너는 과정과 같다.
저 강을 건너면 있을 무엇인가를 발견한(발견했다고 믿는) 사람이(창업가) 함께 강을 건널 사람들을 모아서 강 건너기에 도전합니다. 한 치 앞도 보이지 않는 이 상황에서 조심스럽게 물가에 발을 디디며 우리가 올라설 디딤돌이 있는지를 확인하며 앞으로(직선이 아닌 지그재그 일지 언정) 강을 건너는 모험이죠.
자 그럼 이 강을 빠르고 안전하게 건너는 방법은 무엇일까요?
1.
디딤돌이 있을 확률이 높은 곳 으로 발을 내디뎌야 합니다. (좋은 가설)
2.
강에 빠지지 않을 만큼 최대한 여러 번 발을 내디뎌 디딤돌을 찾아야 합니다.
(시간은 한정적인 자원이기에 많은 시도 = 빠른 실행)
(시간은 한정적인 자원이기에 많은 시도 = 빠른 실행)
고로, 강을 빠르게 건너는 방법 = 좋은 가설 * 빠른 실행
좋은 가설로 빠른 실행을 할 수 있게 해주는 개발방법론으로 우리가 흔히 이용하는 것이 애자일 방법론 중 스크럼입니다.
규칙적으로 반복되는 스프린트 기간을 통해 일정한 속도로 새로운 디딤돌을 찾도록 하고, 한 주기(보통 2주)를 제한하여 너무 무게 중심을 싣지 않도록(릴리즈 스펙을 최소화) 하고 데일리 스크럼을 통해 단순 실행이 아닌 목표를 이루기 위한 유기적인 커뮤니케이션을 유도하며 회고를 통해 더 좋은 가설을 세우고 실행하는 선순환을 돕습니다.
그러나 많은 팀이 스크럼 프레임워크 자체에 매몰되어 다음과 같은 문제를 겪고는 합니다.
•
스프린트 산출물을 찍어내는 것을 목표로 하고 그것에 만족함
•
아무런 의미 없이 일정 체크하는 데일리 스크럼 미팅
•
개선 없이 불평만 하는 회고 (기능의 무의미, 일정 못 지킴 등)
예를 들어 포도 마켓이라는 하이퍼로컬 중고 마켓이 있다고 해봅시다. 이 회사의 디스커버리 팀은 이번 스프린트에서 해시태그 검색 기능을 넣자는 아이디어를 냈습니다. 기존 키워드 검색 기능보다 쉽고, 트렌디한 느낌을 줄 수 있을거라는 의견이었죠. 스프린트 둘째 날, 유관부서에서 도와줘야 하는 부분이 크고 복잡하며 기능 추가 이전으로 되돌리기 어려워 일정을 맞추기 어렵다는 개발자의 의견이 공유됩니다. 하지만 이미 하기로 했고 다른 팀들과 경영진에게도 개발하겠다고 공유한 상황이라 어떻게든 개발을 완료하기로 결정합니다. 결국 4주짜리 장기 계획으로 변경하고 밤을 새워서 릴리즈 날짜를 맞춥니다. 어려운 미션이었지만 해냈다고 자축하며, 해시태그 관련 추가적인 기능(유해 키워드 차단 및 키워드 즐겨찾기 관리 기능 등)을 다음 스프린트로 준비합니다.
위 예시에서 디스커버리팀은 더 좋은 가설을 세우거나, 더 빠른 실행을 할 수 있었습니다.
디딤돌이 있을 확률이 높은 곳 찾기 ( 좋은 가설 )
1.
가설 검증을 위해 기존 키워드 검색을 통한 사용성/만족도를 확인하고 기능의 형태와 목표를 더 명확히 할 수 있었어요.
2.
릴리즈 후 바로 이어지는 추가 기능 개발이 아닌, 사용자들의 검색패턴 및 구매전환율 등의 결과를 통해 더 좋은 가설을 세울 수 있었어요.
최대한 빠지지 않을 만큼만 많은 시도 ( 빠른 실행 )
3. 기존 키워드 검색의 UI만 해시태그 형태로 바꾸어 유관부서의 업무량을 줄이고, A/B 테스트를 통해 가설 검증이 가능했어요.
4. 데일리 스크럼에서는 개발자가 스펙이 무거워진다는 의견을 주었을 때 가설에 집중한 더 작은 스펙을 고려해보았으면 어땠을까요?
3. 기존 키워드 검색의 UI만 해시태그 형태로 바꾸어 유관부서의 업무량을 줄이고, A/B 테스트를 통해 가설 검증이 가능했어요.
4. 데일리 스크럼에서는 개발자가 스펙이 무거워진다는 의견을 주었을 때 가설에 집중한 더 작은 스펙을 고려해보았으면 어땠을까요?
정리하자면,
•
좋은 가설 을 세우기 위해 보다 면밀히 문제의 본질을 살피고,
•
가설 검증을 위한 핵심 기능에 집중하여 빠른 실행 을 이루고,
•
실행의 결과를 객관적 으로 바라보고 또 다른 좋은 가설을 설계해 나가야 합니다.
스크럼은 발견을 하기 위한 프레임워크입니다. 미래를 예측할 수 없는 복잡한 환경에서 효율적으로 진화하기 위한 프레임워크입니다. 스프린트를 통해 추가된 기능이 아닌 그 기능을 통해 사용자 만족도가 증가하고 이를 통해 서비스와 비즈니스를 향상시키는 부가 가치를 만들어 내는 것이 목표입니다. 이런 목표를 달성하지 못한 기능 추가들은 훗날 서비스의 복잡도를 높이고 우리가 제공하려는 고객 가치를 희석하여 강을 건너는 우리를 더 무겁게 만듭니다.
예시를 위해 스크럼을 언급했지만 개발 방법론에 정답은 없습니다. 오래전에 정답이라고 이야기되었던 다양한 방법론들이 지금은 구시대의 유물이 되었죠. 우리의 시장, 우리의 고객, 우리의 서비스, 그리고 우리! 에게 맞는 우리만의 방식을 찾아가는 과정에서 무엇을 기준으로 해야 하는지에 대한 고민을 잠시 해보고자 이야기를 시작했습니다.
Subscribe to 'BASS Ventures'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'BASS Ventures'!
Join Slashpage and subscribe to 'BASS Ventures'!
Subscribe
1
