Transcrição:
Clique na frase para navegar pelo vídeo

Obrigado. Bom dia.

O resto da apresentação será em inglês. Infelizmente, isso é tudo o que sei dizer em português. Mas, felizmente, temos aqui atrás

a ajuda de excelentes tradutores. Vou falar hoje sobre o design sprints. Um design sprint pode ser aplicado a um grande desafio,

um projeto importante que uma equipe esteja para começar. Algo que será custoso, em termos do tempo e/ou dinheiro necessário para sua conclusão.

Uma situação em que as pessoas precisem Uma situação em que as pessoas precisem garantir que estão no caminho certo.

garantir que estão no caminho certo. Você deve formar uma equipe pequena, de cinco, seis, sete pessoas

com diferentes competências, de diferentes áreas de especialidade. Assim, você não terá apenas uma equipe

de engenharia ou de design. Terá um time com um mix de diferentes perspectivas. Também terá alguém com poder decisório.

Pode ser o CEO, ou o líder de projeto. Alguém na sala será responsável por tomar decisões ao longo do sprint sobre o que fazer e qual

é o melhor caminho a seguir. Então a equipe vai separar o período de uma semana, limpar a agenda e, em vez de seguir os processos padrão

de reuniões e conversas, vai usar uma lista de tarefas, um roteiro. A ideia de usar o roteiro é eliminar todo o estresse

sobre a discussão do que fazer. A lista de tarefas fornece todos os passos a serem seguidos e permite um avanço

muito rápido e eficaz. No final do livro “Sprint”, há uma lista de tarefas de 14 páginas.

A lista está toda no livro e é extremamente específica. Indica que tipo de materiais de escritório, canetas e papel você deve comprar.

Quais lanches você deve disponibilizar. Diz como fazer as coisas em incrementos de 10 e 15 minutos.

Até mesmo diz quando você pode ir ao banheiro. É extremamente prescritiva. Não vou entediar vocês descrevendo

Não vou entediar vocês descrevendo a lista completa aqui... a lista completa aqui... O que eu quero é apresentar a vocês é o ponto-chave,

o foco de cada um dos cinco dias do sprint. Na segunda-feira, a equipe mapeia o escopo do problema. Isso é muito importante, porque, por padrão,

as equipes tendem a pensar no todo. Se você está trabalhando em um projeto grande e importante, precisa fazer isso, pensar na complexidade

da coisa como um todo... Mas, muitas vezes, pode ser paralisante pensar em como o sistema inteiro funciona.

Acontece de você reunir as pessoas em uma sala e elas começarem a falar sobre como as coisas funcionam, e todo mundo tem uma perspectiva um pouco diferente,

um jeito distinto de ver as coisas. Essa troca de informações que às vezes ocorre se mistura com as ideias de como resolver o problema,

com debates sobre o que é melhor fazer e alguém pode ter um monte de ideias sobre suas perspectivas

e o processo todo acabar sendo muito frustrante. Essa é uma reunião típica e é muito frustrante. O que acontece em um sprint

é que capturamos toda essa informação para conseguirmos focar em um momento chave. Durante o sprint, não podemos resolver tudo.

Focamos somente no ponto mais importante e, assim, conseguimos concluir a tarefa em uma semana. No sprint, as conversas vão sendo registradas

enquanto acontecem. Nós as anotamos em um quadro branco e pensamos em como realizar tudo aquilo, nas diferentes

perspectivas das pessoas sobre o produto, no que estamos desenvolvendo, em como tudo se encaixa.

Depois, simplificamos as informações e definimos, com a ajuda do encarregado das decisões, qual é o momento mais importante do mapa.

Qual é o ponto, o alvo em que devemos nos concentrar. Para vocês terem uma ideia de como isso funciona em uma empresa real, esta é uma companhia

de serviços médicos que está avaliando quem são seus clientes como eles, em um nível muito simples e elevado, como eles, em um nível muito simples e elevado, se movimentam no produto

se movimentam no produto e qual é o resultado que esperam no final. Desse modo, o responsável pelas decisões é capaz

de definir qual é o cliente e o momento mais importante do mapa, nos quais é preciso focar. Parece muito simples, mas a reunião da equipe

e o processo de fazer o mapa e decidir no que focar são extremamente poderosos, porque, assim, no resto da semana, não será necessário ter um monte

de discussões sobre o que está sendo feito. Todo mundo sabe no que está focando. E são maiores as chances de você perceber quando

há um momento de risco ou oportunidade que talvez acabaria perdendo. O mais importante talvez seja o marketing do produto,

não o produto em si. Talvez seja o discurso de venda o mais importante e seja nele que toda a equipe precise se concentrar para definir

o que construir, não no próprio produto. No segundo dia, a equipe decide no que focar e esboça soluções, define como será o projeto...

O padrão para muitas equipes é fazer um brainstorm em grupo. Todos se reúnem e começam a despejar ideias,

