Métricas de Engenharia

Como nos tornamos um time de elite performance na Loft

Marcos Moraes

Published in

Loft

10 min readApr 6, 2022

Sumário

Contexto: identificando a necessidade de utilizar as métricas
Desafios que encontramos na execução
Como fiz o time enxergar as oportunidades de melhoria
As primeiras implementações
Ser ágil não é apenas implementar frameworks e métodos como Scrum e Kanban
Framework de Entrega Incremental e Constante
Conclusão

Em Outubro de 2020, eu iniciava como Engineering Manager em uma squad no contexto de reformas. O time de engenharia era e ainda é muito bom. As pessoas possuíam uma capacidade técnica acima da média além de estarem muito engajadas com o produto. À medida que fui me aprofundando no core business, planejamento estratégico e acompanhamento do time, fui percebendo que algumas de nossas entregas não estavam gerando o valor esperado aos nossos clientes finais. O time já coletava algumas métricas como cycle time & throughtput, entretanto os números não refletiam a realidade. Resumidamente, éramos muito bons em mover cards do quadro Kanban. A partir deste cenário começamos aos poucos a olhar de forma mais crítica sobre o que de fato estávamos produzindo e colocando nas mãos dos nossos usuários. O restante da história contarei nos próximos parágrafos, bem como os resultados atingidos.

Contexto: identificando a necessidade de utilizar as métricas

No final de 2019 e início de 2020 me deparei com uma proposta aqui na Loft trazida por um Diretor de Engenharia na época, hoje nosso VP, o Cirne, onde sua proposta visava a implementação de mais “Observabilidade” sobre nossos sistemas e como poderíamos ser uma empresa de ELITE. Gostei muito da iniciativa e resolvi encarar e usar meus times como “cobaia” para testarmos a nova abordagem. Na época, pouco conhecia sobre o assunto e logo procurei referências onde pude estudar mais sobre assunto e me deparei com duas leituras obrigatórias, o relatório anual State Of DevOps 2019 e o Livro Accelerate.

Resumindo, este livro é oriundo de um estudo realizado com milhares de empresas de vários segmentos e tamanhos, classificando-as entre low performers, medium performers e high performers, e traz quatro métricas relacionadas à Delivery Performance nas quais podem ser vistas na imagem abaixo:

Porém, meu objetivo aqui não é explicar em detalhes o estudo e as métricas em si (isso você encontra no relatório e também em um artigo nosso publicado no medium da Loft), mas falar um pouco sobre como aplicamos na engenharia da Loft e todos os benefícios que estamos colhendo diariamente.

Desafios que encontramos na execução

Quando assumi um time do contexto de reformas em outubro de 2020 eu já havia criado uma dinâmica em meu time anterior (2019) sobre como observar melhor o andamento de nossas aplicações. Tal dinâmica rodava muito bem e já conseguira alguns bons resultados. Um exemplo foi, a redução de nosso cycle time de 2 a 3 semanas para 4 a 5 dias, ou seja praticamente toda semana conseguíamos experimentar e coletar feedbacks rápidos. Além de maior previsibilidade e precisão em possíveis prazos dados aos clientes. Ainda, com um acompanhamento de perto sobre a saúde das nossas aplicações, permitiu que nós pudéssemos melhorar o desempenho do nosso aplicativo mobile. Mas foi nesse time de 2020 que pude perceber o efeito positivo que isso trazia ao longo prazo, dado que esse meu primeiro time acabou logo depois, visto que a Loft resolveu mudar de estratégia ao longo daquele quarter.

Logo quando entrei para liderar esse time, uma das coisas que me chamou bastante a atenção foi que o cycle time (tempo duração de uma tarefa do Doing ao Done) do time estava em torno de 4 dias. Porém, ao passar dos dias comecei a perceber que nada ia para a produção em 4 dias. Além disso, a métrica de Deploy Frequency estava bem diferente. Foi então que resolvi olhar para nosso quadro Kanban e vi que diversas tarefas que iam para o status de Done não refletiam uma entrega de valor, e não estavam em produção.

Para ilustrar melhor, tínhamos histórias que eram algo como “Criar enpoint X…” ou “Criar interface para receber endpoint X”. Ou seja, eram tarefas que iam pro status Done sem estar em produção. E o pior, não geravam valor de entrega. Claro, podemos ter discussões a respeito de incrementos de produto e essas entregas seriam uma parte do todo. Porém, nesse caso, essas tarefas sozinhas não tinham valor algum. Foi então que a partir daí comecei minha “saga” em tentar contextualizar o time sobre como estávamos numa direção na qual não tínhamos visibilidade.

Como fiz o time enxergar as oportunidades de melhoria

