Um dos grandes desafios na substituição da cultura de projeto para uma cultura de produto está no paradigma de buscar segurança e previsibilidade através do escopo: determina-se na largada um escopo do que será desenvolvido, e com base nisso, cria-se uma estimativa e um cronograma (e um custo pré-fixado) que num primeiro momento cria uma áurea de segurança para os stakeholders.
Independentemente da técnica de estimativa de esforço para execução e desenvolvimento da iniciativa, há fatores fundamentais que nenhuma estimativa é capaz de prever — e dentre as principais, destacam-se:
O fator humano
Como fator humano, considera-se questões como nível de engajamento e maturidade do time de desenvolvimento (sinergia entre os membros) e a curva de aprendizado do mesmo sobre o produto que será desenvolvido.
O fator processo
Toda jornada, apoiada num processo de inspeção e adaptação para melhoria contínua torna a performance como algo crescente — ou seja, a performance de entrega varia ao longo da jornada. Um bom processo, além de otimizar cadência de entrega, pode mitigar riscos de impedimentos, ainda que alguns possam não ser tão previsíveis.
O fator técnico
Assim como a própria curva de aprendizado sobre o produto em si que é alvo de desenvolvimento, no geral, cada membro do time se aprimora tecnicamente com as tecnologias e ferramentas que compõem a jornada de desenvolvimento à medida em que a percorre, de forma que a performance de desenvolvimento também varia ao longo da jornada. Algumas questões técnicas também podem ser imprevisíveis na largada — como uma estratégia de integração ou alguma decisão tecnológica que será exercitada ao longo da jornada.
O fator descoberta
Ignorar todos os insights e aprendizado decorrentes da jornada de desenvolvimento traz um risco extremamente alto para o investimento: sucesso é cumprir prazo e entregar o escopo, ou desenvolver um produto bem sucedido? Este fator talvez seja o mais importante no que se refere à projetização do desenvolvimento de iniciativas — já que se assume que o desenho de escopo realizado na largada e todas as suas hipóteses são verdadeiras (um verdadeiro ato de fé) — e basta que um time de desenvolvimento o materialize.
Outro fator que não pode ser ignorado é o desperdício no desenvolvimento de funcionalidades que podem ser pouca ou nunca utilizadas — isso é muito comum na abordagem de tentar identificar e definir todo o escopo na largada.
Uma jornada de descoberta foca em criar uma estratégia de desenvolvimento incremental, que se valide rapidamente cada hipótese de sucesso do produto, entregando o máximo de valor aos usuários e com o apoio de métricas de produto (aprendizado validado), direcionar o desenvolvimento das próximas releases.
Considerando os fatores acima, e ainda, que o escopo deixa de ser fixo e passa a ser uma variável — de que forma trazer segurança para os stakeholders?
Criando o cenário da previsibilidade
A primeira questão importante sobre previsibilidade é que ela deve ser capaz de compreender o momento ou estágio atual — sabemos que os fatores humano, processo, técnico e descoberta geram condições variantes de performance ao longo da jornada — e dessa forma, com o uso de algumas técnicas e métricas, é possível englobar esses fatores — e serão apresentados ainda neste artigo.
A segunda questão é considerar o desenvolvimento como uma grande jornada de descoberta, ou seja, escopo como variável, e não uma constante — de forma que a discussão sobre o que se pensa inicialmente sobre o todo da iniciativa exige uma nova tratativa com os stakeholders em fracionar esse todo em pequenos pacotes — idealmente orquestrados no conceito de MVP (Minimum Viable Product, ou Produto Mínimo Viável). O MVP em linhas gerais trata de uma estratégia de priorizar o desenvolvimento de produto de forma a validar o máximo de hipóteses e entregar valor no menor tempo, e não simplesmente em cumprir o desenvolvimento de uma lista de requisitos — e o mais importante, o time/squad se conecta profundamente ao propósito da iniciativa e contribui ativamente no desenho dos incrementos do produto, potencializando a jornada de descoberta.
A consciência dos fatores acima é fundamental para embasar e potencializar os ganhos que uma esteira de entrega é capaz de performar, tanto em eficiência (fazer bem) quanto eficácia (fazer o que precisa ser feito).
Uma organização capaz de compreender os ganhos no médio e longo prazo dessa abordagem otimizará enormemente o investimento em suas iniciativas — e principalmente, terá mais agilidade em responder ao que acontece no mercado (cada vez mais dinâmico).
A esteira de entregas: primeiros passos
O conceito de esteira de entregas é consequência de uma séria de disciplinas e metodologias interligadas de forma sinérgica — e cada uma delas é um universo de conhecimento e experiências que devem ser pesquisadas e aprofundadas — em linhas gerais, serão ilustrados alguns pontos básicos e um roteiro inicial na utilização de algumas métricas que ilustram o conceito da previsibilidade — o suficiente para dar a largada.
Pré-requisitos:
- Time/Squad multidisciplinar (time de desenvolvimento + Gestor do Produto) dedicado à iniciativa e com todas as skills necessárias para desenvolver e sustentar o produto (a partir do primeiro release lançado, haverá demanda de sustentação em paralelo ao desenvolvimento — e é importante que se tenha um único time responsável).
- Clareza sobre os objetivos do produto e os resultados esperados para o negócio.
- Autonomia do time/squad em propor soluções com base nos desafios e metas.
- Proficiência em cultura e metodologias ágeis.
- Um quadro kanban.
Alguns diferenciais importantes:
- Clima e cultura organizacional propícias ao alto engajamento e alto nível de felicidade das pessoas, para que se experimente o mínimo de rotatividade dos membros do time/squad.
- Ferramental de apoio na gestão de atividades e obtenção das métricas.
Como ponto de partida, o primeiro exercício do time/squad é identificar o ciclo de vida em que cada atividade passa desde a sua ideação até a sua efetiva publicação em produção, de maneira a reproduzir esse ciclo de etapas em um quadro kanban:
Exemplo de um quadro kanban na ferramenta Trello.
Quadro kanban na ferramenta Jira.
É importante que os critérios de passagem de cada tarefa de uma etapa à outra sejam bem claros para todo o time.
Uma vez que o time/squad passa a movimentar suas tarefas no quadro kanban, algumas informações e contabilizações podem ser extraídas viabilizando a geração de alguns indicadores que serão essenciais no entendimento e melhoria da fluidez do processo.
As métricas ágeis apoiando na previsibilidade: começando pelo CFD
O primeiro exercício de análise decorrente do uso do Kanban é identificar e avaliar pontos de gargalos do processo — em alguns casos há uma percepção intuitiva do time, porém, em estágios avançados da melhoria contínua, somente com métricas será possível refletir e aprimorar este processo. O primeiro indicador para este tipo de análise é o CFD (Cumulative Flow Diagram). Você pode produzi-lo através de uma ferramenta como Excel, ou em alguns casos, como o sofware Jira, ele pode ser extraído automaticamente.
CFD (Cumulative Flow Diagram): identificação de gargalos.
Como ele funciona? Em uma linha do tempo, ele contabiliza a quantidade de tarefas empilhadas (como uma fotografia) em cada uma das etapas previamente definidas — e de forma acumulativa, vai somando as fotografias dos períodos seguintes, permitindo visualizar tendências de aumento ou encurtamento da quantidade de tarefas engarrafadas ou empilhadas em cada uma das etapas ou ciclo de vida das atividades, e dessa forma, identificar potenciais gargalos no processo.
Um exemplo típico para ilustrar esse tipo de leitura, seria identificar um aumento significativo na raia amarela, que no nosso diagrama, representa as atividades que estão em testes. A interpretação mais natural neste caso seria a de que há um gargalo neste tipo de atividade, o que eventualmente traria algumas ações que o time poderia tomar, como engajar outros membros nesta atividade (porque de nada adiantaria desenvolver mais tarefas, já que todas ficariam represadas), automatizar fluxos críticos de testes para diminuir dependência dessa atividade, ou ainda reequilibrar a composição do time, aumentando a força desse tipo de atividade. O importante é gerar a reflexão contínua do time e estar sempre buscando a manutenção da cadência de entregas.
Um outro cenário típico é o acúmulo de tarefas prontas para produção, que geralmente denota casos em que há uma burocracia ou dificuldade na realização da publicação em produção — o que direcionaria esforços do time em melhorar o processo de publicação, automatizando testes, procedimentos de deploy, etc.
Para potencializar a resolução de gargalos, existe uma técnica conhecida como limitar o WIP (Work in Progress), que significa que há um determinado número limite de tarefas que podem ser empilhadas em determinada etapa, de forma que todo o time deverá redirecionar seus esforços em resolver essas tarefas antes de assumir qualquer outra do quadro.
Ampliando a análise: Leadtime e Throughput
Com a busca incessante por gargalos (na prática você resolve um gargalo para descobrir o próximo), o time está sempre refletindo sobre o que pode ser melhorado em termos de fluidez do processo de trabalho. Para complementar a análise, um segundo gráfico bastante interessante é o que ilustra o leadtime — que é o tempo em que uma tarefa leva para percorrer todo o ciclo de vida representando pelo kanban — e sobre ele, extrair mais algumas informações que podem auxiliar na melhoria do processo.
Gráfico: análise de leadtime.
Complementar a análise do CFD, a visualização dos extremos do leadtime (mínimo e máximo de tempo que uma tarefa levou para percorrer todo o ciclo do quadro) permite identificar variabilidades do processo — a ocorrência de tarefas que ficam muito tempo bloqueadas, e que diferem bastante da média do leadtime, indica cenários de impedimento geralmente externos ao processo ou esfera de atuação da equipe, e que exigem algum tipo de atuação mais abrangente. Em outros casos, significa que uma tarefa pode ter sido subestimada em tamanho, ou passou por um longo ciclo de definições e redefinições. Quando se busca previsibilidade, deve-se atuar para minimizar variabilidades — e quanto mais próximo os extremos mínimos e máximos estiverem da média, e esta média for constante na linha do tempo, significa que está se criando um cenário de estabilidade e cadência.
Gráfico de Throughput: quantidade de tarefas entregues por período.
O Throughput representa a quantidade de tarefas que foram publicadas em produção, em intervalos regulares de tempo. Em uma leitura simples, a medida que o time se estabiliza, a variabilidade de publicação de tarefas em produção tende a se estabilizar também. Com inspeção e adaptação, a medida que o processo de trabalho do time vai se tornando coeso — com gargalos sendo identificados e tratados — as tarefas vão avançar nas etapas do ciclo de vida com uma natural estabilização que irá refletir na cadência de entregas.
A essa estabilização do Throughput é que se chega no conceito de esteira de entrega — é possível ter um sistema previsível, que engloba todas as variáveis envolvidas (fatores humano, processo, técnico e descoberta), em que uma tarefa designada para percorrer todas as etapas do ciclo de vida tem uma alta probabilidade de ser publicada em produção ilustrada pela visão de Throughtput. Dessa forma, o Gestor do Produto é capaz de ensaiar priorização de tarefas e ter um alto grau de previsibilidade de quando essas tarefas seriam concluídas.
Estatisticamente, é possível expandir a visão do Throughput de ‘prever o futuro’ através dos cálculos de moda, média artimética, mediana e/ou percentil. O importante é identificar a situação em que cada uma delas se torna mais adequada. É válido destacar também que amostragens maiores costumam trazer maior assertividade.
Moda
No cálculo da moda, deve-se considerar o maior número de ocorrências da quantidade de tarefas entregues em cada período — o que no exemplo acima, seria 4 — ou seja, na maior parte dos períodos analisados, a quantidade entregue foi 4.
Média Aritmética
Soma a quantidade de tarefas entregues, e divide pela quantidade de períodos observados. No nosso exemplo, são 28 tarefas entregues durante 7 ciclos, e a média simples é de 4 tarefas entregues por periodo. Esta análise é prejudicada quando há uma ou mais variabilidades extremas (para mais ou para menos), que impactam diretamente na média geral.
Mediana
Em um cenário em que há algum extremo na amostragem (algum cenário atípico de alto ou baixo volume de entrega) poderá distorcer a média aritmética simples. A mediana é menos vulnerável porque considera exatamente o meio entre a metade maior e a metade menor de uma amostragem (quando a quantidade de itens da amostragem for ímpar, faz-se uma média entre os dois valores do meio), ou seja, é o valor do ‘meio’ da amostragem. No nosso exemplo: {1, 2, 4, 4, 4, 6, 7} a mediana é 4.
Percentil
O modelo de cálculo do percentil consiste em fracionar a amostragem (que é 100%) em quartis (25%). O cálculo em si pode ser realizado através da função nativa do Excel ou software similar — e o conceito deste cálculo trata de identificar a média da quantidade de entregas considerando 75%, 50% e 25% do período — o que é extremamente útil para o provisionamento e ensaio dos cenários futuros de entrega do time, de forma complementar as outras visões.
Nossa leitura para este caso:
- Em 75% dos períodos, nosso time entregou 3 tarefas;
- Em 50% dos períodos, nosso time entregou 4 tarefas;
- Em 25% dos períodos, nosso time entregou 5 tarefas.
Análises complementares
Embora a eficiência de processo não esteja atrelado ao tamanho da história ou tarefa, é muito importante que cada uma delas não seja maior que um ciclo padrão de trabalho determinado pelo time/squad, e que na medida do possível, sempre se busque equalizar o tamanho das mesmas, no sentido de facilitar a leitura da eficiência do processo. É natural que isso comece a ocorrer à medida que o próprio time evolui junto com o Gestor do Produto na gestão do backlog e na quebra dos épicos em histórias.
O método conhecido como T-Shirt Size é uma forma simples de classificação de cada tarefa ou história com base nos critérios P, M, G (em alguns casos com alguma granularidade maior, como PP e GG). A ideia é que o exercício seja simples, votado pelo time e na busca do consenso ou maioria de votos.
Medir a proporção do tamanho T-Shirt das histórias ou tarefas entregues em produção pode ajudar na busca pela uniformização.
A classificação T-Shirt Size pode auxiliar na busca pela padronização do tamanho das tarefas.
E por fim, um exercício extremamente importante, principalmente quando uma primeira release do produto é publicada em produção, é avaliar as demandas sob a ótica da Classe de Serviço.
Classe de serviço é uma classificação das tarefas tendo por base um critério de preferência previamente acordado, e uma vez que esta tarefa esteja dentro da esteira, ela terá preferência de execução, eventualmente quebrando o padrão natural FIFO (first in / first out), ou seja, classe de serviço trata da preferência de execução e é diferente de priorização (ato de escolher o que entra no processo). Complementarmente, também é possível acomodar a sua natureza ou tipo de tarefa— como por exemplo, identificar cada tarefa ou história como Nova Funcionalidade (estou entregando valor para o usuário final), Bug / Correção (de baixo ou alto impacto para o usuário final) ou Débito Técnico (melhoria técnica, que na grande maioria das vezes não é perceptível para o usuário final).
Tendo essa contabilização a cada ciclo de trabalho, é possível avaliar, refletir e equilibrar a dose de cada tipo de tarefa que entra na priorização do time de desenvolvimento — e isso é extremamente importante para a missão primordial da cadência de entrega de valor — investir longos períodos de tempo atuando fortemente em débitos técnicos certamente irá gerar uma experiência ruim para os usuários finais ou stakeholders, que não terão percepção de trabalho e entrega do time — e essa é uma armadilha muito comum de ocorrer, quando o time fica com a sensação de bastante trabalho, mas isso não reverbera para os stakeholders.
Visualização da proporção de tarefas entregues em um período por Tipo.
Concluindo
Se você chegou até aqui, deve ter percebido que uma nova abordagem totalmente diferente da tradicional (uso de estimativas) pode ser totalmente substituída com técnicas que trazem muito mais previsibilidade e principalmente, criam a disciplina de melhoria contínua na eficiência do processo de um time/squad de desenvolvimento de produto. E fica difícil imaginar uma jornada sem essas medições — tornando totalmente questionável a afirmação de que é possível obter resultados consistentes de melhoria contínua com inspeção e adaptação sem o uso de métricas.
Há várias outras técnicas e métricas de eficiência não mencionadas neste texto que deixam o exercício ainda mais arrojado, e adicionalmente, há as métricas de eficácia e de produto, que são a faceta complementar e igualmente importante para uma boa performance de entrega — e que serão exploradas em outros artigos.
Se esse tema é do seu interesse, sugerimos também: e-Book “Squad Health Check na prática” e-Book “People Everywhere Innovating Everything” e-Book “Distributed, Remote Work, connected by real collaboration and data” e-Book “What makes game-changers love our Global Growth Framework – increasing and accelerating innovation missions”
Vamos falar sobre seus desafios específicos?
