Olá, pessoal!

Meu nome é Angélica e sou Agile Coach na Lambda3. Faço minha estreia no blog, compartilhando percepções geradas a partir  de uma experiência recente.

Para mim, a grande graça da vida é encarar desafios… Sejam eles quais forem. Desde aprender a fazer uma receita diferente até viajar a um lugar desconhecido sozinha, com todas as variáveis possíveis a esses e outros cenários.

Há algumas semanas, fui convidada a facilitar a Inception de um projeto. Fiquei muito feliz com essa possibilidade, já que há cinco meses não sabia do que se tratava, a aproximadamente três vi uma sendo executada e naturalmente, queria fazer isso funcionar.

Esclarecendo os que estavam na mesma situação que eu há cinco meses, Inception é uma atividade que reúne todos os envolvidos em um projeto, de stakeholders a desenvolvedores, com o objetivo de, colaborativamente, alinhar as expectativas sobre este projeto, estabelecer sua visão, identificar usuários, entender necessidades, dar clareza a pontos de incerteza, organizar o trabalho, planejar releases, enfim, fornecer uma estrutura para que que essas pessoas conversem e definam o caminho a seguir.

Convencionalmente, a duração da inception é de cinco dias. Em virtude da indisponibilidade de agenda do cliente, precisamos enxugar esse tempo e realizar as atividades em três dias. Com esse adendo, foi necessário maior cuidado para que a execução não fosse demasiadamente acelerada e não se perdêssemos qualidade.

Ok, convite aceito. E agora? Nessa hora você para e pensa: “Será que não deveria esperar mais um pouco… Estudar mais, ver mais algumas sendo facilitadas por pessoas mais experientes?” Não. Não deveria. Aproveite a oportunidade e corra atrás de fazer bem feito, de preferência sem surtar no meio do caminho, pensei.

A parte do correr atrás é a mais bacana. Requer esforço e dedicação, como de um modo geral, tudo que fazemos. A absorção de conhecimento que me oferecesse mais segurança e assim, respaldasse a condução das atividades de forma que houvesse o melhor aproveitamento do tempo disponível, ocorreu basicamente através de revisão bibliográfica (por mais formal que isso possa parecer) e conversas com facilitadores mais experientes.

A metodologia aplicada nessa Inception que facilitei foi a Direto ao Ponto, elaborada pelo Paulo Caroli, que generosamente a compartilhou com a comunidade através de seu livro de mesmo nome, além de posts em seu site.

Ler, reler, de novo e mais uma vez, agora com anotações, e novamente, revisa as anotações, volta para o livro, só para se certificar de que não faltou nada… Ajuda. Mas no fim me soou mais como uma tentativa de ganhar experiência através de cada página virada. O que é uma ilusão.

Chama para tira-dúvidas disfarçados de bate-papos, facilitadores mais experientes. Nesse momento, menciono o Victor Hugo Germano, que também generosamente me cedeu seus ouvidos, talvez nas horas mais inoportunas, mas sempre com disponibilidade e paciência análogas a de monges budistas. Mais uma tentativa de ganhar experiência através da vivência de outras pessoas. Da mesma forma que as referências bibliográficas, ajuda, mas ainda fica aquela sensação de que falta alguma coisa.

Finalmente chega a data marcada. Participantes devidamente convidados e confirmados, materiais necessários separados e sala reservada. Agora é fazer acontecer.

Dia 1

Passados os momentos iniciais de certo nervosismo, a condução das atividades vai se desenrolando de forma mais tranquila. É a segurança que aparece quando se lembra que absorveu conteúdo suficiente para esse ponto de partida.

O primeiro dia foi dedicado a apresentação da proposta e dos participantes, definição da visão do produto e também do que ele é, não é, faz e não faz. O interessante dessa abordagem (É, Não é, Faz e Não faz) é que o produto vai ganhando contornos mais concretos através da definição do que não é e o que não faz, o que não é muito comum de se questionar.

Esclarecemos seus objetivos, através de percepções individuais e em seguida, coletivas, utilizando a seguinte pergunta:“Se você tivesse que resumir este produto em 3 objetivos para seus usuários, quais seriam?“.

