Nas últimas semanas, 3 dos meus clientes pergutaram sobre como aumentar a produtividade dos times de desenvolvimento de produto. Curiosamente esse é tema do próximo capítulo do meu livro “Gestão de Produtos, como aumentar as chance de sucesso do seu software” que estou publicando aqui capítulo a capítulo.

No meu último ano na Locaweb, estávamos nos focando bastante em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb poderiam produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

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

Entregas por semana na Locaweb

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, logo, 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 é possível perceber a seguir, mesmo com o aumento de produtividade, a quantidade de rollbacks foi reduzido em 40%!

Rollbacks por semana na Locaweb

Depois que cheguei na Conta Azul, decidimos implementar o mesmo tipo de controle de entregas semanais e acabamos conseguindo também um bom aumento da produtividade.

Entregas por semana na Conta Azul

Entregas por pessoa por semana na Conta Azul

No Gympass, como estamos desenvolvendo a equipe muito rapidamente, decidimos controlar o número de entregas por pessoa por semana. Contamos as pessoas que ingressaram 2 meses antes, uma vez que as pessoas precisam de 1 a 2 meses para se tornarem produtivas. Em um trimestre, conseguimos aumentar em 16% nossa produtividade por pessoa.

Entregas por semana por pessoa na Gympass

No Gympass, também medimos o número de deploys, tanto em nosso core, conhecido como monolito, quanto em microsserviços. Também conseguimos um aumento considerável em um ano.

Entregas por mês na Gympass

Na Lopes também conseguimos um aumento considerável. Assim que um deploy era feito, um email era enviado com uma lista dos itens “deploiados”. Uma das primeiras coisas que fiz foi compilar esses relatórios em uma planilha para construir o gráfico adiante. Daí foi fácil notar que os deploys não aconteciam todos os dias. Aconteciam em média uma vez por semana. Assim que notamos isso, definimos OKRs para aumentar a frequência de deploys, o que vem surtindo efeito. Os OKRs que definimos foram:

• Objetivo: Aumentar a cadência de deploys em produção;
• KR: Aumentar o número de deploys por semana para no mínimo 3 (quanto mais melhor);
• KR: Reduzir o número máximo de novas features por deploy para no máximo 10.

Deploys por dia e quantidade de itens “deploiados”

Entre 21 de agosto e 30 de setembro tivemos 41 dias e:

• 10 dias com deploy
• 12 deploys
• 1 dia com mais de 1 deploy/dia
• 85 itens deploiados
• 41 itens novos deploiados (48%)

Entre 1º de outubro e 23 de outubro, na área marcada em verde no gráfico acima, tivemos 23 dias (pouco mais da metade do período anterior) e:

• 10 dias com deploy
• 31 deploys
• 6 dias com mais de 1 deploy/dia
• 96 itens deploiados
• 66 itens novos deploiados (69%)

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 na Locaweb para conseguir aumentar a produtividade do time de desenvolvimento de produto, práticas essas que depois levei para outras empresas.

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.

Na Locaweb e na Conta Azul, cada gestor de produtos me mandava na sexta-feira as entregas da semana, eu compilo os dados e anoto a quantidade de cada semana, gerando esse gráfico. A partir do momento em 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, isto é, algo na linha de “olha que interessante o seu gráfico, como vocês 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, ficando travado. Contudo, às vezes acontecia de o time mover um item de “doing” para “to be done”, por estar impedido, 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 para “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.

Importante reforçar que isso não é uma crítica ao Kanban. Isto acontece em 2015. Acredito que não tínhamos maturidade e conhecimento suficiente para obter o melhor do Kanban, por isso optamos por mudar para o Scrum. 

Discovery e delivery

O que a 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 a engenharia faz pode ser chamado de delivery, ou seja, fazer e entregar o que tem de 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. É difícil 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 víamos nos times algo sendo implementado pelos engenheiros. E quando o pessoal de UX e o gestor de produtos viam sua especificação implementada, desejavam 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 um novo discovery, para só então ir para delivery.

Tamanho das entregas

Em alguns casos, nossas entregas eram bem grandes, trabalho de várias semanas ou até alguns meses. Como já foi amplamente discutido em metodologias ágeis, a entrega frequente de software funcionando é um dos princípios da 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 que os deploys sejam de entregas pequenas, bem pequenas. É preciso dividir toda história grande em histórias menores. Isso é trabalho do gestor de produtos em conjunto com o designer de UX. Já me perguntaram se isso não é trapacear, afinal, em vez de entregar uma história grande, entregaremos a mesma coisa só que dividida em pequenas histórias. Parece ser a mesma coisa, mas em vez de entregar algo grande depois de semanas, ou até mesmo meses, acabamos entregando valor todo dia, e assim nosso usuário já pode usufruir dos benefícios logo em vez de esperar semanas ou meses.

