Design Sprint em times remotos

Sim! É possível! E eu vou relatar a experiência que tive no time remoto da Clara

Esta não é uma receita de bolo para resultados sensacionais. Nem eu, nem a Clara acreditamos nessas receitas infalíveis. Cada time tem suas particularidades e o que funciona de um jeito para uns, pode funcionar diferente para outros. O que eu quero compartilhar com você aqui é a nossa jornada de adaptação do Design Sprint para a realidade de um time que funciona remotamente. A minha expectativa é fazer você se inspirar para testar novos processos adaptados para a realidade do seu time.

O que é o Design Sprint?

Não dá para explicar como nós adaptamos um processo sem explicar o mínimo de como ele funciona, né? Ok! Então, lá vamos nós…

É um método criado por designers do Google Ventures. Se eu fosse resumir em apenas uma frase o que é isso, eu diria o seguinte:

É um processo que dura 5 dias e ajuda a responder questões críticas do negócio através do design, protótipos e testes com usuários.

Um dos seus principais pilares é a necessidade da presença física do time. Todos reunidos em uma sala durante uma semana. A grande questão é que o time da Clara é remoto e tem gente trabalhando em diversas cidades no Brasil e até mesmo na Europa. Temos um nômade digital perambulado pelo leste europeu nesse momento. E sem data de retorno! Isso não é sensacional? Com certeza é!

Por essas e outras digo que não existe processo que vá mudar os ganhos que temos com o trabalho remoto. Ou seja, não somos nós que nos adaptamos aos processos, mas os processos que devem ser adaptados a nós. Faz sentido, não acha?

A jornada da adaptação

Quando começamos a pensar na criação da Clara, havia um mundo de possibilidades. Ter ideias nunca foi problema para nós. Muito pelo contrário! Nosso canal no Slack sempre viveu cheio de insights interessantes. E foi assim que tudo começou. Com base em muitas leituras, referências e milhares de insights discutidos internamente.

Após algum tempo de desenvolvimento, a primeira versão da Clara nasceu! Ainda sem se chamar Clara e com uma forma bastante questionável, mas ela estava lá. Fruto de muitas conversas internas e baseada em referências como Codecademy, Duolingo, Coursera e outras. Já era possível enviar um link para alguém e pedir para que testassem. Vários feedbacks foram dados e a nossa maior dificuldade nesse começo foi canalizar essas descobertas para fazer a Clara evoluir de verdade.

Durante a busca por uma solução que nos ajudasse no desenvolvimento ágil da Clara, conversei com designers de outras empresas na expectativa de me inspirar em algum processo. Percebi que cada equipe funcionava de uma forma diferente, mas encontrei uma característica comum: alguns usavam adaptações do Design Sprint e seus resultados eram bem interessantes. Eureka!

Iniciei imediatamente a leitura do livro Sprint (já disponível em português) para entender melhor como tudo funcionava. A cada capítulo eu me empolgava mais e mais, pois via aquilo como uma solução interessante para os nossos desafios. Tirando a parte presencial, parecia que as coisas se encaixavam. Enviei o link do livro para o Leandro, um dos sócios da Clara, e ele também se empolgou. Aquele era o momento certo para adaptarmos o método e testarmos. E assim fizemos!

Nossa versão do Design Sprint

Tenho que confessar que mudamos tanto o processo, que eu poderia falar que criamos o Sprint Clara em vez de falar que usamos o Design Sprint. Em minhas leituras, fui identificando três grandes blocos que se mostravam como principais desafios para times remotos como o nosso.

1. O desafio do quadro branco: Um ponto chave do processo é ter um quadro branco para evoluir com anotações e descobertas ao longo desses 5 dias. Graças ao Apresentações Google, criamos o nosso quadro branco virtual onde o time poderia editar simultaneamente. Com isso, eliminamos boa parte dos impedimentos de aplicar Design Sprint em times remotos.
2. As reuniões presenciais: O modelo oficial sugere que isso aconteça em uma sala fechada e nenhum membro do time deveria ter acesso a celular ou computadores. Esta foi mais uma mudança necessária. Como equipe remota, a nossa forma de reunir o time era pelo computador. Usamos o Appear, Slack ou mesmo o velho Skype para fazer nossas reuniões.
3. Os testes com os usuários: Essa parte dos testes eu tenho que confessar que não foi grande problema para nós, pois já estávamos habituados a fazer testes remotos. No entanto, como o método oficial valorizava o presencial, inclusive nos testes, esse também se tornou um desafio. Conseguimos superá-lo aplicando testes remotos através do compartilhamento de tela via Skype e usando protótipos feitos no Invision. Isso tem funcionado bastante para nós.

