닷새의 기적, Sprint

Slack, Nest, Blue Bottle Coffee, Medium.

네 기업의 공통점이 하나 있습니다. ‘Sprint’라는 프로세스를 통해 한 발 더 앞서 나가는 계기를 만들었습니다. Sprint는 5일 간 Startup이 당면한 가장 중요한 문제를 혁신적이고 효율적으로 풀어내는 Google Ventures의 방법론입니다. Google Ventures의 Design Partner인 Jake Knapp이 고안한 Sprint는 얼마 전 한 권의 책으로 세상에 나왔습니다.

 

[Image 1. Sprint]

 

이 책을 감수하신 Startup Alliance의 임정욱 센터장님의 강연 내용과, 제가 책을 읽으며 느꼈던 점을 덧붙여 소개해 드립니다.

 

[Link 1. ‘Startup Alliance의 명강연들 – 임정욱 센터장님’]

 

(제가 덧붙인 부분은 Italic으로 표시했습니다.)

 

Jake Knapp의 실험

So I reviewed the outcome of the workshops I’d run. And I noticed a problem. The ideas that went on to launch and become successful were not generated in the shout-out-loud brainstorms. The best ideas came from somewhere else.

『Sprint』, Page 2

 

Jake Knapp은 목소리 큰 사람들이 주도하기 쉬운 ‘Brainstorm’이 최고의 아이디어를 내는 것은 아님을 알게 되었습니다.

 

(이런 맥락에서 Sprint는 함께 아이디어를 떠올리는 활동보다는, 개개인이 낸 아이디어를 함께 생각해 보는 시간을 위주로 진행됩니다.)

 

I compared the brainstorms with my own day-to-day work at Google. My best work happened when I had a big challenge and not quite enough time.

『Sprint』, Page 2

 

(Sprint 역시 조직이 반드시 풀어야 할 ‘Big challenge’를 강조하며, 5일이라는 시간의 제한 – 제한 시간은 유동적으로 둘 수 있습니다 – 을 분명히 두고 있습니다.)

 

사람마다 차이가 있겠지만, 미리 일을 끝내는 사람보다 닥쳐야 일을 하는 사람이 많은 것 같습니다. 그래서 데드라인이 필요한 것인지도 모르겠습니다. 특히 시간과 자금 등 리소스가 부족한 Startup에게는 충분한 시간을 주고 느슨하게 일을 진행할 여유가 없습니다. 그런 상황에서 최선을 다하다 보면 좋은 방법을 찾게 되는 것 또한 사실입니다.

Jake Knapp은 전 직장에서 미팅이 너무 많아서 일을 하려면 그 사이 빈 시간을 활용해야 했습니다. 하지만 만만치 않은 일이었습니다. 그는 고민 끝에 Google로 이직했습니다. 하지만 Google도 크게 다르지는 않았습니다. 다만 한 가지 달랐던 점은, 문제가 될 수 있는 상황을 그대로 두지 않고 실험하면서 개선하려는 실리콘밸리의 문화가 있었다는 점이었습니다. Jake Knapp은 팀 프로젝트를 효율화 하는 실험을 시작했습니다.

그의 실험은 Google Ventures로 옮겨 계속되었습니다. 참고로 Google Ventures는 Google이 펀드를 만들어 투자하는 CVC ^{Corporate Venture Capital} 입니다. Uber, Nest, Slack 등 여러 회사들에 성공적인 투자를 하고 있습니다. Google Ventures의 특징 중 하나는 Engineer, Recruiter, Market 등 다양한 인력들로 구성되어 있다는 점입니다. 투자한 기업들이 잘 되도록 Resource를 투여해 돕기 위함입니다. Jake Knapp 역시 많은 Startup들이 결정을 내리는데 자신의 일처럼 도왔습니다. 그 가운데 다양한 아이디어를 실험할 수 있었습니다.

 

[Image 2. Google Ventures의 Design 팀 출처: Google Ventures]

 