Além disso, ao colocar em produçã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 em um 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 disso, ao facilitar para os engenheiros as ações de implantar (e reverter) código, isso ajudará a colocar o código na produção mais rapidamente.

Quando eu saí da Locaweb estávamos começando a experimentar mais alguns pontos que tinham bom potencial para ter 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-a para resolver o problema. Só que nem sempre a primeira solução é a melhor, 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 para 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%. 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 e- mail pode deixar de funcionar por um motivo externo ao serviço. O domínio ao qual a hospedagem e o e-mail 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 perfeitamente 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, pois ao cobrarmos, garantimos que o cliente sabe que tem de 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 receberá duas cobranças pela mesma coisa, o registro de domínio, pois o Registro.br continuaria cobrando-o. 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, na qual cobraríamos pelo serviço de terceiro, seria algo novo para o time e para a Locaweb. Novos processos teriam de 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 de 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; é uma solução bem mais simples do que duplicar o processo de cobrança. Se a Registro.br fornecer também um link direto para a cobrança do domínio, podemos mandar esse link na comunicação. Assim, 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, dependendo delas, 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 existem alguns problemas que, com a implementação de uma solução usando outro framework ou linguagem, podem ser mais simples e rápidos de se resolver. Usar uma única linguagem de programação para todos os problemas é como usar uma única ferramenta para todos os consertos que precisam 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 esses dois pontos, que estamos começando a mexer agora, conseguiremos aumentar a produtividade por 10x ou mais! E com certeza há outros pontos que sequer percebemos ainda e que, quando percebemos e tratarmos, podem impactar ainda mais.

O que impacta a produtividade

A produtividade de um time de desenvolvimento de produto é impactada por vários fatores. Certa vez encontrei um artigo bem interessante escrito pelo time de desenvolvimento da Apptio onde eles mostram um mapa mental com todos os elementos que podem impactar positiva ou negativamente a produtividade de um time de desenvolvimento de produto:

Mapa mental da Apptio sobre o que impacta a produtividade

Este diagrama mostra coisas e atividades que afetam a velocidade de desenvolvimento de alguma forma. Verde significa que uma atividade aumenta a velocidade. Quanto mais você tiver, melhor. Amarelo indica que existe algum máximo. Por exemplo, você pode acumular dívida técnica e aumentar a velocidade, mas, se acumular muito, isso o atrasará significativamente. O vermelho mostra coisas que retardam o desenvolvimento, quanto menos você tiver, melhor. A seta verde indica efeito crescente. Por exemplo, o trabalho focado aumenta a velocidade de desenvolvimento. A seta vermelha indica efeito decrescente. Por exemplo, melhores habilidades de desenvolvimento diminuem a complexidade do sistema (bons engenheiros criam sistemas menos complexos).

O que gosto dessa imagem é que ela mostra quão complexo é esse tema e quantas coisas podem impactar positiva ou negativamente a velocidade do time. Na Conta Azul acompanhávamos esse tema todo trimestre na Product Council, reunião em que conversávamos sobre o planejamento trimestral do time de desenvolvimento de produto com a liderança. Tinha um slide onde elencávamos todos os temas que podiam impactar a velocidade para discutirmos o que estávamos fazendo sobre cada um desses tópicos.

Temas que impactavam a velocidade do time de desenvolvimento de produto da Conta Azul

Coloque o tema produtividade no centro da discussão

Não há bala de prata, com cada time que trabalho foram várias ações que tomamos e sempre tivemos a certeza de que sempre há mais ações que poderão ser tomadas para aumentar a produtividade ainda mais.

A única bala de prata que existe é transformamos produtividade em tema importante de nossas conversas. Todos passaram a conversar sobre produtividade e sobre o que poderíamos fazer para melhorá-la.

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 de produtos, coloque isso como tema central de suas conversas e experimente bastante. Você verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

Outro ponto importante: não deixe para discutir o tema produtividade esporadicamente. Minha recomendação é que você o faça semanalmente. Criar uma cadência semanal dará oportunidade de, a cada semana, experimentar com algo novo e discutir os resultados com o time.

Resumindo

• Não existe bala de prata para aumentar a produtividade de um time de desenvolvimento de produto. Contudo, existem sim duas ações essenciais para ajudar nesse objetivo.
• A primeira ação é medição. Não há como melhorar algo que não se mede. O que é velocidade de desenvolvimento de produto? É importante haver uma definição clara dessa métrica e consequente mensuração.
• A segunda ação é trazer o tema produtividade para o centro da discussão. Todos do time de desenvolvimento de produto são responsáveis pela produtividade do time. Por isso, ao trazer o tema para o centro da discussão, todos poderão colaborar para melhorar a produtividade.

Treinamento e consultoria em gestão de produtos digitais

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digita) a enfrentarem seus desafios e oportunidades de produtos digitais.por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.