As etapas do Sprint Clara

Após todas as adaptações, criamos um único PPT do Google Drive listando todo o roteiro do nosso sprint adaptado. Essa mesma apresentação serviu para explicarmos o processo para o time que participaria nessa primeira rodada. Para ajudá-lo, vou resumir cada etapa do nosso sprint adaptado para você entender como ele ficou.

1. Objetivos do sprint

Começamos com um slide para traçar os objetivos do sprint e também fazer a previsão de como gostaríamos de estar em médio prazo.

Essa é a forma como os criadores pensaram no processo. Fizemos exatamente isso no começo, mas logo percebemos que não precisávamos pensar a cada sprint a mesma coisa. Logo, deixamos de fazer essa parte nos sprints seguintes.

2. Mapeamento do problema

A parte vermelha é o ponto que o sprint vai tentar resolver

Entender o problema e focar em resolver uma parte dele é o recomendável. No primeiro sprint, escolhemos uma parte grande demais e isso comprometeu o resultado final. Aprendemos cedo que devemos focar em partes menores de um problema para aumentarmos as chances de resultados mais conclusivos.

3. Abrindo a cabeça

Uma parte de um “HMW” já categorizado pelo time

A obrigação de pensar em soluções pode ser uma pressão que bloqueia as ideias e isso acontece com todos, mesmo com os mais criativos. Por isso, mantemos essa etapa do processo original sem alterações. É o que eles chamam no livro de How Might We (Como Podemos). Várias ideias sobre como poderíamos resolver algo eram inseridas nos slides. Nossa experiência com isso foi muito positiva para quebrar o gelo e abrir a cabeça para ideias inusitadas. É como se fosse um brainstorming.

4. Busca de referências

Oba!!! Vamos roubar ideias dos outros! Brincadeira haha. Não é esse o objetivo. Buscar referências abre mais ainda a sua cabeça. É extremamente recomendável ser mais ousado trazendo referências de lugares inusitados. Pense que você está envolvido em um projeto de uma cafeteria. Se você ficar preso na busca de referências de outras cafeterias, não vai conseguir sair da caixa. Por outro lado, e se você trouxer ideias de lugares impensados como um circo ou academia de ginástica para um café? O que pode parecer loucura no começo, pode virar a grande sacada. Apenas lembre do que foi visto nas três etapas anteriores.

5. Esboço de ideias

Ih ferrou! Você não sabe desenhar? Sem problema algum. Eu também não sou bom e o esboço acima confirma isso! O mais importante aqui é você saber expressar a sua ideia. O método original sugere que cada um se atenha a esboçar até três partes de algum problema. Começamos assim e vimos que isso nos deixava sem opções para um protótipo completo. Por isso abrimos para que cada um pudesse fazer mais esboços pensando em fluxos de um protótipo. O Design Sprint chama essa parte de Sketch.

6. Apresentação e votação

Cada ideia esboçada é apresentada por seus autores. Os caras lá do Google não gostam muito disso, pois alegam que a ideia de alguém visto como importante ou criativo pode influenciar nas votações. Não acreditamos nisso e ignoramos essa questão. As apresentações ajudaram muito a entendermos as ideias. Após o entendimento, votamos nas melhores partes de cada sketch com bolinhas laranja (cada membro tem até três bolinhas por sketch). Depois disso, o decisor do sprint vai determinar quais partes serão prototipadas usando bolinhas rosa. E não se espante se o decisor optar em ignorar o voto do time. Faz parte e nós vimos isso acontecer em nossos sprints também.

7. Prototipação e testes

