O que eu fazia no trabalho não estava dando certo.

Em 2003, minha esposa e eu tivemos nosso primeiro filho. Quando voltei ao escritório, queria que meu tempo no trabalho fosse tão relevante  quanto meu tempo em família. Fiz uma análise minuciosa de meus hábitos – e vi que não estava dedicando meus esforços à parte mais importante do trabalho.

Assim, comecei a otimizar. Procurei livros sobre produtividade. Criei planilhas para conferir se me sentia mais eficiente fazendo exercícios de manhã ou na hora do almoço, se bebendo café ou chá. Durante um mês, experimentei cinco tipos de listas de tarefas. Sim, toda essa análise foi  estranha. Contudo, pouco a pouco, fui ficando mais focado e mais organizado. 

Então, em 2007, consegui um emprego no Google e lá encontrei uma cultura perfeita para um nerd dos processos. O Google encoraja a experimentação – não apenas com produtos, mas nos métodos usados pelos indivíduos... e pelas equipes.

O aperfeiçoamento dos processos em equipe tornou-se uma obsessão para mim (sim, também estranho). Minhas primeiras tentativas foram workshops de brainstorming com equipes de engenheiros. O brainstorming, quando todo mundo expõe suas ideias, é bastante divertido. 

Após algumas horas juntos, tínhamos uma grande pilha de notas autoadesivas e todos estavam muito animados.

Um dia, porém, no meio de um brainstorming, um engenheiro interrompeu o processo. “Como você sabe que o brainstorming funciona?”, perguntou  ele. Eu não sabia bem o que responder. A verdade era constrangedora: eu vinha indagando aos participantes se eles gostavam dos workshops, mas não verificara os resultados reais.

Avaliei, então, o saldo dos workshops que conduzi e identifiquei um problema: as ideias que vinham a ser desenvolvidas e se tornavam bem-sucedidas não saíam dos brainstormings barulhentos. As melhores vinham de outro lugar. Mas de onde?

Quando estavam sozinhas, as pessoas continuavam tendo ideias da mesma forma de sempre – sentadas a suas mesas, esperando pelo café em uma lanchonete ou tomando banho. Essas ideias geradas individualmente eram melhores. Quando a euforia dos workshops acabava, os planos elaborados a partir do brainstorming não eram competitivos o suficiente.

Talvez não houvesse tempo sufi ciente durante as sessões para um pensamento mais profundo. Isso provavelmente acontecia porque o brainstorming terminava com desenhos em papéis em vez de algo mais realista. Quanto mais eu pensava sobre isso, mais falhas identificava em minha abordagem.

Comparei os brainstormings a minha própria rotina no Google. Eu fazia meu melhor trabalho quando tinha um grande desafio e dispunha de  pouco tempo.

Um desses projetos se deu em 2009. Um engenheiro do Gmail chamado Peter Balsiger teve a ideia de possibilitar a organização automática dos e-mails. Fiquei animado com a ideia – conhecida como “Caixa Prioritária” – e recrutei outra engenheira, Annie Chen, para trabalhar nisso conosco. Ela concordou, mas só nos daria um mês. Se não conseguíssemos provar que a ideia era viável naquele período, ela iria para outro projeto. Eu tinha certeza de que um mês não seria tempo o bastante, mas Annie é uma engenheira incrível, por isso decidi apostar.

Os prazos apertados me forçaram a manter o foco. não podia me dar ao luxo de pensar muito nos detalhes ou me distrair com algo

Dividimos o mês em quatro blocos com uma semana de duração. A cada semana, criávamos um novo design. Annie e Peter desenvolviam um  protótipo, e então, no último dia da semana, nós o testávamos com algumas centenas de pessoas. 

No fim do mês, havíamos chegado a uma solução que as pessoas conseguiam entender – e queriam usar. Annie ficou conosco para liderar a  equipe da Caixa Prioritária. E, de alguma forma, fizemos o trabalho do design em uma fração do tempo habitual.