Mesmo com toda experiência de implementação no meu time anterior, minha abordagem inicial com o time novo não foi das melhores. Durante uma daily, trouxe ao time que nosso board estava todo errado e nossas entregas não refletiam a realidade e, ainda, não estavam entregando valor. Estávamos literalmente focados em Output e não em Outcome. E, segundo os autores do livro Accelerate, “Nossa medida deve se concentrar nos resultados e não na produção: não deve recompensar as pessoas por dedicarem grandes quantidades de trabalho que não ajuda a atingir as metas organizacionais.”

A abordagem acima é sempre lembrada pelo time e como diz uma pessoa do meu time até hoje, porém em tom de brincadeira: “Marcos chegou com os dois pés na porta falando que estava tudo errado”.

Percebendo que a estratégia de comunicação não havia sido boa, resolvi contextualizar a todos. Então, montei uma apresentação de Power Point e comecei explicando o que deveríamos fazer. E a primeira delas foi jogar nosso board inteiro fora e criar um novo. Então, comecei a recrutar um por um: Group Product Manager, Product Manager, Product Design e Time Dev. Todos sem exceção! Aos que não conheciam muito bem o conceito de agilidade, dei um Workshop de Kanban e Scrum. Dessa forma, todos ficaram na mesma página. Posso afirmar que dois dos meus principais argumentos foram: Importância da Entrega Contínua e Incremental e Vantagem Competitiva.

Quando temos uma estratégia de ciclos curtos de aprendizagem, somos capazes de nos adaptar entre momentos de alta incerteza, gerando um alto valor aos nossos clientes. Ainda, criar produtos escaláveis e de alta qualidade. Isso nos dá vantagem competitiva em relação aos nossos clientes, pois estamos rapidamente testando iniciativas, coletando feedbacks. Ou seja, ciclo de aprendizagem na veia!!!

Vale ressaltar que após a contextualização e diversos One-On-One todos aceitaram muito bem o tema e logo de cara compraram a ideia de mudança. Principalmente nosso Product Manager, que ficou muito entusiasmado com a ideia de nos tornarmos um time de Elite dentro da Loft. Posso dizer que devo muito a ele, pois graças à sua senioridade e ajuda conseguimos realizar rapidamente as mudanças. Valeu Bruno Bertozzo! 🤘

Show, agora com o board refeito, nossas tarefas indo para produção no seguinte lema: “Done é PRODUÇÃO” e, ainda, reescritas de forma que todas gerassem outcome. Dessa forma podíamos começar a ter confiança em nossos números. A partir daí começamos a implementar o que chamamos de “Weekly Metrics”

As primeiras implementações

A partir daí, começamos semanalmente a nos reunir após a daily para falar sobre a saúde de nossas aplicações. Basicamente olhamos para as seguintes métricas: Cycle Time, Throughput, Deployment Frequency, Lead time for changes, Median time to recover e Change failure rate. Abaixo, segue um exemplo das medições que monitoramos em um período de 14 dias.

Para obtermos essas medições utilizamos uma ferramenta chamada Pulse.

As métricas de Cycle Time, Throughput utilizamos uma ferramenta chamada GetNave que já possui integração com Jira.

Para que essa dinâmica funcione em todos os times de Engenharia da Loft, criei um documento onde exponho com detalhes todas as etapas para o para o funcionamento do framework Entrega Incremental e Constante.

Ser ágil não é apenas implementar frameworks e métodos Scrum e Kanban

Estou na Loft desde Agosto de 2019 e realizo entrevistas com candidatos das mais diversas senioridades. Ouço com muita frequência falarem sobre seu dia a dia de trabalho, bem como a dinâmica entre produto, clientes e engenharia. Em quase sua totalidade dos casos, existe o papel do Product Owner levando demandas para o time de engenharia.

Na minha experiência como Engineering Manager, percebo que isso não é o bastante para gerarmos o máximo de valor aos nossos clientes. Gosto da ideia de estarmos muito mais próximos do produto bem como nossos clientes. Para mim, todo desenvolvedor deve ser capaz de olhar para uma tarefa e entender para qual direção estamos indo, se estamos atuando em cima dos nossos OKRs e ainda, devem ser capazes de realizar uma apresentação sobre produto explicando nosso estado atual e onde queremos chegar como time, tribo e empresa. Isso faz total diferença na entrega do resultado final.

Na Loft usamos um conceito de EPOD (Engenharia, Produto, Operação e Design). Esse cluster de pessoas multidisciplinares trabalham juntas e com objetivos complementares. Dessa forma, conseguimos extrair o máximo de entendimento sobre o cliente e mercado.

E como funciona tudo isso?

A cada quarter definimos objetivos e todos participam desde o início da concepção, inclusive o time de desenvolvimento. Assim, é possível manter todos os envolvidos alinhados durante toda a jornada. Em seguida, Produto, Design e Time de Desenvolvimento trabalham juntos em um processo cíclico de Descoberta, Testes e Entrega como pode ser visto na imagem abaixo:

Nosso ciclo de aprendizagem começa desde a fase de descoberta até a entrega. E isso ocorre praticamente toda semana. Dessa forma, conseguimos ser ágeis pois estamos constantemente testando novas iniciativas.

