SaaS개발 성공방정식(?)

협업툴 마림바이야기#11

#스포티파이 #개발프로세스 #SaaS개발 #성공방정식 #애자일팀 #크로스펑셔널 #JTBD #애자일 #협업툴

여러분들은 SaaS 제품으로 어느 정도의 성공을 거둔 사람들에게 '어떻게 개발했는가?'라고 물어본 적이 있는가? 일반적으로 아마도 다음과 같은 대답들을 들을 수 있을 것이다.

'성공을 위해 무엇이든지 해보는 거다.'

'사용자 많이 만나고 피드백 듣고 반영하는 거지'

'죽지 않을 만큼까지 열심히 하는 거지'

이 대답들은 모두 맞는 말이다. 사실상 '무엇이든지 열심히 하면서 사용자 많이 만나고 피드백을 받는다'가 성공의 유일한 방법이다.

하지만 안타깝게도, 이렇게 노력하더라도 실패하는 제품들은 시장에 너무나 많다. 통계적으로 보면 아이디어 단계부터 제품을 개발하여 상업적으로 제품이 성공할 확률은 전체의 1/3000 정도밖에 안된다. 현실적으로 볼 때,  우리는 어쩌면 이 방정식의 답을 끝까지 구하지 못할지도 모른다.

그럼에도 불구하고, 오늘도 이에 도전하는 분들을 위해 '무엇이든지 열심히'라는 추상적인 말을 구체적으로 풀어 보려고 한다.

개발할 제품의 산업적 위치와, 제품 특성과, 상황에 따라 조금씩 접근하는 방법은 달라져야 하겠지만, 이제부터 설명할 방식은 성공한 많은 회사들이 해온 방식이다. '스포티파이'도 '캔디크러시사가'도 아래의 일하는 방법으로 탄생했다.

다시 워크숍 장소로 돌아가 보자.

------

JTBD의 설명 후 존은 JTBD와 연결되어 시장에 통하는 제품(Product market fit)을 만들기 위한 단계 들에 설명을 시작했다

"전체적으로는 JTBD의 프로세스를 그대로 따릅니다. 이터레이션이 중심이죠. 다섯가지의 단계가 있지만 단계마다 모두 피드백을 반영하는 체계가 기본입니다. 다만, 단계마다, 집중하는 목표와 리소스 투입의 질과 양이 다를 수 있죠. 이를 쉽게 설명하기 위해 음원 스트리밍 회사 스포티파이가 그린 그림을 참고하겠습니다."

#1 제품 아이디어 단계(Product idea)

존은 계속 설명을 이어나갔다.  

"제품 아이디어 단계의 목표는 신제품에 대한 아이디어를 가지고 스폰서십을 받는 것입니다. 제가 여러분들을 모을 때 초기 문제와 해결방법을 정리하여 경영진에 보고한 내용이 이 단계입니다. 이 아이디어도 결국 앞서 설명한 JTBD와 결을 같이한다는 것을 잊지 않았으면 좋겠습니다. (1) 고객을 정의하고, (2) 인터뷰를 통해 고객의 문제를 찾으며, (3) 인터뷰에서 나온 인사이트를 정리하고, (4) 고객에게 우리의 아이디어가 실제 문제를 해결하는지 테스트하고 학습하는 과정을 거쳐야 합니다."  

"이때에도 실제 무언가를 만들어야 하나요? 고객에게 우리의 아이디어가 실제 문제를 해결하는지 어떻게 테스트할 수 있을까요?"

케이트가 질문했다.  

"아, 케이트 좋은 질문 고맙습니다. 다음 단계들과 비교할 때 이 단계의 모든 활동은 훨씬 단순할 겁니다. 어떻게 '이 아이디어를 당신의 현실에 적용하면, 문제가 해결될까요?'라는 질문의 답을 듣는 정도 이겠죠"

"이 단계는 보통 어떤 구성원들이 참여하나요?"

개발자 키가 물었다.

"뭐 제가 여러분들을 모시기 전에 경험한 대로 것과 같습니다. 아이디어 발제자 한 명 또는 마음 맞는 두 명 정도의 최소한의 인력이겠죠. 그리고 경영진의 스폰서십을 얻고 다음 단계로 나아갑니다. 우리는 다행히 성공적으로 스폰서십을 얻어 이 자리에 앉아 있는 겁니다."

#2 아이디어 검증 단계(Think it)  

"그리고, 오늘부터 우리가 해야 할 단계가 바로 아이디어 검증 단계입니다."

존은 계속 설명을 이어갔다.  

아이디어 검증 단계는 이전 단계인 제품 아이디어 단계에서 정의한 아이디어를 실 사용자에게 의미 있는 사용자 시나리오로 옮겨 테스트하는 단계이다. 여기에서 사용자 시나리오란  사용자가 시스템을 활용하여 업무를 수행할 때 수행 시작부터 수행 완료까지의 업무 시나리오를 흐름 의미한다.