Meses depois, visitei Serge Lachapelle e Mikael Drugge, dois googlers que trabalham em Estocolmo. Queríamos testar uma ideia para um software de videoconferências que pudesse ser executado em um navegador de web. Eu ficaria poucos dias na cidade, por isso trabalhamos o mais rápido  possível. No fim da visita, tínhamos um protótipo em funcionamento. Nós o mandamos por e-mail para nossos colegas e começamos a usá-lo em reuniões. Após alguns meses, a empresa inteira estava usando. (Mais tarde, uma versão refinada e aperfeiçoada desse aplicativo foi lançada como Google Hangouts.)

Nos dois casos, percebi que havia trabalhado com muito mais eficiência do que em minha rotina diária normal ou em qualquer workshop de  brainstorming. Qual era a diferença?

Em primeiro lugar, houve tempo para desenvolver as ideias de maneira independente, ao contrário do que acontece em meio à gritaria e aos  argumentos de um brainstorming. Mas não houve tempo demais. Os prazos apertados me forçaram a manter o foco. Não podia me dar ao luxo de pensar muito nos detalhes ou me distrair com outro projeto menos importante, como frequentemente acontecia nos dias de trabalho comuns.

Os outros ingredientes-chave foram as pessoas. Os engenheiros, o gerente de produto e o designer estavam todos juntos na sala, cada um resolvendo  sua própria parte do problema, cada um pronto para responder às dúvidas dos outros. 

Reconsiderei aqueles workshops em equipe. E se eu acrescentasse estes ingredientes mágicos: foco no trabalho individual, tempo para criar um  protótipo e um prazo impreterível? Decidi chamar isso de design “sprint”, em uma alusão às corridas de alta velocidade em curtos intervalos de tempo.

Criei um cronograma básico para meu primeiro sprint: um dia para compartilhar informações e esboçar ideias, seguido por quatro dias de desenvolvimento de protótipos. Mais uma vez, as equipes do Google receberam a experiência de bom grado. Liderei sprints para o Chrome, o Gmail e o próprio mecanismo de buscas do Google, além de outros projetos.

Foi empolgante. Os sprints funcionaram. Ideias foram testadas, desenvolvidas, lançadas – e o melhor de tudo: em muitos casos, tiveram sucesso no mundo real. O processo de sprint se espalhou pelo Google de uma equipe para outra e de sede para sede. Uma designer do Google X se interessou pelo método e liderou um sprint para uma equipe no Ads. Os googlers desse sprint contaram aos colegas, e assim por diante. Em pouco tempo, eu estava ouvindo falar sobre sprints de pessoas que nem conhecia.

Cometi alguns erros no caminho. Meu primeiro sprint contou com quarenta pessoas – um número ridiculamente alto que quase frustrou o processo antes mesmo de começar. Ajustei o período gasto na formulação de ideias e no desenvolvimento de protótipos. Descobri o que era rápido demais, o que era lento demais e, por fim, o que era o ideal.

Dois anos depois, encontrei Bill Maris para conversar sobre os sprints. Bill é o CEO do Google Ventures (GV), firma de capital de risco criada pelo Google para investir em startups promissoras. Ele é uma das pessoas mais influentes no Vale do Silício, mas é impossível saber disso tendo como base seu comportamento despojado. Naquela tarde em particular, ele estava usando seu traje típico: um boné e uma camiseta que dizia alguma coisa sobre o estado de Vermont.

Bill estava interessado em conduzir sprints com as startups no portfólio do GV. Em geral, essas empresas têm apenas uma chance de criar um produto de sucesso antes de ficarem sem dinheiro. Os sprints podiam lhes dar uma forma de descobrir se estavam no caminho certo antes de se arriscarem a desenvolver e lançar seus produtos. Conduzir sprints era uma chance de economizar e gerar dinheiro.

Porém, para que desse certo, eu teria de adaptar o processo dos sprints. Fazia anos que eu vinha pensando sobre produtividade individual e em equipe. No entanto, eu não sabia quase nada sobre startups e as particularidades de seu negócio. Mesmo assim, o entusiasmo de Bill me convenceu de que o Google Ventures era o lugar certo para os sprints – e o lugar certo para mim. “Nossa missão”, disse ele, “é encontrar os melhores empreendedores do planeta e ajudá-los a mudar o mundo para melhor.” Não resisti. 

No GV, juntei-me a três outros parceiros no design: Braden Kowitz, John Zeratsky e Michael Margolis. Juntos, começamos a organizar sprints com startups, fazendo experiências com o processo e examinando os resultados para descobrir formas de aprimorá-lo.