basicamente produzindo ideias o mais rápido possível. Às vezes, as pessoas misturam suas ideias com um pequeno

discurso de vendas para tentar discurso de vendas para tentar fazê-las parecer muito boas.

fazê-las parecer muito boas. Dependendo de quão bem alguns vendem suas ideias e são extrovertidos nessas reuniões,

elas podem ser muito frustrantes para introvertidos... Alguns membros da equipe podem querer mais tempo para pensar.

Ou podem ser novos no time e ainda não estarem à vontade. Por isso, muitas vezes não ouvimos as vozes de todos nesses brainstorms em grupo.

E sempre tem alguém capaz de se sobrepor aos outros com o volume de ideias que consegue produzir. O que eu vi diversas vezes na Google foi que esses brainstorms

em grupo eram muito legais, as pessoas adoravam, estávamos trabalhando como um time. Na superfície, parecia estar correndo tudo bem.

Mas acontecia, às vezes, de um pessoa mais quieta continuar pensando sozinha por algum tempo e, com esse tempo, a ideia ficava mais sofisticada.

Partia-se de uma ideia para uma solução. E, com essa solução, ela podia usar seus “superpoderes”. Se fosse uma desenvolvedora, poderia programar um protótipo.

Se fosse uma designer, poderia criar um modelo visual. Talvez, se fosse gerente de produto, elaborasse as especificações do produto.

Mas essa solução detalhada, quando levada de volta para a sala onde todo mundo teve meio que suavizar suas soluções para que fossem aceitas

por todos, quando a pessoa traz essa solução muito bem pensada, as ideias dos outros muito bem pensada, as ideias dos outros simplesmente não são páreo.

simplesmente não são páreo. Foi isso o que vi acontecer na Google muitas e muitas vezes. E achei que seria muito legal se pudéssemos ouvir

de todo mundo qual seria sua solução cuidadosamente ponderada, caso conseguíssemos elevar uma ideia até aquele nível de detalhamento.

Em um sprint, cada pessoa trabalha sozinha, em silêncio. Todos ficam juntos na mesma sala, mas cada um trabalha trabalha individualmente para produzir uma solução detalhada.

E é assim que funciona... Efetivamente, isso possibilita que cada pessoa Efetivamente, isso possibilita que cada pessoa elabore essas ideias.

elabore essas ideias. Mas permite também que elas deem um passo além e transformem suas ideias em soluções e, então,

coloquem essas soluções no papel, de modo que não seja preciso discuti-las. Podemos simplesmente olhá-las anonimamente.

Esta é uma sala durante uma seção de sprint. Parece muito chato. É como se todos estivessem fazendo uma prova

ou um teste surpresa. O que acontece aqui é que todo mundo tem tempo de pensar, elaborar os detalhes de que precisa para explicar

como sua solução funciona, sem ter que fazer isso verbalmente, o que pode ser um fator limitante para alguns membros do time.

No fim do dia, na terça-feira, temos soluções detalhadas. Que realmente descrevem com funcionam. E haverá muitas delas competindo entre si.

Cada um tem sua opinião e essas opiniões entrarão um pouco em conflito. Isso é muito saudável e proveitoso.

Na quarta-feira, temos todas essas diferentes soluções e é preciso decidir qual delas virarão protótipos e serão testadas.

Muitas vezes, escolhemos duas ou três para fazer protótipos e testes. O mais comum para a maioria das equipes é discutir o tema,

apenas falar sobre o assunto. Mas, em um sprint, tomamos uma decisão rápida e decisiva, e fazemos isso usando uma estrutura que nos guia ao longo

do processo, e o encarregado da decisão dá a palavra final. Não é uma decisão democrática. A pessoa com poder decisório é quem escolhe no fim.

Após ter todas as soluções no papel, vamos colocá-las na parede e apenas ler o rascunho de todos sem comentar.

Vamos entender apenas com a leitura. É assim que funciona… Em silêncio, o time avalia os esboços.

Não há nomes nas folhas, assim, as pessoas não se distraem pensando coisas como “nossa, este aqui é do CEO”.

Todos apenas leem o conteúdo que está ali, avaliando o mérito de cada solução. Então, há um discussão estruturada sobre cada esboço

ou sobre as melhores partes de cada um, mas ninguém pode tentar vender sua ideia. Depois que cada membro da equipe argumenta

a favor de uma solução, finalmente, a pessoa indicada toma uma decisão. A responsável escolhe uma ou duas soluções,

talvez três, para as quais serão feitos protótipos e testes naquela semana. Na quinta-feira, a equipe cria um protótipo.

Essa palavra significa muitas coisas diferentes para pessoas diferentes em contextos diferentes. Mas, em um design sprint, há uma noção

muito específica do que seja um protótipo. Um protótipo é algo realista. Uma simulação realista do produto.