아이디어 검증 시는 가장 단순한 형태로 업무 시나리오를 만드는 것이 중요하다. 가장 단순한 형태라야 사용자에게 테스트할 때 명확하게 사용자의 문제가 해결되었는지 확인하기 쉽기 때문이다. 이 때문에 시나리오의 주 흐름 외에 대안 흐름이나 예외 흐름은 고려하지 않는다.

 여러 가지 방식으로 아이디어를 검증할 수 있지만,  일반적으로 디자인 프로토타입을 활용한다. 디자인 프로토 타입을 보여주고, 질문을 통해 실제 문제가 해결되는지 질문하거나, 디자인 프로토타입을 클릭할 수 있게 만들어 검증할 수도 있다.

사용자는 한 가지 시나리오에 정확한 타깃으로 정의된 사용자 5~6명 정도 검증하는 것이 적당하다. 로라 클레인(Laura Klein)이 집필한 린 UX스타트업이라는 책을 보면, 한 시나리오를 대상으로 5명 정도 검증하면, 정규분포에서 사용자의 90% 정도의 케이스들을 커버할 수 있다고 언급되어 있다.  

이 단계에서는 빠르게 변화하는 것이 중요하다. 사용자들이 시나리오를 경험하고, 정의한 문제에 대한 솔루션이 되기에 부족하다는 반응을 보이면, 재빠르게 시나리오를 수정해야 한다. 이를 피벗(Pivot)이라 한다. 그리고, 수정된 시나리오로 다시 한번 사용자에게 테스트한다. 자연스레, 아이디어 검증 단계에는 지속적으로 보완한 시나리오를 테스트하기 위해 많은 사용자들을 만나야 하고, 이를 통해 시나리오를 검증하는 일이 일어난다.   

아이디어 검증 단계에는 2가지 역할 정도가 필요하다. 아이디어를 최초 만든 사람을 프로덕트 매니저라고 하면, 사용자 테스트와 프로토타입을 빠르게 제작할 수 있는 디자이너 정도이다. 물론 초기부터 기술적인 역량이 많이 필요한 제품의 경우 개발자가 포함되기도 한다. 커뮤니케이션의 복잡화는 팀 전체의 속도를 늦추기 때문에 일반적으로 2~4명 정도가 이 단계에 팀원으로 참여한다. (물론 규모와 하는 일의 종류에 따라 다르다)

#3 동작하는 MVP 개발단계(Build it)

아이디어 검증 단계를 거쳐 MVP 개발 단계로 가기 위한 스폰서십을 얻은 뒤, 가장 먼저 해야 할 일은 실제 시스템으로 구축할 개발 인력을 리크루팅 하는 것이다.  

이때 채용하는 개발자는 작성한 시나리오를 처음부터 끝까지 개발할 수 있는 역량이 있어야 한다. 때문에 클라이언트, 서버, 디봅스 환경 개발 등의 역할 구분을 하지 않아도 되는 풀 스택 개발자를 참여시키는 것이 가장 이상적이다. 하지만 풀 스택 개발자를 참여시키는 것은 매우 어려운 일이라, 각각의 전문성을 가지고 있으면서 다른 전문성의 개발자들과 늘 협업할 수 있는 태도를 가진 인력을 채용하는 것도 가능하다.

다만, 최소한의 인원을 모아야, 기존에 팀에 존재하던 2~4명의 프로덕트 매니저와 디자이너들이 기존의 하던 업무를 온전히 수행하면서, 개발자들에게 지식을 전달하는 일 또한 잘 해낼 수 있다. 일반적으로 4명 정도의 인력을 최초 투입하고, 추후 개발자를 늘리려면, 3~4주 후 추가로 2명 정도를 투입하는 것이 좋다.  

MVP 개발단계에는 가능하면 인력을 많이 늘리지 않는 것이 좋다. 왜냐하면 구축 단계에 가장 큰 목적은 실제 동작하는 제품을 사용자들에게 써보게 했을 때, 사용자들의 문제를 온전히 해결하는지를 확인하는 것이다.

지속적으로 사용자들의 피드백을 받아 이를 제품에 반영하려면, 팀 크기가 8명 이상이 될 경우 커뮤니케이션의 낭비가 많이 발생한다. 개발자들이 도착하면 이전 단계에서 검증된 시나리오 및 디자인 프로토타입을 공유하고, 그 디자인 프로토타입과 연관된 기능을 공유하고 바로 개발에 착수할 수 있도록 한다.  

구축 단계에 사용자에게 제품을 사용하게 하는 방법은 아이디어 검증 단계와 다르다. 구축 단계에 구현된 제품의 사용성을 테스트할 때는 실제 사용자에게 개략적 설명만 한 뒤, 써보라고 맡긴다. 그리고 그들이 사용하는 패턴을 녹화하고 잘 분석하여 어느 부분에서 사용성이 막히는지, 개선할 부분이 어디 인지 찾는다. 이를 개선하며 올바른 문제에 대해 올바르게 동작하는 솔루션을 찾고 이를 통해 스폰서십을 얻는다.