Idea – Build – Launch – Measure의 Iteration을 수행해 보면 Build 자체가 오래 소요됩니다. 이 같은 Iteration으로 의사 결정을 신속하게 한다는 게 말처럼 쉽지 않습니다. 비용 역시 많이 필요해 원활한 Iteration을 수행하는 것이 쉽지 않습니다. Jake Knapp은 이 점을 착안해 Startup이 Build – Launch의 과정을 거치지 않고 좀 더 신속하게 중요한 비즈니스 이슈를 풀고 의사 결정을 내릴 수 있는 유용한 프로세스를 만들었습니다.

 

0. SET THE STAGE

가장 먼저 해야 할 일은 당면하고 있는 가장 시급하고 큰 ‘Challenge’를 선택하는 것입니다.

 

(여러 사람이 일주일을 온전히 Sprint에 사용하는 것은 Resource 측면에서 보통 일이 아닙니다. 그 정도의 노력을 기울일 만한 ‘큰’ Challenge를 선택해야 합니다.

Challenge를 살펴 보기 위해서는 조직의 목표를 먼저 생각해 봐야 합니다. 그 목표를 실행하는 데 큰 걸림돌이 되는 점들을 찾아 보고, 그 중에서 우선 순위가 높은 점을 Big challenge로 삼아야 합니다.)

 

그 자리에서 의사 결정을 할 수 있는 ‘Decider’도 정합니다. CEO가 맡을 수 없다면 대리자라도 꼭 두어야 합니다.

 

(기업들이 빠른 의사 결정을 내리기 어려운 이유 중 하나는 의사 결정자가 적기에 의사 결정을 내리지 않기 때문입니다. 회의에 함께 참석해 결정을 내리거나, 회의에서 나온 의사 결정 사항을 수시로 청취하고 결정을 내려야 합니다. 회의의 맥락을 잘 모르고 자신의 마음에 들지 않는다고 방향을 바꾼다면 그 동안의 논의는 헛수고가 될 수 있습니다. 5일 간 문제 해결의 과정을 집약하는 Sprint에서는 특히 Decider의 역할이 중요합니다.)

 

‘Sprint Team’을 선정합니다. 너무 많으면 의견을 모으기가 쉽지 않으므로, 최대 7인으로 제한합니다. Sprint Team과는 별도로 좀 더 상세하고 전문적인 의견을 수집하기 위해 ‘Expert’를 섭외해도 좋습니다.

5일 간 온전히 Sprint에 집중할 수 있도록 Calendar를 Block합니다. Laptop이나 스마트폰도 회의실 내에서는 사용을 금합니다.

 

(책에서는 Whiteboard나 Sticky note 같은 준비물도 상세히 알려 줍니다. 디테일한 지침서로 사용할 수 있다는 점이 이 책의 가장 큰 장점 중 하나입니다.)

 

책에서는 호텔을 위한 로봇을 제작하는 Savioke의 예를 들어 설명하고 있습니다. 체크인과 체크아웃 시간에 인력의 수요가 큰 호텔에서 고객 응대를 더욱 신속히 할 수 있도록 Savioke는 심부름 로봇을 만들었습니다. Savioke는 로봇이 고객을 접촉할 때 어떻게 행동해야 하는지 결정하고 싶었습니다. 문제 해결을 위해 Sprint를 수행하기로 결정했습니다.

 

1. MONDAY

고객이 서비스를 이용하는 과정을 Map으로 구성합니다. 과정 중에서 Sprint를 통해 집중해야 할 점들에 대해 HMW ^{How Might We?} 에 대한 아이디어를 생각나는 대로 기록합니다. 스티커로 아이디어 투표를 하는데, Decider에는 가중치를 부여할 수 있습니다. 사내 전문가들에게 아이디어를 듣는 시간을 둘 수도 있습니다.

 

(바쁜 마음에 첫 날부터 Solution을 찾는 데 초점을 맞출 수도 있습니다. 하지만 서두르지 않는 것이 중요합니다. 오히려 Solution을 찾기 위한 ‘Foundation’을 충분히 준비하는 것이 중요합니다. 문제가 무엇인지를 곰곰이 생각해 보고, 함께 이해하고 공유하는 것이 우선입니다.)

 

