Quando vocês irão finalizar a entrega do projeto? A equipe irá atender o prazo estipulado? Vocês conseguirão entregar até a data? Se você trabalha com projetos, certamente irá perder a conta se tentar somar quantas vezes precisou responder a esses tipos de questionamento.

Quando estamos lidando com prazos, famosos deadlines (não poderiam ser successlines?!), essas perguntas provavelmente irão surgir em vários momentos do projeto antes da entrega, e com certeza muitas outras vezes se o prazo inicial não for atendido. Independentemente do período em que esteja o projeto, você já pensou que muitos problemas relacionados com essas perguntas são causados por falta de alinhamento na expectativa da data de entrega?

Aqui na Ptec estamos trabalhando com uma dinâmica chamada Reality Check, ou verificação de realidade. É uma dinâmica muito eficaz para quando há um prazo de entrega bem apertado. Meu amigo Lucas Colucci contou um pouco sobre como esta dinâmica funciona em seu blogpost Desenvolvendo melhoria contínua em seu processo ágil: A cerimônia de Reality Check. Nós testamos esta dinâmica e a evoluímos e, com isso, encontramos algumas novas práticas que podem agregar valor para esta ferramenta. Nos exemplos que serão apresentados a seguir, os resultados foram muito positivos! Vamos conhecer?

Salvando o prazo do seu projeto!

Arrisco defender o seguinte: na maioria das vezes, é mais relevante para o projeto deixar as expectativas de data de entrega bem alinhadas do que efetivamente cumprir um prazo inicialmente empurrado para a entrega do projeto. Defendo isso porque, no início do projeto, ou de alguma parte dele, dificilmente conseguimos prever uma data precisa de entrega, pois as diversas variáveis que interferem nessa promessa de data influenciam demais no que efetivamente irá acontecer, como, por exemplo, ausências diversas, feriados e as deliciosas emendas de sextas-feira, desmotivação, problemas novos não existentes no início do planejamento, mudanças de escopo não controladas, férias de colaboradores não programadas com antecedência, entre tantas outras. Entretanto, todos esses pontos não significam que não podemos mostrar o que realmente está acontecendo. Prazo não deve ser uma restrição, mas sim uma meta!

É possível trabalhar a questão abordada de uma forma bem simples: deixe claro, de forma explítica e antecipada, quando a entrega irá efetivamente ocorrer. Dessa forma, seu cliente sempre terá o controle da situação, caso a equipe descubra antecipadamente que o prazo inicial não será atingido.

A ideia é muito simples: mostrar a realidade do que está acontecendo no time, concedendo visibilidade quanto ao prazo! Apresentar a real situação ajuda a deixar as expectativas de data de entrega muito bem alinhadas, e de forma antecipada. De quebra, em um formato colaborativo, o Reality Check tem a capacidade de empoderar a equipe sobre a apresentação da data de entrega e, dessa forma, cria um vínculo de parceria e responsabilidade com seu cliente. A mensagem é que somos um único time, e estamos fazendo o melhor!

Explica como funciona?

Primeiramente, tenha o seguinte cenário: um escopo e um prazo. Bem simples, não? Segundo passo: obtenha o detalhe do escopo de alguma maneira. Isso pode ser feito via Story Mapping, decomposição do escopo para obter os pacotes de trabalho de uma EAP (Estrutura Analítica do Projeto), grupos de tarefas de um cronograma, etc. Enfim, tenha um conjunto de itens que, juntos, somam todo o escopo de sua entrega. É importante também que esses itens sejam, mais ou menos, de “tamanhos” semelhantes ou de mesma natureza técnica, evitando misturar demandas muito grandes com as muito pequenas, por exemplo. No nosso caso, usamos histórias de usuário de um Backlog de produto, todas oriundas de um Story Mapping e, na medida do possível, já priorizadas no contexto da próxima entrega do projeto.

