Escrevi há algum tempo atrás um artigo sobre como organizar times de desenvolvimento de produto e algumas mudanças que fizemos nos times de desenvolvimento de software da Locaweb.

Temos nos focado bastante, desde o ano passado, em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb podem produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico abaixo mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver no gráfico, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, ou seja, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como dá para ver abaixo, mesmo com o aumento de produtividade, a quantidade rollbacks foi reduzido em 40%!

Como conseguimos isso?

Não há bala de prata, foram várias ações que tomamos e temos certeza de que ainda há mais ações que poderão ser tomadas para aumentar ainda mais. Aqui vai uma lista do que fizemos.

• Medir: antes de mais nada, para melhorar qualquer coisa é preciso medir, para poder saber se essa coisa está melhorando! Fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos então a comunicar toda a empresa sobre as entregas da semana. Cada gestor de produtos me manda na sexta-feira as entregas da semana, eu compilo os dados e anoto a quantidade de cada semana, gerando esse gráfico mais acima. A partir do momento que começamos a medir, ficou mais claro o nível em que estávamos e as ações que passamos a fazer começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, ou seja, algo na linha de “olha que interessante no seu gráfico, como vcs conseguiram aumentar esse indicador?”
• Kanban vs sprint: outro ponto que mexemos foi a mudança de Kanban para sprint. Antes, todos os times rodavam com Kanban. Só que no Kanban, quando um item tem um impedimento, ele não pode ser mexido, e o time não pode fazer mais nada, o time fica travado. Contudo, às vezes acontecia de o time, por estar impedido mover um item de “doing” para “to be done” e pegar outro item para fazer o que não deveria ser feito. Uma vez em “doing” a tarefa só pode ir para “done”, não pode voltar pra “to be done” pois perde-se o controle da produtividade. Com sprint, o time organiza as próximas duas semanas de trabalho, colocando vários itens para serem trabalhados. Assim, se algum item tiver impedimento, o time pode começar a mexer em outro item e, com isso, consegue entregar mais no mesmo intervalo de tempo.
• Discovery e delivery: o que o designer de UX e o gestor de produtos fazem pode ser chamado de discovery, ou seja, descobrir o que é preciso ser feito. Já o que engenharia faz pode ser chamado de delivery, ou seja, fazer e entregar o que tem que ser feito. Essa separação de papéis parece óbvio, mas não deixar isso explícito nos times pode atrapalhar o processo de desenvolvimento de software. Por quê? Por alguns motivos. O primeiro é que se o discovery não é visto de forma explícita, não é claro o que é feito nessa fase e nem o que motiva certas decisões sobre o que deve ser implementado no software. É díficil fazer alguma coisa sem saber porque se estáfazendo aquilo. O segundo motivo é que quando essa separação não é explícita, itens podem ir e voltar de delivery para discovery e vice-versa sem critério. Não raro a gente via nos times algo sendo implementado pelos engenheiros e UX e gestor de produtos, ao verem sua especificação implementada, desejarem mudar algo, no meio do desenvolvimento. Com a separação clara entre discovery e delivery, definimos que, uma vez indo para delivery, não se mexe mais. Se quiser mexer de novo, deve passar por novo discovery para só então ir para delivery.
• Tamanho das entregas: uma discussão que temos já há alguns meses é sobre o tamanho das entregas. Em alguns casos nossas entregas eram bem grandes, trabalho de várias semanas ou até alguns meses. Como já amplamente discutido em metodologias ágeis, a entrega frequente de software funcionando é um dos princípios de agilidade, reforçado pela técnica de entrega contínua. É só procurar no Google para encontrar inúmeros exemplos de empresas de primeira linha que fazem múltiplos deploys por dia, com algumas fazendo centenas de deploys por dia! :-O Para fazer isso, é preciso os deploys sejam de entregas pequenas, bem pequenas. É preciso dividir toda história grande em hostórias menores. Isso é trabalho deo gestor de produtos em conjunto com o designer de UX. Já me perguntaram se isso não é trapacear, afinal, ao invés de entregar uma história grande estaremos entregando a mesma coisa só que dividido em pequenas histórias. Parece ser a mesma coisa, mas ao invés de entregar algo grande depois de semanas ou até mesmo meses, a gente acaba entregando valor todo dia, e assim nosso usuário já pode usufruir dos benefícios logo, ao invés de esperar semanas ou meses. Além disso, ao colocar em produtção todos os dias, já podemos aprender com o feedback e ajustar entregas futuras. E ainda há um benefício adicional, o fato de colocar em produção todo dia algum código faz desse processo de colocar código em produção algo mais simples, exatamente pelo fato de ser feito diariamente. Então, entregar uma história grande num período de semanas ou meses não é a mesma coisa que quebrar essa história em pequenos pedaços e entregar um pedacinho todos os dias. Há ganhos claros de produtividade em se entregar pequenos pedaços com frequência.