Savioke의 경우 Map은 고객이 객실에서 전화를 하고, 로봇은 고객의 요청 사항을 인지하고 물품을 받아 객실로 이동하며, 고객에게 물품과 메시지를 전달하는 것입니다. HMW 투표를 통해 로봇이 고객에게 물품을 전달하는 순간이 가장 중요한 사항이며, 이 점에 초점을 맞추기로 했습니다.

 

2. TUESDAY

(월요일이 문제 이해를 위한 시간이었다면, 화요일은 ‘Sketch Day’입니다. Prototype의 Building block을 만드는 시간입니다. 함께 작성한 Sketch를 단계 별로 Break down 해 봅니다.)

 

각자의 아이디어를 3분간 Pitch하는 시간을 가집니다. Flow와 Storyboard를 만들어 어떤 아이디어가 적합할 지 각 Function 별로 분석해 봅니다.

 

(완전히 새로운 아이디어를 찾기 보다, 기존의 아이디어를 적절히 조합해 혁신을 꾀해볼 수 있습니다. 외부 Solution에서 훌륭한 점을 뽑아 보는 ‘Lightning Demo’도 해 봅니다.)

 

3. WEDNESDAY

3분씩을 할애해 아이디어 별로 토론을 합니다. 그 중 세 가지 아이디어를 선택합니다.

Savioke는 로봇이 고객을 만날 때 표정을 보여 주는 것이 좋겠다는 의견을 모았습니다. 고객이 간단한 게임을 하거나, 미션 수행 시 로봇이 가볍게 춤을 추는 것도 고려하기로 했습니다.

 

4. THURSDAY

목요일에는 Prototype을 만듭니다. 실제 구동하지 않더라도, 겉으로 움직이는 것처럼 보이는 ‘Façade’ 수준이면 됩니다. Lego, Photoshop, Keynote, YouTube 등의 도구를 사용해도 됩니다. Savioke의 경우도 iPad를 얹고 리모콘으로 원격 조정해 실제 작동하는 것처럼 만들었습니다.

 

(Prototype을 만드는 데 Role 배정도 필요합니다. 더불어 Interview Script를 준비합니다. Prototype을 잘 만드는 것도 중요하지만, 고객의 반응을 면밀히 관찰하기 위해서는 Script가 사전에 잘 짜여져 있어야 합니다.)

 

5. FRIDAY

통상 5명 내외를 인터뷰 합니다. 5명만 인터뷰 하면 발생 가능성이 있는 이슈의 85%는 드러나게 된다고 합니다. Prototype을 시연할 때 고객의 반응을 최대한 수집할 수 있도록 카메라 장치를 미리 설치해 원격으로 고객의 반응을 살핍니다.

 

(‘Wow’와 ‘No wow’의 패턴을 찾는 것이 중요합니다.)

 

Savioke는 Craigslist에 광고를 올려 Usability test에 참여하는 대신 100달러의 기프트 카드를 제공했습니다. 로봇 실험이라는 얘기는 사전에 하지 않고, 호텔방에서 칫솔을 주문하게 했습니다. 고객이 주문하는 동안 옆 객실에서 모니터링을 했습니다. 게임은 큰 반응이 없었고 표정과 춤은 좋은 반응을 보였습니다.

 

Implications

Sprint의 가장 큰 강점이라 생각 들었던 것은, 많은 기업들을 대상으로 Framework를 사용하고 검증하면서 날로 견고해지고 있다는 점입니다. 나아가 그 Framework를 상세하개 공개하고 공유한다는 점입니다.

Sprint의 또 다른 강점은 어느 기업, 어느 서비스에도 적용이 가능하다는 점입니다. 하지만 Sprint가 만능은 아닙니다. 구성원들의 능력과 협력, 리더의 결단 등이 전제되지 않으면 어떠한 Framework도 혁신을 이끌어내지 못할 것입니다.