Também abordamos os trade-offs, que expõe itens desejáveis ao produto e incentiva a discussão sobre trocas, de acordo com a importância de cada um perante outro. Esse, considero o ponto mais crítico do dia. Não pela complexidade da atividade, mas pela quantidade de informações geradas e seu gerenciamento. Como após o levantamento dos itens os participantes podem eleger suas prioridades, combinando a quantidade de itens e a quantidade de participantes, a atividade ficou um pouco extensa e cansativa. Minha melhoria nesse caso para a próxima facilitação, é limitar a quantidade de itens a no máximo 10, favorecendo maior dinamismo e objetividade na consolidação do resultado.

Terminando a atividade dos trade-offs, iniciamos o trabalho com as personas do sistema ao qual o projeto se referia.  Ao meu ver esse é um dos pontos altos da inception, sem desmerecer os outros. Creio que quando damos a devida atenção aos nossos usuários, entendendo seu perfil, comportamentos e necessidades, já começamos a trilhar um bom caminho rumo ao sucesso. Estimular a discussão sobre esse tema força a equipe a dar atenção a detalhes que muitas vezes passam despercebidos ao longo do processo e podem ter grande impacto no atendimento à essas pessoas.

Dia 2

No segundo dia, precisamos dar continuidade à atividade de entendimento das personas, pois foi identificado que aquelas levantadas até então, não cobriam todos os perfis relevantes existentes. Finalizada essa etapa, iniciamos o trabalho de descoberta de features, cruzando as personas elencadas como mais críticas com os objetivos do projeto. Respeitando as prioridades estabelecidas para cada persona e objetivo, o questionamento de apoio ao grupo foi: “O que o sistema necessita oferecer para que tal persona alcance determinado objetivo?“.

Esse passo foi realizado até que cada persona tivesse suas features mapeadas para que alcançasse todos os objetivos levantados. O interessante desta atividade, é que utilizamos dois pontos de suma importância para o projeto: seus objetivos e seus usuários. Considerando essas duas fontes, entender o que precisamos disponibilizar fica muito mais claro, embora gere bastante discussão, o que no momento é ótimo para alinhar entendimentos e expectativas.

Após a descoberta das features, passamos à fase de compreensão técnica e de negócio sobre cada uma delas. Para isso, foi disponibilizado um gráfico com dois eixos, onde um se referia ao entendimento técnico, com três níveis (alto, médio e baixo)  e o outro se referindo ao entendimento de negócio, com os mesmos níveis sinalizados.

Cada participante recebia uma feature e a posicionava no gráfico onde considerava mais adequado, utilizando seu nível de compreensão técnica e de negócio. Isso era o estopim para a discussão e detalhamento da feature em questão. As informações levantadas nessa discussão eram anotadas no verso do cartão onde a feature estava descrita, para respaldar discussões futuras.

A medida em que eram encerradas as discussões, cada cartão recebia um registro sobre o risco que a compreensão (ou ausência dela) representava para o projeto: vermelho para alto risco, amarelo para médio risco e verde para baixo risco. Reproduzimos esse passo até todas as features terem seus entendimentos técnico e de negócio avaliados pelo grupo.

Dia 3

Entendimentos alinhados, a etapa seguinte foi a identificação do valor de negócio e do esforço para a implementação de cada feature. Também utilizamos um gráfico, similar ao utilizado na atividade anterior, porém, com eixos correspondendo a valor de negócio, sendo os níveis alto, muito alto e altíssimo e, esforço com os níveis baixo, médio e alto. A medida utilizada no valor de negócio é bem interessante, porque remove o desconforto do cliente em admitir que uma feature tem baixo valor, sendo assim, todas possuem valor de negócio considerável, bastando entender o quão alto ele é comparado com outras.

O princípio dessa atividade é similar ao utilizado anteriormente. Cada participante posiciona uma feature onde entende que melhor se enquadre no gráfico. Discutimos sobre a opinião e a feature recebe uma nova marcação, sinalizando seu valor de negócio e esforço.

Após identificar todos esses pontos feature a feature, começamos a organizar o MVP (Minimum Viable Product) do projeto, que é a versão mais simples e funcional que pode ser disponibilizada ao usuário.

O canvas destinado a essa atividade, é dividido em ondas. Cada onda representa um agrupamento de features, que tem como objetivo organizar o trabalho a ser realizado. Respeitando regras pré-estabelecidas, como quantidade limite de features, combinação de riscos permitidas, bem como somatória de valor de negócio e esforço, os participantes foram posicionando os cartões com as features em cada onda.

Finalizada a organização do canvas, discutimos que ondas de fato corresponderiam a cada MVP. Conforme a discussão ia evoluindo, marcávamos na onda final que MVP ela limitava.