O que ganhamos com isso?

Previsibilidade de entrega, aprendizado, rapidez em inovação e vantagem competitiva. Em um mercado de rápido crescimento, quanto mais ágil sua empresa conseguir entender as necessidades do seu público, melhor. Imagine um cenário onde temos uma empresa que lança seus produtos trimestralmente. A cada lançamento, ela corre o risco de estar perdendo uma grande fatia do mercado, pois alguns desses requisitos já mudaram e todo o trabalho de 3 meses pode ser jogado fora. Empresas como Amazon, Google, Facebook e Twitter realizam milhares de deploys dia. Ou seja, no caso da Amazon são 23 mil produtos sendo testados diariamente.

Segundo o livro Accelerate, “Nós estabelecemos a métrica Deployment Frequency como um proxy para o tamanho do lote, pois é fácil de medir e normalmente tem baixa variabilidade. Por ‘deploy’, queremos dizer uma implantação de software para produção ou uma loja de aplicativos.”

Uma pesquisa realizada pela Atlassian, revela que em grandes empresas descobriu que a medição do deployment frequency é o método mais comum de medição de sucesso do DevOps. 75% dos entrevistados citaram a métrica de deployment frequency como sua maior indicação de sucesso.

Meu objetivo não é explicar o que cada métrica pode fazer, mas por exemplo, monitorar a frequência de implantação em ambientes de QA e pré-produção pode ajudar a identificar questões mais amplas, como escassez de pessoal, processos ineficientes e a necessidade de mais tempo de teste.

Framework de Entrega Incremental e Constante

Como falei um pouco mais acima, criei um framework que acredito ser um guia para implementar um pouco de observabilidade em times de engenharia. Hoje o tema está em alta e deve ser tratado com extrema importância. Para ilustrar o que estou falando, imagine você indo viajar de carro com sua família ou amigos para outro estado. Agora imagine que o painel do carro (aquele que marca nível do óleo, água, gasolina e outros) pare de funcionar? Ficaria muito mais difícil a viagem, não é? Você estaria contando com a sorte. Pois é, se trazermos pro contexto de sistemas é a mesma coisa. Você está contando que suas aplicações nunca irão parar de funcionar 😬.

Outro cenário é: imagine agora uma empresa que teve um ano de vendas não muito bom e está esperando a black friday para tentar recuperar o prejuízo dos meses passados. Porém, no dia da black friday o sistema apresenta instabilidade pois a quantidade de acessos e requisições ao site estão fazendo com que a aplicação fique fora do ar durante alguns minutos e/ou horas. Isso certamente levará um prejuízo de milhares de reais e pode inclusive decretar a falência de uma empresa. Agora você entende o tamanho do problema de trabalhar no “escuro”?

Conclusão

Então, resolvi escrever esse documento para demonstrar como venho trabalhando com meus times e tentando antecipar problemas, corrigir e o mais importante, ter aplicações que garantem a melhor experiência para o cliente. Além disso, como já disse anteriormente, ser ágil significa ter vantagem competitiva para sua empresa e também gerar o máximo de valor ao mercado.

O exemplo que trouxe com o framework é apenas uma diretriz, cada time pode ter a sua forma de implementação e fazer o que for melhor em cada contexto.

Mas vocês devem estar se perguntando como está o time no qual cheguei “dos dois pés na porta?” 😂. Pois é, após 1 ano e meio aplicando o Framework, com reuniões semanais, políticas de oncall, refinamento de alerta das aplicações, entre outros, podemos afirmar que somos um time de ELITE performance. Temos um cycle time de ~4 dias, realizamos reviews na maioria das vezes semanais, o que nos permitiu ficarmos muito mais próximos dos nossos clientes. Além disso, viramos referência como squad, o que nos premiou com uma apresentação realizada pelo próprio time para toda a engenharia da Loft. Ainda, posso destacar outros resultados como um aumento na satisfação geral do time (coletamos essa métrica semanalmente), diminuição do risco de burnout e turnover. Outro resultado relevante foi nossas métricas de acompanhamento, cycle time & throughput alinhadas com as métricas de produto e negócio, o que certamente nos ajudou a batermos todos os nossos OKRs, inclusive um moonshot 🤘. Por fim e não menos importante, vale ressaltar que atingimos esses resultados porque temos um time muito F*** e de alta performance no qual eu me orgulho muito de fazer parte.

Espero que esse artigo ajude de alguma forma pois esse é um tema de extrema importância. Estou a cada dia estudando melhores formas de observação tanto nos meus times, quanto nas aplicações. Estou ansioso para saber como vocês estão fazendo nos times de vocês.

Para finalizar, se você se identifica com esse modelo de trabalho, focado em melhoria contínua, e quer se juntar ao time, confira nossas vagas abertas: loft.vc/vagas e #VemPraLoft

Grande abraço! 🤘

Links úteis