Além desses pontos acima, estamos começando a experimentar mais alguns pontos que certamente têm impacto na produtividade:

• Primeira solução vs solução mais simples: é da natureza humana querer resolver problemas. Assim que um problema aparece, a primeira reação é pensar em uma solução e sair implementando essa solução para resolver o problema. Só que nem sempre a primeira solução é a melhor solução, tanto do ponto de vista do cliente, quanto do ponto de vista de quem implementa a solução. Por esse motivo temos preferido não começar a resolver imediatamente cada novo problema que aparece. Buscamos antes verificar se há mais soluções possíveis, analisamos todas as soluções e só aí escolhemos uma solução e partimos para a solução. Investir mais tempo pensando em outras possíveis soluções, sempre tendo claro qual a questão a ser resolvida e porque precisamos resolver essa questão. Saber o porquê ajuda a encontrar soluções simples. Uma solução simples (1 semana de implementação) que resolve 70% a 80% do problema é melhor do que uma complicada (1 mês de implementação) que resolve 100% e, na maioria das vezes, resolver 70% a 80% do problemaé mais do que suficiente. Às vezes a solução mais simples é não fazer nada!
  Exemplificando, na Locaweb o serviço de hospedagem e de email pode deixar de funcionar por um motivo externo ao serviço. O domínio ao qual a hospedagem e o email estão ligados, que é pago anualmente para o Registro.br, pode não ter sido renovado e, quando ele não é renovado, os serviços associados a esse domínio deixam de funcionar, mesmo que tudo esteja operando perfeito na Locaweb. Recentemente a Registro.br disponibilizou uma forma de a Locaweb cobrar o domínio do cliente em nome da Registro.br. A princípio a ideia parece boa, com a gente cobrando a gente garante que o cliente sabe que tem pagar esse domínio para manter os serviços no ar. Só que, analisando um pouco melhor, vimos que essa solução pode gerar mais problemas. O cliente vai receber duas cobranças pela mesma coisa, o registro de domínio, pois o Registro.br iria continuar cobrando o domínio. O que acontece se ele pagar as duas cobranças? E se ele pagar só a da Registro.br? E se ele pagar só a da Locaweb? Além disso, implementar um novo tipo de cobrança, onde iremos cobrar pelo serviços de terceiro, seria algo novo para o time e para a Locaweb. Novos processos teriam que ser desenhados. Começamos então a pensar se não existiriam formas mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar por seu registro de domínio na Registro.br. Como para poder cobrar pela Registro.br é necessário acessar a informação de que o domínio está para expirar, pensamos na seguinte solução, vamos implementar uma régua de comunicação com esse cliente avisando-o da importância de pagar o Registro.br, para garantir que o serviço continue funcionando, solução essa bem mais simples que duplicar o processo de cobrança. Se a Registro.br fornecer tb link direto para a cobran;ca do domínio, podemos mandar esse link na comunicação e as chances de resolver o problema aumentam ainda mais. E uma régua de comunicação é bem mais simples de implementar do que uma cobrança duplicada.
• Escolha da ferramenta mais apropriada: aqui o tema são ferramentas para implementação da solução, ou seja, linguagem de programação, frameworks e bancos de dados. Cada ferramenta tem suas características e essas características as fazem mais apropriadas para resolver certos tipos problemas. Escolher a ferramenta certa para cada problema vai impactar a produtividade. Esse é um tema que estamos começando a estudar agora. Hoje usamos Rails para quase tudo, mas tem alguns problemas para os quais a implementação de solução usando outro framework ou outra linguagem pode ser mais simples e rápido. Usar uma única linguagem de programação para todos os problemas é como usar uma única ferramenta para todos os consertos que tem que ser feitos. Será que o martelo é a melhor ferramenta para apertar um parafuso? Será que Rails é a melhor ferramenta para gerenciar filas?

Temos confiança de que com os dois pontos acima, que estamos começando a mexer agora, conseguiremos aumentar a produtividade por 10x ou mais! \o/

E com certeza há ainda pontos que sequer percebemos ainda e que, quando percebemos e tratarmos, podem impactar ainda mais.

Conclusão

Como disse acima que não há uma bala de prata, mas tem uma ação específica que fizemos que tem impacto crucial nesses resultados: transformamos produtividade em tema importante em nossas conversas. Todos passaram a conversar sobre produtividade, o que pode impactar e como endereçar esses pontos. Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento, coloque essa tema como tema central de suas conversas e experimente bastante. Vc verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.