Review: SPRINT por Google Ventures

Em primeiro lugar imagino que vocês (ou espero), assim como eu, quando se depararam com o livro SPRINT: o método usado no google para testar e aplicar novas ideias em apenas cinco dias escrito por executivos do Google Ventures (braço de venture capital do Google) , logo pensaram: lá vem outro livro que vai falar de SCRUM. Contudo, após comprar o livro fui positivamente impactado pelo fato de que ambas as metodologias podem sim beber de muitas das mesmas fontes, porém as conclusões, formas de implementação e resultados são extremamente distintos.

Vamos começar com uma pequena pergunta, apenas para aquecer um pouquinho a discussão: Quanto tempo vocês demoram para desenvolver um protótipo de um novo produto? Ou de uma nova feature, ou canal de vendas? Após todo o tempo dispendido para desenvolvê-lo, vocês finalmente apresentam ao usuário que pode amá-lo, odiá-lo ou ficar neutro e se a resposta for um dos dois últimos casos, você certamente perdeu uma boa quantidade de recursos, principalmente dois dos mais valiosos em uma companhia: foco e tempo.

E aí que entra o SPRINT: um processo único de 5 dias do Google Ventures que busca resolver questões críticas por meio de protótipos e testes de ideias com clientes, por meio de validações rápidas de hipóteses. Ele por sua vez, consiste em um roteiro segmentado por dias da semana cuja estrutura é a abaixo:

• Na 2a: Se mapeia o problema e se escolhe um ponto importante em que se concentrar
• Na 3a: Esboçar soluções concorrentes de protótipos no papel
• Na 4a: Tomar decisões difíceis e transformar as ideias em hipóteses que possam ser testadas;
• Na 5a: Construir um (ou mais) protótipos realistas
• Na 6a: Fazer um teste com usuários

O charme da metodologia é exatamente o fato de que quanto maior for o desafio, melhor o SPRINT Assim, projetos de altos riscos, com tempo insuficiente ou simplesmente estagnados podem ser propulsionados, ou retirados do papel.

Obviamente não vou percorrer todos os passos que estão habilmente comentados ao longo do livro que tem uma leitura fluida e super acessível. Contudo, queria destacar alguns dos aprendizados que podem ser implementados sem necessariamente aderir ao processo como um todo.

#1 Antes de se debruçar sobre todo o trabalho para desenvolver um produto, foque-se em resolver a superfície primeiro e validá-la com o público-alvo. Dessa forma você poderá avançar de forma mais rápida, chegando a respostas importantes sem se comprometer com a execução. Por que gastar semanas desenvolvendo um site novo se você pode em algumas horas desenvolver uma apresentação que sirva de mock-up do site e já descobrir se ela está clara, ou não?

#2 Estabeleça desde o início para um projeto quem são os Definidores, isto é, aqueles que serão responsáveis por tomar a decisão final de seguir ou não um projeto e o quão prioritário ele é para a estratégia da companhia ou área. Pedir a sua participação desde o início te assegura tanto um buy-in executivo quanto uma visão profunda do problema, assim como opiniões fortes e critérios que ajudam a encontrar uma solução.

Desse modo, melhor consultá-lo antes de dar o greenlight a um projeto, pois em muitos casos, ainda que ele tenha outputs positivos, a decisão de integrá-lo ou não, depende de uma série de outros fatores que podem não estar ao seu alcance.

#3 Trabalhe com times multifuncionais, em tamanho reduzido e consulte a especialistas. Cada parte de um projeto demandará visões e habilidades distintas, portanto é melhor já trazê-las desde a gestação e consultar as referências na companhia nos assuntos em questão para acelerar a sua curva de aprendizado

#4 Comece pelo fim: No início de um projeto reflita sobre seu objetivo de longo-prazo e as questões difíceis que devem ser respondidas. Por que está realizando esse projeto? E por fim, imagine um cenário no futuro em que seu projeto fracassou e se pergunte quais os principais motivos que podem ter levado a esse fim. Com eles em mente, é só incluir no radar para assegurar que não ocorrerão

#5 Evite a todo custo o Groupthink. Opte por processos estruturados de discussão e idealização, pois ficamos menos criativos e assertivos quando pensamos em grupo (o famoso Brainstorming que eu tanto abomino). Trabalhar sozinho em grupo aumenta a pressão da responsabilidade individual e permite que com mais tempo e concentração cheguemos a ideias melhores.

#6 Silencie os bons comunicadores: Todos provavelmente já sentimos que pessoas que se comunicam melhor tendem a ter maior presença e participação em reuniões de apresentação de propostas de projetos. O seu maior carisma e articulação permitem que ideias soem melhor - principalmente no abstrato - e assim tendemos a escolher e aprovar teses que não necessariamente são as melhores. Opte por votações em silêncio em exposições de ideias e propostas em modelos de storyboards autoexplicativos por exemplo para permitir que todos os projetos de todas as pessoas, a despeito de oratória sejam analisados pelo mesmo crivo.

#7 Divida grandes ideias em pequenos blocos de ideias. Muitas vezes tomamos propostas de soluções e ideias como algo único que deve ser analisado como bom, ruim ou indiferente. Dessa forma, aprovamos ou declinamos uma nova ideia para projetos. Desse modo, uma ideia normalmente é composta de uma série de blocos que são imediatamente descartados no processo comum de tomada de decisão. Contudo, se analisarmos os blocos de informação separadamente poderemos reaproveitar uma série de ideias inspiradoras e inovadoras dentro de uma ideia, nos atendo por exemplo a partes especificas dentro de uma proposta de site, ou a features dentro de um novo produto.

#8 Não se preocupe em encontrar uma resposta matadora. Muitas das vezes não chegamos a uma panaceia, isto é, a uma solução que resolva tudo na primeira vez. Se esse é o caso, por que nos preocuparmos tanto em reduzir todas as nossas hipóteses a apenas uma tese? Muito melhor encontras as duas ou três melhores e validá-las no modelo de mocku-up com um usuário, buscando destrinchar dentro da sua experiência quais aspectos foram mais ou menos impactantes e depois disso absorvê-las em uma nova solução :)