구축 단계까지 일반적으로 품질을 크게 신경 쓰지 않는다. 사용자에게 온전히 테스트할 수 있는 한 많은 부분의 결함을 잡거나 예외 흐름 등을 고려하지 않는다. 낭비를 최소화하고 동작하는 제품을 통한 시나리오 활용이 사용자에게 의미를 갖도록 만든다.  

#4 제품화 단계(Ship it)

제품화 단계는 실제 고객에게 제품을 전달하기 전 '제품화'를 수행하는 것을 의미한다. 중심으로 검증된 시나리오를 기반으로 주변에 필요한 기능들을 함께 추가한다. 예를 들어 '시스템 관리자'를 위한 일부 기능이나 '사용자 등록'등의 기능이 꼭 포함된다. 타깃 고객이 이 제품을 활용할 때 발생할 법적 정책적 문제가 있다면, 이때 함께 고려하여 기능을 추가한다.    

이 단계에는 일반적으로 팀 규모를 늘린다. 앞의 세 단계의 공정으로 아이디어에 대한 검증이 완료되었기 때문에, 이제는 정해진 방향대로 뛰어갈 수 있다. 팀 규모를 늘릴 때는 올바른 비율을 유지하는 것이 중요하다. 프로덕트 매니저, 디자이너, 개발자의 비율을 1:1:4 정도로 유지하면서 팀을 키우고, 팀원이 12명 이상이 될 경우 팀을 둘로 나누는 일을 반복하며 팀을 확대하면 속도의 하락을 최소로 유지하면서 개발할 수 있다.

이때 가장 중요한 것은 제품의 품질을 높이는 일이다. 제품화 단계부터는 깨끗한 코드를 짜고, 대안 흐름, 예외 흐름 등에 발생하는 버그들을 잡아야 한다. 운영 중에 일어날 수 있는 문제점도 사전에 고민하는 것이 좋다. 이전 단계까지 데밥스 환경(로컬 - 개발 - 테스트 - 프로덕션의 단계별 환경)이 의미가 없었다면, 제품화 단계에서부터는 이 환경이 필수적이다.  

자동으로 빌드가 일어나고, 자동으로 코드를 통해 테스트되며, 단계별 원버튼(한 번의 버튼 클릭으로 다음 버전 제품이 반영되는) 릴리즈가 가능해야 한다. 또한 테스트 활동도 중요해진다. 이를 통해 결함 0을 지향하는 제품을 만들어야 한다.  

고객에게 피드백을 받을 수 있는 체계 또한 중요하다. 에러가 났을 때 고객이 시스템 관리자와 소통할 수 있는 창구와 개선에 대한 채널이 존재해야 한다. 사용자의 사용 패턴을 분석할 수 있는 툴을 도입하여 사용자들의 활용 시 어느 곳에서 병목이 일어나는지도 함께 조사할 수 있도록 준비해야 한다.  

#5 지속적인 개선 단계(Tweak it)

앞선 과정이 끝나면, 이제부터 진짜 고행의 길이 시작된다. Product market fit을 찾기 위해, 팀은 끊임없이 제품이 릴리즈 되고 나서는 피드백을 받고, 이를 개선하는 체계를 운영한다. 이 과정은 일반적으로 3년 이상 걸리며, 계속해서 어느 날은 좋았다가 어느 날은 힘들었다가 하는 일이 반복된다. 이 과정에서 팀원 서로를 믿고 계속해서 앞으로 나아가는 것이 중요하다.

-------------

존은 개선 단계까지의 설명을 마치고 살짝 흥분하여 팀원들에게 우리는 반드시 성공할 것이라고 말했다. 팀원 모두는 미소를 뗬다. 8시간의 워크숍 시간 중 7시간이 금세 지나갔다. 모든 구성원들이 세션마다 적극적으로 참여했다.  

워크숍은 매우 알차게 진행되었다. 가장 먼저, 팀의 목표와 팀의 목표와 제약 사항들을 이해하게 되었다. 1시간의 짧은 시간 동안 존이 팀의 리더로서 먼저 발제한 첫 번째 아이디어와 시장 상황을 팀원들과 공유하는 시간을 가졌다. 팀원들은 다양한 질문들을 통해 현재 상황에 대해 이해하게 되었다.  

그다음으로  팀 캔버스 활동을 통해 서로에 대해 알아가는 시간을 얻었다. 모든 구성원 각자에 대하여 이야기할 수 있었고, 이 일을 통해 얻고 싶은 것이 무엇인지, 이 개인의 목표와 조직의 목표가 어떻게 연계되어 의미가 있는지 등에 대해 충분히 토의할 수 있었다.  

마지막으로 JTBD와 개발 프로세스에 대해 공유하여 우리가 앞으로 '어떻게' 일할지의 내용을 알 수 있었다.

----- 원격으로 일하는 가장 쉬운 방법 마림바 -----