As ideias contidas neste livro vêm do nosso time todo. Braden Kowitz acrescentou ao processo do sprint o design baseado em cenários, uma abordagem pouco convencional que se concentra na experiência do usuário como um todo, e não em componentes ou tecnologias individuais. John Zeratsky nos ajudou a começar pelo fim, de modo que cada sprint respondesse às questões mais importantes referentes ao negócio. Braden e John tinham a experiência que me faltava com as startups e os negócios e remodelaram o processo para garantir um foco melhor e decisões mais inteligentes a cada sprint. 

Michael Margolis nos encorajou a concluir cada sprint com um teste concreto. Ele pegou a pesquisa de satisfação do cliente, que pode levar semanas para ser planejada e executada, e encontrou uma forma de obter resultados claros em apenas um dia. Foi revelador. Não precisávamos adivinhar se nossas soluções eram boas. Tínhamos respostas no fim de cada sprint.

E há também Daniel Burka, um empreendedor que fundou duas startups, vendeu uma para o Google e se juntou ao GV. Quando lhe descrevi o processo de sprint pela primeira vez, ele o encarou com ceticismo. Como diria mais tarde, “parecia um monte de abobrinha administrativa”. No entanto, concordou em fazer uma experiência. “Naquele primeiro sprint, deixamos toda a conversa fiada de lado e fizemos algo ambicioso em apenas uma semana. Fui fisgado.” Depois que o convencemos, a  experiência em primeira mão de Daniel como fundador e sua completa intolerância a qualquer papo furado nos ajudaram a aperfeiçoar o processo.

Desde o primeiro sprint no GV, em 2012, fizemos ajustes e testes. A princípio, achávamos que desenvolver protótipos e pesquisas com rapidez  só daria certo com produtos de massa. Será que poderíamos trabalhar em um ritmo tão acelerado se os clientes fossem especialistas em áreas como  medicina ou finanças?

Para nossa surpresa, o processo de cinco dias se sustentou. Estava funcionando para todos os tipos de clientes, de investidores a fazendeiros, de oncologistas a pequenos empresários. Funcionava para sites, aplicativos de iPhone, relatórios médicos impressos e hardwares de alta tecnologia. E não servia apenas para o desenvolvimento de produtos. Usamos os sprints na priorização, na estratégia de marketing e até para dar nomes a  empresas. O processo sempre une as equipes e dá vida às ideias.

Será que poderíamos trabalhar em ritmo tão acelerado em projetos de áreas como medicina ou finanças?

Nos últimos anos, nosso time teve uma oportunidade sem precedentes de testar e validar ideias sobre processos de trabalho. Conduzimos mais de cem sprints com as startups que compõem o portfólio do Google Ventures. Trabalhamos lado a lado e aprendemos com empreendedores  brilhantes como Anne Wojcicki (fundadora da 23andMe), Ev Williams (fundador do Twitter, do Blogger e do Medium), Chad Hurley e Steve Chen (fundadores do YouTube).

No início, eu queria tornar meus dias de trabalho mais eficientes e relevantes. Queria me concentrar no que realmente importava e aproveitar ao máximo meu tempo – para mim, para minha equipe e para nossos clientes. Hoje, mais de uma década depois, o processo de sprint tem me ajudado de forma consistente a alcançar esse objetivo. E estou muito animado para compartilhá-lo no livro Sprint.

Com sorte, você escolheu seu trabalho em virtude de uma visão arrojada. Você quer dividir essa visão com o mundo, seja ela uma mensagem, um  serviço, uma experiência, um software, um hardware ou até – como no caso do livro Sprint – uma história ou uma ideia. Contudo, dar vida a uma  visão não é simples. É muito fácil ficar preso no caos: e-mails intermináveis, prazos estourados, reuniões que consomem o dia inteiro e projetos de longo prazo baseados em premissas questionáveis. 

Não precisa ser assim. Os sprints oferecem um caminho para resolver grandes problemas, testar novas ideias, fazer mais coisas em menos tempo. Também permitem que você se divirta mais ao longo dessa trajetória. Em outras palavras, você precisa, sem dúvida alguma, experimentar um sprint. Mãos à obra.