O intuito deste post é lhe fornecer um guia para ser usado quando você tiver a sensação de que seu time não está entregando. Entretanto, existem diversos cenários por trás da famosa “falta de entrega”.
Neste Artigo
Antes de sair aplicando ferramentas, métodos e frameworks da moda, você precisa descobrir qual é o cenário do seu time. Para isso, existem alguns padrões que podem lhe ajudar a fazer essa análise de forma mais sistemática
Porém, o ponto central deste texto é focar em um padrão específico: “O time que quase entrega. Existem outros padrões mas não vai ser o foco desse post.
Time que quase entrega
Nesse tipo de time, é comum diálogos como: “Só faltou aquela validação dos stakeholders para colocar em produção, vamos marcar uma reunião e vai dar tudo certo ainda hoje”.Ou então, apareceu um cenário específico de teste mas está quase pronto, coisa rápida, que resolvemos em um dia. Depois disso, passa- se mais uma semana e parece que nada andou, o item que estava na “boca do gol” continua parado no mesmo lugar pois descobrimos informações cruciais que não sabíamos antes, pode acontecer até dos testes serem tão complexos que não dá pra afirmar se dá pra terminar essa semana. Além disso, existe uma tendência nesse cenário da prioridade mudar e ser necessário deixar este item de lado para atender uma demanda urgente que acabou de surgir.
Já viveu algo parecido? Não né? Como diria Andressa Chiara: “Isso só acontece na Suíça”.
Existe um fator cultural que muito provavelmente as pessoas desse time estão se matando de trabalhar, fazendo várias demandas ao mesmo tempo, alto grau de ocupação, estresse elevado e no final a conta não fecha já que não temos entregas disponíveis para nossos clientes mesmo com todo esse esforço.
Nesse tipo de cenário é comum a falta de alinhamento entre tarefas e resultados. As pessoas estão orientadas para entregar tarefas ao invés de atingir resultados.
Existem algumas características que você deve observar no seu time para entender se ele é um “Time que quase entrega”:
Observação: Essas são algumas caraterísticas, a ideia é usar como guia dentro do que faz sentido no seu time, não leve todos os padrões ao pé da letra. Use esse documento da forma que respeite as particularidades da sua organização.
Quantidade de Entregas
A vazão do time costuma ter um comportamento de picos e vales (Imagem 1). A equipe costuma passar um longo período sem entregar nada e “magicamente” começa a disponibilizar uma grande quantidade de itens para produção, esse processo acontece repetidas vezes e você tem dificuldade em mapear o que está acontecendo.
Esse fenômeno muito provavelmente pode estar ocorrendo devido ao time estar trabalhando em uma grande quantidade de itens ao mesmo tempo. Tudo é importante e a prioridade costuma mudar constantemente, logo essa equipe fica com um custo de coordenação alto, já que todos os membros estão altamente ocupados e indisponíveis. O foco aqui é parar de começar e começar a terminar. Este video exemplifica na pratica o que pode estar acontecendo com o seu time:
Importante é saber que esse pode não ser o único ofensor, vale ficar atento:
-Existe estoque em alguma etapa do processo?
-Qual tamanho das fatias de negócio?
-Estamos mapeando os riscos antes de começar?
-Está claro o que é entrega para o time?
Para ajudar a dar foco no que é mais importante e começar de forma constante a disponibilizar entregas para o usuário, uma boa prática pode ser a redução do trabalho em andamento, assim como o vídeo mostra.
Reduzir o trabalho em andamento pode parecer contraintuitivo em um primeiro momento, como reduzir a quantidade de coisas que eu faço vai me ajudar a entregar mais?
Peço um coração aberto à experimentação. A partir do momento que você limitar a quantidade de trabalho, vai focar no que realmente importa.
Lead Time
Além da quantidade de itens entregues estar aquém, seu time demora para entregar, certo?
Você consegue responder, sem achismos, com 85% de confiança quanto tempo sua equipe demora para entregar um item caso ela comece hoje? Se você não tiver essa resposta na ponta da língua é um bom primeiro passo: Calcular o Lead Time.
Com o Lead Time em mãos você começa a sair dos achismos e entender o comportamento padrão do time baseado em evidências, habilitando por meio de métricas à visibilidade e previsibilidade.
Quando falamos de métricas, não existe fórmula mágica. Entretanto, podemos analisar os dados para tomar as melhores decisões e ajudar na evolução do time. Quero te convidar a refletir sobre alguns pontos:
-O que é um Lead Time alto? (Pensou em um número?)
-100 dias para criar algo é muito tempo? (Será que é?)
A resposta para essa pergunta é: DEPENDE!
Você pode gastar 100 dias para fazer a alteração no campo de texto em um site ou usar esse mesmo tempo para desenvolver um Boing do zero e disponibilizar para o uso da companhia aérea. No primeiro cenário 100 dias se mostra muito tempo mas no segundo é um tempo fantástico.
A principal mensagem aqui é a seguinte: não adianta comparar um número bruto de Lead Time entre contextos totalmente diferentes. Cada cenário tem suas particularidades, as quais devem ser respeitadas e principalmente, os números precisam de contexto e análise para boas tomadas de decisão.
Dito isso, para reduzir o Lead Time é necessário entender qual o comportamento das demandas que o seu time está entregando, já que existe uma percepção de alto tempo de entrega.
Uma boa forma de analisar isso é por meio de um gráfico de dispersão com o tempo de desenvolvimento individual de todas as demandas entregues durante um período de tempo:
Com base nesse exemplo, podemos obter algumas estatísticas importantes: O Lead Time esse time apresenta um Lead Time de 42 dias levando em consideração o Percentil 85 da distribuição. Em outras palavras, podemos dizer que 85% do trabalho foi realizado em 42 dias ou menos.
Uma boa forma de entender as evoluções que podem ser feitas no processo é analisar junto ao time os itens que estão destoando muito do comportamento padrão da equipe.
Existem duas ações que com toda certeza vão ajudar seu time a reduzir o tempo de entrega, sendo elas:
-Fatiar os problemas que vamos atuar.
-Entender onde estão os gargalos no processo.
Com a análise você vai conseguir identificar gargalos no processo e otimizar boas práticas que estão sendo realizadas.
Esse ofensor à eficiência acontece com frequência, porém existe solução: Fatiar o problema em que estamos atuando.
Algumas vezes queremos desenvolver a melhor solução para todos os nossos clientes e pecamos por excesso. Você concorda comigo que para criar a melhor solução, extremamente automatizada, que vai resolver todos os problemas do usuário requer muito tempo e dedicação? Para fugir dessa armadilha de desenvolvimento de produtos/serviços é necessário focar no problema e fatiá-lo. Quer entender como fazer isso? Acesse esse link
Eficácia nas entregas
“Diga-me como me medes e eu te direi como me comportarei”. Muito provavelmente você já escutou essa frase do Eliyahu M. Goldratt. O ponto importante é que métricas moldam comportamentos e grande parte das empresas estão organizadas de forma a cumprir seus objetivos estratégicos impactando positivamente a vida dos seus clientes. Até aí tudo bem, mas você deve estar se perguntando: Como isso impacta o meu “Time que não entrega”?.
O desdobramento da estratégia da companhia nos níveis táticos e consequentemente operacional é um desafio a ser superado. É comum que no dia a dia sua equipe esteja sendo cobrada por entregar ao invés de impactar métricas com as entregas. Isso é muito comum dentro de um cenário de pressão.
Muito provavelmente as demandas que o time trabalha são soluções já definidas, ao invés de hipóteses de problema que queremos impactar. Isso é um risco enorme, pois alimenta uma expectativa dos stakeholders, fazendo acreditar que ao entregar essas soluções dentro do fluxo de trabalho do time, vamos impactar os resultados e isso pode ser uma mentira.
O ponto importante de se trabalhar com hipóteses de problema, ao invés de soluções bem definidas é que desde o começo estamos assumindo que as hipóteses trabalhadas podem não resolver os problemas dos nossos clientes.
O “Time que quase entrega” conhece o mercado que está inserido, as personas do seu produto e as principais tendências de mercado. Entretanto, desconsidera as incertezas no seu processo de desenvolvimento. Tratar a solução definida como resolução de todos os problemas pode ser um equívoco, ainda mais se não estiver claro qual problema você quer resolver, as métricas impactadas e o tempo esperado para comprovar suas hipóteses.
Para resolver o Problema da Eficácia é necessário fazer 2 intervenções iniciais: Atuar no começo(Upstream) e no final (Downstream) do seu fluxo.
Esse artigo pode te auxiliar a observar seu fluxo como um todo
A intervenção no Upstream vai auxiliar na entrada dos itens, a forma como as demandas chegam vão moldar o comportamento de toda a equipe. É importante estar atento se estamos construindo soluções ou hipóteses de problema que vão impactar as métricas estratégicas.
Uma ferramenta que pode te ajudar é o Test Card, Ela foi criada pela Strategyzer para auxiliar no pensamento baseado em hipóteses de problema, esse vídeo exemplifica como utilizar o Test Card no seu “Time que quase entrega”.
Outra ação importante é deixar explícito nas histórias de usuário dentro do seu backlog os seguintes pontos:
- Qual problema você quer resolver?
- De quem é esse problema?
- Quais métricas justificam que esse problema existe?
- Quais métricas estratégicas vamos impactar na organização?
- Como vamos comprovar que resolvemos o problema?
O foco no Downstream será criar formas de comprovar que a hipótese trabalhada pelo time gerou ou não impacto. Saber que a hipótese não gerou resultados é extremamente positivo, nos tira da ignorância e elimina uma ação que não precisamos fazer mais, gerando aprendizado para o time e a organização.
Realizando um bom trabalho no Upstream, deixando explícito o problema, as métricas impactadas e a forma de validar que alcançamos ou não nosso objetivo, será mais fácil colher os resultados das demandas desenvolvidas pelo seu time.
O principal ponto de atenção aqui é: Medir se sua hipótese foi validada ou não!
Existem algumas técnicas que podemos aplicar durante esse processo:
- Teste A/B ;
- Fake Interface;
- Entrevista com cliente após disponibilizar o item;
- Deixar o item com os usuários e medir o comportamento das métricas durante um período de tempo
Esses são alguns exemplos, existem outras inúmeras formas de fazer esse processo de validação no downstream, o importante é fazer”
Vale ressaltar que esse é um guia com boas práticas, cada cenário tem suas particularidades e algumas das propostas podem não se aplicar ao seu time.Importante é entender quais boas práticas você consegue extrair daqui e ter resultados dentro do time time, fazendo com que ele deixe de ser um “Time que quase entrega” e passando a ser uma Equipe de Alta Performance.