Em seguida, escreva todos os seus itens de escopo em post-its (existe algo melhor do que esses papeizinhos que grudam?). Depois, em um quadro branco, por exemplo, ao lado direito de todos os seus itens de escopo, desenhe faixas verticais de períodos iguais que representam a evolução temporal do projeto, ou, em outras palavras, faça várias faixas que mostrem cada semana até a data de entrega do projeto. A última faixa poderá corresponder à data de entrega. Não recomendo dividir esses períodos em dias ou meses, pois são distâncias curtas e longas demais, respectivamente. Depois, trace uma linha horizontal quase no topo do quadro e, em cada espaço de faixas verticais, declare qual é o respectivo período que aquele intervalo representa no projeto.

Para facilitar, você poderá fazer essa dinâmica no primeiro dia de trabalho de uma semana. Não recomendo que o Reality Check seja feito para um período muito longo. Entendo que, no máximo, um trimestre (entre 12 e 14 semanas) seja aceitável para que a dinâmica funcione corretamente. Um período maior do que este fará com que a equipe não consiga ter uma visão adequada e acabe estimando o trabalho futuro de uma forma muito relativa. Quanto mais distante, menos assertivo. Dessa forma:

Feito isso, reúna o time, apresente o desenho e peça para a equipe mover os itens que estão no Backlog para dentro das faixas semanais, declarando em qual semana cada item irá ser finalizado, e não quando começam (faremos isso de outra maneira). Se o mesmo item for durar mais do que uma semana, não é necessário duplica-lo, mas somente coloca-lo na semana de término. O objetivo é distribuir todos os itens na linha do tempo, estimando o quanto de trabalho será feito em cada semana e, principalmente, descobrindo se é possível encaixar todo o esforço do projeto dentro do prazo solicitado pelo cliente. É extremamente importante que a equipe tenha a autonomia de distribuir seus respectivos trabalhos no quadro, e que o gestor do produto / PO esteja presente durante essa parte da dinâmica.

A equipe não precisa buscar ser extremamente assertiva quanto a essa distribuição, mas sim tentar encontrar um volume de trabalho semanal que seja condizente com a realidade. É interessante que, neste momento, a equipe perceberá se será possivel atingir o prazo do projeto e quais são as dependências entre cada item do escopo. Vários outros debates podem surgir e, de repente, você poderá ter a primeira oportunidade de negociar o prazo do projeto ou, se este for inegociável, tentar reduzir o escopo para que ele se encaixe dentro do período mostrado no Reality Check.

Ao final, para finalizar essa primeira parte da dinâmica, distribua um post-it para cada membro do time e, de forma individual, cada um (exceto o facilitador e o gestor do produto / PO) escreverá um valor de 1 a 4, sendo a menor nota representando que a data de entrega não é factível de ser atingida e, à medida que a nota aumenta, o prazo é plausível de ser atingido. Depois, o facilitador da dinâmica calcula a média dessas notas e apresenta para a equipe. Se a nota for 1 ou 2, é interessante rever o planejamento colocado no Reality Check. Se for 3 ou 4, é possivel entender que todos estão confortáveis quanto ao prazo da entrega do projeto. Também é válido conceder a oportunidade para quem colocou notas extremas (1 e 4) comentarem suas posições, visto que essas pessoas podem estar enxergando pontos que os demais membros do time deixaram passar despercebidos. Algum plano de ação poderá surgir neste momento, com o objetivo de melhorar alguma nota baixa, por exemplo.

Na segunda semana, no primeiro dia de trabalho, todos se reúnem novamente para atualizar o Reality Check. É interessante que o cliente esteja presente nesses momentos de atualização do quadro. Agora, a equipe irá deixar os itens que foram concluídos na semana anterior e, caso todos não tenham sido concluídos, o time deverá pensar como irá realocar os itens remanescentes na semana corrente e/ou nas próximas e, portanto, movendo algo que estava nessa semana para a próxima, e assim sucessivamente. Repetindo isto em todas as semanas, a equipe conseguirá alocar os trabalhos do projeto nos períodos e, dependendo da situação, visualizará que a entrega não conseguirá ser desenvolvida até a data estipulada, ou que será necessário a alocação de mais pessoas para o projeto, ou reduzir o escopo, entre outros. Ou seja, o cliente terá visibilidade sobre o andamento do projeto e conseguirá apoiar a equipe a encontrar opções viáveis para solucionar a questão. A foto abaixo, tirada de um exemplo desta dinâmica, reflete a situação do projeto em uma sexta semana:

