Tangibilizando os resultados

O Problema

Uma das responsabilidades do nosso time de desenvolvimento é a sustentação a diversos sistemas. Entre as atividades de sustentação estão correção de defeitos, tirar dúvidas de usuários que os dois níveis anteriores de suporte não resolveram, extração de dados de produção para os quais não há relatório nos sistemas, entre outros. 

Então, no início de março de 2015, o estoque de chamados não resolvidos chegou a cerca de 200, sendo que alguns deles já estavam fazendo aniversário.

A estratégia

Recentemente fiz o curso Software Zen com o Alisson Vale e uma das estratégias que ele ensina é "Tangibilizar os resultados". Geralmente, no desenvolvimento de software, os produtos e as métricas são intangíveis, ficam escondidas dentro de computadores e sistemas. Os objetivos desta estratégia incluem:

1. Criar informação para suportar a tomada de decisão;
2. Gerar confiança em todas as interações do sistema; e
3. Motivar as pessoas.

Então, no início de março, incluímos um gráfico de chamados não resolvidos abaixo do quadro kanban, como mostrado na Figura 1.

Figura 1 - Quadro kanban

Este gráfico é atualizado diariamente e foi feito da forma mais simples possível: uma papel A3, caneta esferográfica e canetinha vermelha e preta, como mostrado na Figura 2. A propósito, a linha vermelha no gráfico é a fila de chamados não resolvidos e a linha verde, incluída após uma reunião de retrospectiva, evidencia o número de defeitos não resolvidos.

Figura 2 - Chamados não resolvidos

Este gráfico evidencia para este time se o objetivo de reduzir os chamados não resolvidos está sendo atingido ou não. Ao mesmo tempo, o gráfico é um motivador para a equipe quando mostra o quanto o time já avançou para atingir este objetivo.

Conclusão

Antes de tudo, a diminuição no número de chamados não resolvidos, como mostrado no gráfico, não se deveu somente a esta estratégia. A queda já era esperada, já que janeiro e fevereiro tinham sido meses atípicos, onde houve uma acumulação de cerca de 100 chamados. Entretanto, alguns fatos nos levam a crer que a estratégia de tangibilizar os resultados teve um impacto e que a queda talvez fosse menor sem ela.

Primeiro, o gráfico deixou evidente qual deveria ser a preocupação da equipe a todo momento. Antes dele, estes dados ficavam guardados dentro de um sistema que nem todos do time acessavam constantemente. Agora, mesmo sem querer, todos vêem o s números. Em diversos momentos, quando o número não diminuiu de um dia para outro, ouvia-se de alguém do time: "Pô, não diminuiu!" ou "Aumentou!";

Segundo, houve um esforço para procurar chamados que não precisavam mais ser feitos e fecha-los. Alguns deles deixaram de fazer sentido porque se referiam a partes dos sistemas que já tinham sido desligados, outros porque um outro chamado já tinha resolvido o problema.

Por fim, nos últimos dias, quando a linha vermelha diminuiu a velocidade de queda e até tendendo para a estabilização, pudemos cruzar os dados com as férias de 3 integrantes deste time, o que já nos deu uma hipótese sobre a diminuição do ritmo e, consequentemente, reduziu a ansiedade dos gestores para tomar alguma medida imediata, já que 2 destes integrantes já estavam por voltar das férias.

Os efeitos da redução do WIP

Introdução

A Figura 1 é uma fotografia do quadro kanban do desenvolvimento de software judicial no TST de dezembro de 2014. Cada post-it é um defeito ou uma história de usuário. Os post-its verdes são quase todos de correção de defeitos. Cada uma das outras cores representam um projeto diferente.

Esta figura mostra dois problemas principais: muito trabalho em progresso (WIP) e lotes grandes. Muito trabalho em progresso é um problema pois dificulta a coordenação dos trabalhos e é uma grande fonte de interrupções nas demandas que ainda estão em desenvolvimento. O que faz com que estas últimas demorem mais para serem terminadas. Lotes grandes, como o ilustrado pelo círculo na Figura 1, são um problema quando entram em produção. Normalmente, uma entrega grande em produção é seguida de uma sequência de defeitos reportados.

Figura 1 - kanban de dezembro de 2014

O que fizemos?

Então, a partir do início do ano, mas com mais intensidade a partir de fevereiro, começamos a tomar ações para reduzir o WIP do sistema de trabalho. Abaixo listo uma sequência de ações executadas e fatos que se sucederam:

1. O projeto em azul (Figura 1) foi implantado no início janeiro;
2. Os limites de WIP foram retirados do quadro kanban. Isto parece contraditório, mas pela Figura 1 podemos ver que os limites, mesmo altos, não eram respeitados pela equipe. Então retiramos os limites, para recolocá-los quando o WIP já estivesse mais baixo.
3. Em fevereiro começaram a aparecer os defeitos da implantação do projeto em azul. A equipe de desenvolvimento trabalhou quase que exclusivamente todo o mês para corrigi-los de forma imediata.
4. Para favorecer a correção destes defeitos e não permitir o aumento do WIP, não foi priorizado nenhum item que não fosse imediato até o início de março (círculo na Figura 2);
5. Com o WIP mais baixo, no início de março foram recolocados os limites de WIP. Por exemplo, o limite do desenvolvimento que antes estava em 28 itens passou para 6, o limite do teste e homologação que antes era 30 passou para 6.
6. Então, no final de março, com os limites já sendo respeitados voltamos a priorizar itens não emergenciais para serem desenvolvidos.

Figura 2 - kanban do início de março de 2015

E onde isto nos levou?

O Lead Time, que é o tempo desde que uma história de usuário entrou em desenvolvimento até o momento em que ela foi colocada em produção, tem caído para a maior parte destas histórias. A Tabela 1 mostra a média e a mediana para quatro períodos. Apesar da média não ter caído tanto, pois algumas histórias antigas ainda puxam a média para cima, a mediana mostra que para 50% das histórias a tendência é de queda no tempo de entrada em produção. 

Tabela 1 - Lead Time

A taxa de entrega mensal (throughput) de março só não foi superior aos meses de agosto de 2014 e de janeiro de 2015, considerando os últimos 12 meses (Gráfico 1). Por outro lado, nestes dois meses existiram entregas grandes em produção que haviam ficado acumuladas, como aquela da Figura 1. Assim, isto nos indica que esta taxa de entrega mais alta veio das ações descritas anteriormente.

Gráfico 1 - Taxa de entrega mensal

Conclusão

A redução do WIP teve impacto não só na redução do Lead Time e no aumento da taxa de entrega (que ainda precisamos confirmar se irá se manter nos próximos meses), mas também facilitou a coordenação do trabalho da equipe no dia a dia.