Na Guiando, buscamos entregar o melhor software no melhor tempo, com o melhor custo. Nos preocupamos em melhorar nossos processos de desenvolvimento, testes e liberação. Entretanto, infelizmente, como qualquer empresa, ainda entregamos software com bugs (cada vez menos, felizmente).
Houve um tempo em que acreditávamos que a melhor alternativa para minimizar impacto de nossos erros em nossos clientes era manter um time dedicado para correção de bugs. Não acreditamos mais nisso!
NOTA DO ELEMAR: Este é um post do Fernando Paiva. Eu, Elemar, sou apenas o editor.
Como era nosso time de “Sustentação” (On-going)
Tínhamos um time dedicado para corrigir bugs e realizar ações preventivas (aham!?).
Inicialmente, entendíamos que ter pessoas focadas em resolver problemas, no menor tempo possível, da melhor maneira possível, causava impacto positivo no negócio. Tínhamos mais agilidade na trataiva de incidentes.
Gostamos tanto da ideia que modelamos bem os processos desse time. Ousados, estipulamos SLAs. Além disso, passamos a monitorar indicadores de qualidade de atendimento e conquistamos a credibilidade de que os problemas demandados eram de fato resolvidos. (Um assunto a ser abordado com mais detalhes em um próximo post)
Restava apenas uma dor: Corrigíamos bugs rapidamente. Entretanto, a frequência com que novos bugs surgiam não diminuía. Tínhamos um “custo fixo” (alto) em função dos bugs. Entendíamos como algo natural. Para piorar, nosso time de “sustentação” tinha conflitos sérios com o pessoal de desenvolvimento. A impressão era de que muitos bugs ocorriam por “descuido”.
Quando o evidente fica ainda mais evidente
Foi então que percebemos algo que hoje parece óbvio. Não dá para despoluir um rio apenas limpando. Temos que parar de poluí-lo!
Quando separamos o time de sustentação do time de desenvolvimento, estávamos separando também quem “polui” de quem sofre as “consequências da poluição”. Constatamos que, por mais que as pessoas se sensibilizem com o fato de estarem entregando software com bugs, nada é mais efetivo do que sentir a “dor” de ter seu resultado afetado devido a entregas de baixa qualidade (São as ditas “cicatrizes”, que o Elemar tanto menciona).
O que estamos fazendo hoje
Percebido o problema, resolvemos fazer uma reorganização dos nossos times buscando competências multidisciplinares. Agora, cada time é completamente responsável por uma parte do produto (incluímos nos times, inclusive, pessoal de negócio).
Nos inspiramos fortemente em muitos dos processos antigos. Continuamos, também, observando as mesmas métricas e indicadores. Entretanto, mudaram os atores! Também mudaram nossos instrumentos de acompanhamento (veja a série “Kanban no mundo real” para entender melhor do que estou falando).
Cenas dos próximos capítulos
Ainda temos muito a melhorar, qualidade é algo a ser perseguido de maneira constante. Mas, essa mudança fez com que os problemas passassem a ser resolvidos na raiz e bugs recorrentes não retornassem. Ainda estamos sofrendo com o peso do legado – mas estamos percebendo que estamos melhores a cada dia.
O fim do time de sustentação aumentou o interesse pela escrita de testes automatizados (Elemar avisou que isso aconteceria). Estamos avançando muito nesse aspecto e acreditamos que vamos alcançar um nível muito bom em bem pouco tempo.
Na Guiando, [tweet]começamos a REALMENTE eliminar bugs no momento em que deixamos de ter um time dedicado a eliminação de bugs[/tweet].
Como funciona na sua empresa?
Uma resposta
O processo de unificação de frentes de sustentação e projeto no meu entendimento é factível mas muitas vezes uma mudança de paradigma nas métricas que compõem os indicadores de entrega dos times é necessária.
Se eu cobro quantidade e não qualidade inevitavelmente vai haver problemas…
Agora se eu mantenho uma gestão sobre o impacto das novas funcionalidades na operação consigo mensurar melhor e é possível endereçar aos donos as correções.
Tendo uma equipe com foco na qualidade o problema das entregas e handover para suporte diminui, outro ponto interessante de se abordar é a equipe desenvolvedora ser responsável pelo que cria para sempre. Assim não ficam rabos, e débitos técnicos se a equipe quer evoluir o produto.
Se vc gera o monstrinho, vc cuida, simples assim…