Organizados os MVPs, elegemos três ondas para servirem de base para as estimativas do projeto. Embora a escolha seja livre, é interessante que sejam ondas representativas para os primeiros MVPs.

Para cada feature das ondas escolhidas, serão definidas histórias de usuários que em seguida serão estimadas.

Os participantes foram divididos em trios e a cada um foi entregue um cartão contendo uma feature para ser detalhada. Após cinco minutos de trabalho, era feito um rodízio de features para que todas passassem por todos os trios, evitando que ficassem sob a visão de apenas um grupo de pessoas.

Histórias de usuários definidas, chegamos a fase de comparação de tamanho entre elas. Na própria mesa em que estávamos trabalhando, sinalizamos os extremos com o sinal de + e de – . Selecionamos duas histórias e o grupo foi questionado: Quanto ao esforço de realização, onde posicionamos essa história nessa escala? Em seguida, comparando uma com a outra: Considerando a história anterior, essa requer mais ou menos esforço para ser implementada? E assim por diante, até todas as histórias terem sido contempladas e organizadas na mesa. Neste momento, separamos as histórias de tamanho P, M e G, sendo respectivamente, pequenas, médias e grandes para assim, termos uma melhor dimensão dos nossos itens de trabalho.

Embora nos ofereça uma boa perspectiva sobre a dimensão do trabalho para as features selecionadas, essa estimativa comparativa não nos atende quando a intenção é descobrir quanto tempo levará para a que os MVPs sejam disponibilizados aos usuários. Para levantarmos essa informação, a equipe técnica, que está presente, avalia e estima cada história de usuário.

Nessa inception, a medida utilizada foi de 1 dia de trabalho de um desenvolvedor, que equivale a 8 horas. Então, considerando todo o fluxo da história (entendimento, elaboração de testes, codificação, testes, entrega para homologação) o questionamento foi o seguinte: Quantos dias de trabalho um desenvolvedor levaria para completar essa história?

Repetimos esse processo até que novamente todas as histórias tivessem sido atendidas. Quando foram, somamos os dias estimados para cada história de cada feature e em seguida, o total de dias de todas as features de cada onda.

Para exemplificar o resultado, supomos que as 3 ondas que elegemos como amostra para detalharmos as histórias e embasar nossa estimativa estavam com o seguinte formato:

Onda 1: 2 features;
Onda 2: 3 features;
Onda 3: 2 features.

Somando as estimativas das histórias, chegamos ao resultado de que a feature 1 da primeira onda levaria 10 dias para ser realizada e a feature 2 levaria 12 dias;

Na onda 2, a primeira feature levaria 8 dias para ser realizada, a segunda 13 e a terceira 15;

Na onda 3, a primeira feature foi estimada em 9 dias e a segunda em 11;

Sendo assim, o total de dias para a realização de cada onda, é:

Onda 1: 10 + 12 = 22 dias;
Onda 2: 8 + 13 + 15 = 36 dias;
Onda 3: 9 + 11 = 20 dias.

Com esses dados, tiramos uma média para determinar qual é o tempo que cada onda demoraria para ser implementada:

22+36+20 = 78
78/3 = 26

Em média, cada onda levará 26 dias de trabalho para ser desenvolvida. Esse tempo considera o trabalho de apenas um desenvolvedor, como era o cenário do projeto onde essa inception foi realizada. Quanto mais pessoas na equipe, teoricamente, menor o tempo de desenvolvimento.

Graças ao fato de as ondas respeitarem um padrão de organização, possuem basicamente a mesma complexidade e tamanho, possibilitando que apliquemos o resultado da média de tempo de desenvolvimento em todas as demais.

Esse resultado é apresentado aos envolvidos que por ventura não estiveram no decorrer na inception e também documentado, sendo da mesma forma, enviado aos participantes/interessados.

Conclusão

Concluo exteriorizando a sensação de missão cumprida. Naturalmente, identifiquei diversos pontos que posso melhorar, muitos dos quais compartilhei ao longo desse texto, porém, esses pontos foram levantados a partir da minha própria experiência, o que fornece um pouco mais de tranquilidade para as futuras facilitações. Assim, “a coisa que estava faltando” no começo aparece, e nada mais é do que a prática. É cansativo, mas muito enriquecedor.

Reforço que todas essas atividades estão melhor detalhadas no livro Direto ao Ponto, do Paulo Caroli.

Que venha a próxima inception!