스프린트의 본질은 빠른 검증
스프린트는 구글에서 도입한 협업 방법론으로, 일주일의 시간 동안 문제를 정의하고 빠르게 프로토타입을 만들어서 검증하는 과정을 거친다. 서비스가 런칭되기 까지 보통 몇 달이 걸리는 데, 단 일주일 안에 프로토타입 서비스를 만드는 걸 목표로 잡은 스프린트는 '빠른 속도'를 핵심 가치로 둔 것처럼 보인다. 하지만, '빠른 속도'만으로 스프린트의 본질을 설명할 수 있을까?
보다 정확히 말하면, '빠른 속도'보다 '빠른 검증'이 스프린트의 본질이라고 할 수 있다. 스프린트의 시작은 '문제의 정의'다. 고객이 원하는 바가 무엇인고, 고객이 어떤 것을 불편해 하는지 등의 가설적 문제를 가장 먼저 정의한다. 여기서 '가설'이라 표현을 쓴 이유는, 이 문제가 진짜 문제인지 모르기 때문이다. 고객은 여러가지 요소에 의해, 자신의 진짜 생각을 겉으로 완전히 표현하지 못한다. 따라서, 가지고 있는 최대한의 정보를 활용해 가설적 문제를 정의한다.
스프린트의 끝은 '프로토타입의 테스트'이며, 이는 앞서 정한 가설적 문제를 검증하는 것과 같다. 애초에 프로토타입 제품은 스프린트가 시작하는 날에 정한 문제를 '진짜 문제'라고 전제하고 만든 솔루션이기 때문이다. 그러므로, 만약 이 프로토타입 제품이 고객의 긍정적 반응을 받지 못한다면, 전제한 '진짜 문제'는 사실 진짜가 아니게 된 것을 검증하게 된다. 이와 같이, 스프린트를 이루는 큰 축은 '문제 정의'와 '테스트'이며, 이를 통해 일주일 안에 문제를 검증할 수 있다.
그렇다면, 빠른 검증이 필요한 이유는 무엇일까? 왜 스타트업은 스프린트에 열광할까? 빠른 검증은 다음으로 나아갈 방향을 알려주기 때문이다. 스타트업은 한정된 자원을 가지고 목표를 향해 나아가야 한다. 하지만, 스타트업이 서있는 곳은 지도가 없는 미지의 길이며, 여기서 한 방향만 잡고 무작정 걸어가다가 자칫 목표와 전혀 반대 방향으로 나아갈 수 있게 된다. 미지의 길에서 목표와 가까워지기 위해선, 자신이 나아가는 방향을 반복적으로 확인해야 한다. 지금 걷는 방향이 맞는지 계속 확인하고, 잘못됐다 싶으면 다시 방향을 수정해야 한다. 그래야지만, 목표와 자신과의 거리를 서서히 좁혀갈 수 있다. 스프린트를 도입하면, 일주일마다 하나의 검증을 진행하게 된다. 그리고, 이러한 검증이 반복되면서 스타트업의 방향을 확인시켜준다.
단 하나의 이해관계자와 행동
스프린트의 첫 날은 모두, 문제를 정의하는 데 쓴다. 팀의 목표를 정하고, 이 목표의 본질에 더 다가갈 수 있는 핵심 질문(=스프린트 질문)을 끊임없이 던진다. 이 후, 모든 이해관계자와 이들의 행동이 담긴 여정 지도를 그리고, 이 지도 안에서 How 질문(=무엇을 해야할까?)을 던진다. 최종적으로, 여정 지도에서 단 하나의 이해관계자와 행동을 선택한다.
회의가 길어질수록, 주제에 벗어난 이야기가 자주 오가는 상황이 발생하게 된다. 여러 이야기가 오가다가, 어느 순간부터 주제와 전혀 관련 없는 이야기를 하게 된다. 하지만, 스프린트의 문제 정의 과정은 마치 점점 좁아지는 깔때기처럼, '목표'에서 시작해 여러가지 질문을 거친 끝에 단 하나의 이해관계자의 행동에서 끝난다. 그리고, 각각의 질문은 직전의 질문에 기반을 둔다. "우리의 목표는 무엇일까? ", "이 목표와 관련된 핵심 질문은 무엇일까?" "고객은 어떤 여정을 거치지?" "이 여정 속에서 목표를 위해 무엇을 해야할까?" "이 여정에서 우리가 집중해야 할 행동은 무엇일까?" 이렇게 이어지는 질문은 모든 팀원이 하나의 방향을 바라보게 만들고, 팀이 문제를 풀어나갈 영역을 점점 날카롭게 만든다.
스프린트에서 재밌는 점은 스프린트 질문이나 How 질문 같이, 문제 정의 과정의 대부분에서 질문이 등장한다는 점이다. 질문을 사용하는 이유는, 문제의 본질에 더 깊게 다가가기 위함이다. 포스트잇에 적힌 질문을 계속 보고 읽음으로써, 문제의 본질이 무엇인지 스스로에게 계속 되묻게 된다.
다양한 아이디어와 빠른 합의
문제 정의를 통해 팀은 자신들이 문제를 풀어나갈 영역을 날카롭게 만들었다. 바로, 단 하나의 이해관계자와 행동 말이다. 이제 이걸 어떻게 풀어낼지를 정할 일만 남았다. 우리에게 친숙한 해결책 구상 방식은 집단 브레인스토밍이 있다. 하지만, 스프린트는 초기 솔루션을 팀원이 다 같이 생각하는 방식보다, 각자가 아이디어를 생각하고 서로 경쟁해서 결정하는 방식을 장려한다.
집단 브레인스토밍을 선호하지 않는 이유는, 혼자서 일을 할수록 문제에 대해 더 깊게 생각할 수 있기 때문이다. 다 같이 모여서 브레인스토밍을 하면, 개인은 문제에 대해 깊게 생각하기보다 팀원에게 자신도 모르게 의존하게 된다. 또한, 솔루션을 혼자만의 힘으로 스케치해야 한다는 책임감은 개인의 참여도를 더 높인다.
경쟁을 통한 초기 솔루션 도출은 업무의 효율성을 높여준다. 스프린트의 시간은 일주일이며, 이 시간 내 문제를 정의하고, 빠르게 프로토타입 솔루션을 만들어야 한다. 이처럼 시간이 촉박한 만큼, 모든 회의는 효율적으로 진행되야 한다. 하지만, 회의를 하면서 어쩔 수 없이 병목이 걸리게 되는데, 서로 다른 의견을 하나의 의견으로 합의해야 하기 때문이다. 이 때, 합의가 빠르게 일어나지 않는다면, 회의는 점차 길어지며 비효율을 낳는다.
회의의 목적은 모두가 얼라인 되는 단 하나의 의견을 도출하기 위함이다. 즉, 핵심은 '단 하나의 의견을 만들기'에 있다. 스프린트는 이 핵심을 캐치함과 동시에 비효율을 줄이는 방식으로 경쟁에 주목했다. 우선 팀원 각자가 초기 솔루션을 생각함으로써, 다양한 아이디어가 나올 수 있다. 그리고, 이 아이디어가 서로 경쟁함으로써, 단 하나의 가장 좋은 아이디어가 남게 된다. 경쟁에서 살아남은 아이디어는 가장 좋은 아이디어이자, 모든 팀원이 동의한 아이디어이다. 이 아이디어는 최종 솔루션의 뼈대로서, 팀원 모두에게 동일한 방향을 제시한다. 이제 팀은 이 뼈대에 어떤 살을 붙일지 결정하기만 하면 된다.
'진짜 같은' 프로토 타입 만들기
프로토 타입을 만드는 이유는 제품에 대한 고객 반응을 미리 엿보기 위함이다. 즉, 프로토 타입은 실제 제품의 가능성을 검증하기 위한 많은 수단 중 하나다. 그렇다면, 다른 수단을 사용해 고객 반응을 살필 수 있지 않을까? 가령, 프로토 타입을 만들기 전에 작성한, 아이디어 노트를 가지고 고객 반응을 엿볼 수 있지 않을까?
아이디어 노트와 프로토 타입 사이의 가장 큰 차이는 구체성이다. 스케치 아이디어는 추상의 영역에 머무르고, 이를 구체화 시킨 게 프로토 타입이다. 아이디어 노트와 프로토 타입 사이를 연결하는 구체화 과정에서 팀은 많은 부분을 고려된다. 만약 고객에게 아이디어 노트를 보여주는 경우, 이 복잡한 구체화 과정은 고객이 스스로 해야 한다. 이 때, 구체화의 정도도 개인에 따라 달라지게 된다. 환경, 성격, 배경 지식 등에 의해 구체화의 정도가 달라지고, 결과적으로 고객 각자가 서로 다른 제품을 생각하게 된다. 즉, 아이디어 노트에 적힌 기능이 실제로 동작되는 모습은 아이디어 노트 그 자체보다, 고객의 상상에 더 의존하게 된다.
프로토 타입을 최대한 진짜 같게 만들어야 하는 이유도 이 때문이다. 대상이 구체적일수록, 고객은 그 대상에 더 집중하게 된다. 아이디어 노트를 봤을 때, 제품의 구체적 모습을 그리기 위해 사용된 정신적 에너지가, 이제 프로토 타입의 평가에 쏟아지게 된다. 즉, 프로토 타입은 서로 다른 고객이 동일한 제품을 보게 만들고, 그 제품의 평가에 더 집중하게 만드는 유일한 수단이다.
검증의 주체는 고객이지 '나'가 아니다.
세계에서 가장 유명한 소설 중 하나인 해리포터, 그러나 이 해리포터가 8개의 출판사에 거절 당했다는 이야기는 누구나 한 번 쯤 들어봤다. 사실, 9번 째 출판사도 해리포터를 거절하려고 했었다. 하지만, 출판 담당자는 결정을 내리기 직전, 해리포터의 초안을 본 딸이 엄청 열광하는 모습을 보고나서 생각을 바꾸게 됐다. 많은 출판사가 해리포터의 출판을 거절한 이유는 간단했는데, "내용이 매우 길어서 아이들이 재미있게 볼 수 있을 것 같지 않다."고 생각했다. 하지만, 아이들은 오히려 해리포터에 깊게 몰입해 긴 내용을 순식간에 읽었다.
해리포터의 사례는 다른 사람이 고객의 시선에서 세상을 바라보기란 불가능하고, 오직 고객에게 물어봐야 알 수 있음을 보여준다. 이는 프로토 타입의 검증에서도 마찬가지다. 아이디어 노트에서 프로토 타입을 만들기까지 팀은 최대한 고객의 시선에서 많은 부분을 생각해본다. "우리 고객은 이런 기능을 좋아하겠지?" "우리 고객은 이런 부분을 싫어할꺼야" 이러한 생각도 전혀 근거 없는 것이 아니다. 이미, 팀은 고객을 이해하기 위한 리서치를 완료했고, 관련된 데이터를 가지고 있다. 하지만, 이러한 노력에도 불구하고 팀은 고객의 시선을 잠시 빌릴 뿐, 고객 그 자체가 될 수 없다. 따라서, 고객에게 직접 물어보고 검증을 해야지 비로소 참과 거짓을 판단할 수 있다.