Para complementar a dinâmica, a equipe poderá adotar alguns mecanismos visuais para ajudar a interpretar cada item do Reality Check. Como sugestão, colocamos:

• Um adesivo azul, no canto superior esquerdo do post-it, para mostrar quando aquele item (no nosso caso, histórias de usuário) estava em desenvolvimento;
• Um adesivo vermelho, no canto inferior esquerdo do post-it, para representar algum bloqueio naquela história de usuário (algo que esteja atrapalhando o andamento do desenvolvimento, ou algum impedimento que precisa ser removido);
• Um adesivo retangular, no canto superior direito do post-it, para declarar em qual semana aquela história de usuário tinha começado a ser desenvolvida (somente para quando a semana de início não era a mesma de término da história);
• Um post-it amarelo menor, no canto inferior direito do post-it principal, que representava alguma pendência daquela história (com um pequeno texto explicativo).

Além disso, quando havia dependências entre os itens, como, por exemplo, a história de usuário B somente poderá começar após o término da história A, a equipe desenhava uma seta de ligação, a fim de representar esta dependência. Post-its de cores diferentes também podem ser utilizados para que haja uma identificação de tema, como, no nosso exemplo, uma cor para representar histórias de desenvolvimento de código e uma outra cor para demandas relacionadas com layout. O “tamanho” de cada item também poderá ser declarado, evitando que a equipe planeje desenvolver demandas muito grandes na mesma semana, por exemplo. Para ajudar no entendimento de tudo isso, crie uma legenda ao lado do quadro, semelhante a esta foto:

Portanto, a dinâmica de Reality Check tem o potencial de agregar valor de gestão para toda a equipe, minimizando problemas de alinhamento quanto às expectativas de entrega dentro de determinado prazo, bem como mostrando como está a realidade do desenvolvimento do projeto.

Dicas extras

Algumas práticas podem facilitar a utilização dessa dinâmica:

• O facilitador do projeto pode manter o quadro atualizado durante a semana. Depois, no início da próxima, o time poderá focar em distribuir os post-its. Para isso, sempre tenha por perto todos os utensílios necessários (adesivos, caneta de quadro, etc.);
• O facilitador precisa apoiar o time em momentos de debates quanto a prazos, pois é normal que o cliente queira a entrega dentro do prazo inicial. Logo, conversas sobre horas extras, por exemplo, podem surgir, caso a equipe não consiga encaixar todo o escopo dentro do prazo. Cabe à equipe decidir se vale a pena esse esforço adicional, pois, talvez, é melhor tentar negociar um novo prazo, ou mesmo “quebrar” partes do escopo e encaixar o que for possível dentro da data desejada;
• Evite identificar a pessoa que está desenvolvendo cada item do escopo. O Reality Check não pode se transformar em uma ferramenta de cobrança, ou mesmo que exponha algo irrelevante para o projeto/time. O quadro, o progresso e as decisões são do time, e não de atores individuais;
• Tenha outras ferramentas para a gestão do projeto. O Reality Check é um item adicional e funciona muito bem quando sincronizado com um quadro Kanban, por exemplo. Ele também poderá agregar valor quando seu projeto ainda não possuir dados históricos para a utilização de métricas, sendo uma potencial ferramenta para conceder, no início do projeto, previsibilidade sem dados;
• O Reality Check não precisa ser utilizado em todas as entregas do projeto. Talvez ele seja naturalmente demandado quando o contexto do projeto (um prazo apertado, por exemplo) justificar sua utilização, ou mesmo quando os membros da equipe encontrarem alguma motivação;
• Se você estiver trabalhando com Scrum, o Reality Check poderá ajudar o time durante a Daily. O próprio time poderá identificar essa oportunidade.

E você, gostou dessa dinâmica? Fique à vontade para comentar, feedbacks e opiniões são sempre bem-vindos!