Será que a nossa ideia vai dar certo? Essa parte é para responder esse tipo de questionamento. O time olha o que foi marcado com bolinhas rosa pelo decisor e começa a montar o protótipo. Usamos o Invision para prototipar e aplicamos testes também remotos com compartilhamento de tela via Skype. Gravamos os testes com o Camtasia. Quando recebemos muitos feedbacks críticos de usuários, é onde temos o sucesso do sprint. Lembra quando falei na etapa 4 sobre busca de referências inusitadas? Nossos primeiros sprints eram carentes disso e não conseguíamos responder aos nossos questionamentos. Quando decidimos ousar mais, começamos a aprender mais. Ou aprendíamos que determinado caminho era muito ruim ou que talvez pudesse ser promissor.

8. Implementar ou não?

Um monte de anotações, horas de gravações de testes, novas ideias para solucionar problemas identificados nos testes e novos questionamentos. Hora de pegar esse monte de informação para decidir. Não é tarefa fácil, mas é aqui que a gente faz valer a pena todo o tempo dedicado. Entenda que chegar a uma decisão de não implementar pode ser um excelente resultado. Afinal, você dedicou uma semana para testar algo e não gastou meses de desenvolvimento. Saber que uma ideia não deu certo é uma ótima forma de dizer que o sprint teve sucesso. Claro que também adoramos quando percebemos uma oportunidade de implementação :)

Aprendizados coletados até aqui

Nós começamos o processo já adaptando para a nossa realidade remota e, consequentemente, tivemos nosso tempo para a curva de aprendizagem. Alguns pontos principais foram:

1. Saiba lidar com o poder soberano do decisor: Isso faz parte do processo original e não deixamos todos os participantes 100% cientes de como o processo funcionava e todas as suas implicações como o poder soberano de um decisor. Tivemos um momento curioso onde o time inteiro era contra deixar a Clara como chat em uma só coluna e o decisor era o único a acreditar nisso. Seguimos a ideia do decisor, mas testamos as 2 versões (com uma e com duas colunas). Tivemos a feliz surpresa de descobrir que um time inteiro estava “errado” e o decisor era o único “certo”. De 5 testes, 5 pessoas preferiram a coluna única sem pensar duas vezes. Ou seja, o time como um todo teve sucesso.
2. Tenha mais ousadia nas soluções: Os primeiros sprints foram pouco ousados e assim aprendemos como não se deve jogar fora 5 dias da semana de um time inteiro. Ao testar pequenas melhorias em sprint percebemos que os testes não eram conclusivos. Além disso, estamos falando de um processo para ousar e inovar sem medo. Afinal, estamos testando com protótipos. Se for para dar algo errado, que seja tentando algo novo. Uma das coisas que ajuda aqui é ter um trabalho de busca de referências mais ousada no lightning demo.
3. Não tente resolver todos os problemas: No começo, tínhamos dificuldade para entender qual problema deveríamos atacar. Então acabamos atacando algo grande, gerando um protótipo grande e um teste grande. Para piorar, as conclusões não acompanharam essa ordem de grandeza e ficamos carentes de insumos para decidir o que fazer. Com mais foco no problema, tivemos testes mais curtos e menos cansativos. Nada mais que 15 ou 20 minutos em cada teste. As coisas tenderam a ser mais conclusivas.

Momento atual

Hoje estamos bem felizes com o nosso processo adaptado. Sabemos que ainda temos muito o que evoluir. E nós vamos!

Como qualquer processo, ele precisa da adesão e colaboração de todo o time. Sem isso, não há processo no mundo que funcione.

Se você já tem um time remoto (que funciona), já pode começar a aplicação. Se preferir, leia o livro Design Sprint, faça uma apresentação para a sua equipe e tente!

Acreditamos que é o empreendedorismo que move a sociedade para a frente e é por isso que estou compartilhando nossos aprendizados sobre o Design Sprint. Esperamos que ele possa ajudá-lo assim como tem nos ajudado.

E se você quiser dar uma olhadinha nos resultados atuais dos nossos sprints, é só entrar e experimentar gratuitamente. Não se esqueça de comentar aqui sobre qualquer crítica ou sugestão. Talvez isso possa virar tema do nosso próximo sprint.

Boa sorte na sua jornada :)