A maioria das equipes quer avançar rápido para construir um produto minimamente viável e obter dados no mundo real.

No sprint, apenas simulamos como se já tivéssemos o produto final. Fazemos uma fachada, uma representação do produto

e com ela conseguimos simular como será o lançamento. Assim, testamos o protótipo em um cenário realista. Em geral, a maioria das equipes apenas aguarda.

Simplesmente precisa confiar no seu instinto e criar um produto que não saberá se vai funcionar, de fato, até que esteja no mundo real.

Em um sprint, logo de cara você consegue dados preliminares, que permitem dizer o que está acontecendo imediatamente.

Não são dados perfeitos. Não é o que se consegue em um lançamento, mas é o suficiente para dizer se você

está no caminho certo. Vejam como isso é feito… É uma entrevista individual.

Bastante simples, com uma pessoa do time de sprint e um cliente-alvo. O cliente-alvo está olhando para o protótipo.

A pessoa do sprint apenas faz algumas perguntas... Em um dia, fazemos cinco dessas entrevistas individuais. Não há grupos de foco nos quais eu não confio.

Não acredito que grupos de foco sejam confiáveis. Mas, nessas cincos entrevistas individuais, temos uma simulação bastante precisa de como será quando

o produto estiver no mundo real e as pessoas estiverem reagindo a ele. Enquanto essas entrevistas são feitas,

o resto da equipe assiste por vídeo. Em outra sala, o time acompanha as entrevistas e faz anotações.

No fim do dia, temos resultados. Estes são os resultados de um sprint real da marca da startup. Percebam que há muita coisa em vermelho.

Cada coluna representa um dos clientes entrevistados. Dá para ver que há muito vermelho, muitas coisas que não funcionaram no protótipo.

Há o suficiente para observar um padrão, e o padrão não é bom. Mas, se olharmos pela perspectiva da equipe, estamos em uma posição excelente.

Após uma semana de trabalho, a equipe testou sua melhor aposta de produto e não deu certo. Em circunstâncias normais, a equipe teria

se comprometido com a ideia porque todos estariam muito entusiasmados, e gastaria semanas, meses ou até um ano lançando

e colocando o produto no mercado para só então descobrir todas essas áreas vermelhas. No nosso caso, todas as pessoas relevantes

para o projeto estão na sala. O encarregado das decisões está na sala. Todo mundo tem o mesmo contexto sobre

o que os clientes disseram, como reagiram. Todos têm o mesmo contexto sobre por que aquela solução foi escolhida e todos podem ver onde está a lacuna

entre o ponto em que estamos e aonde queremos chegar, e como construir uma ponte sobre essa lacuna. Isso em geral fica bem claro.

Aqui estão os resultados reais da semana seguinte, quando a equipe consertou o protótipo, fez as alterações que eram óbvias para todos e o testou novamente.

É muito comum vermos isto: na segunda repetição do sprint, os clientes olham para o produto e entendem a história por trás dele.

É basicamente disso que se trata: conseguir fazer a equipe encontrar a história do produto que está sendo criado e, então,

transmiti-la para os clientes de modo eficaz. Às vezes, você vai acertar de primeira. Mas, muitas vezes, a equipe vai acertar na segunda semana.

O ponto-chave é acertar logo no começo do processo, antes de se comprometer com um lançamento. Estamos falando de dados restritos

e de uma simulação, mas tudo isso é bom o suficiente para você ter confiança de que está no caminho certo. Quero dar a vocês uma amostra de como é trabalhar desse jeito,

com uma organização que implementa sprints. No final da semana, dez equipes da empresa empresa haviam conduzido um total de 80 sprints.

Todos tinham passado pela experiência. Isso provocou uma transformação na organização, no modo como se pensava o trabalho em equipe.

Portanto, em uma abordagem “de cima para baixo”, é realmente o melhor método. Acho que a melhor maneira de responder a essa questão,

sobre como convencer alguém de que vale a pena dedicar tempo e recursos de uma semana inteira, é perguntar “Quanto você gastará se não fizer isso?”

e “Você já errou antes? Quanto custará se você estiver errado?”. A resposta geralmente é que custaria muito mais

do que uma semana de trabalho de cinco pessoas. Realmente acredito que essa seja a forma mais simples de entender a questão.

É uma barganha. É um modo não convencional de pensar, mas é uma barganha se comparado a como costumamos trabalhar.

Bom, pessoal, vou encerrar por aqui. Há um cartão destes em cada lugar... É uma espécie de resumo do processo de sprint

e de como ele funciona. Pelo menos eu acho que é... Está tudo em português, então, pode ser um cardápio,

mas acredito que seja sobre o processo de sprint. Como comentei antes, o livro também está disponível em português.

Estarei por aqui caso vocês tenham mais perguntas. Se alguém tiver alguma dúvida, pode me procurar. Muito obrigado pelo seu tempo e pela atenção.

Fico realmente muito grato.