Medir a produtividade em equipes de software vai além de olhar apenas o volume de código produzido: você precisa do Coeficiente de Produtividade

Por Alberto Silveira*

Medir a produtividade das equipes de software é uma tarefa complexa. Para começar, a produtividade em si pode ser um tópico subjetivo. Mesmo quando parâmetros de referência e métricas são estabelecidos, a forma como um engenheiro de software percebe a produtividade será, muito provavelmente, diferente do que a percebida por um executivo ou membro do conselho. As pessoas têm pontos de vista diferentes e o significado dado à produtividade depende da interpretação e perspectiva de cada pessoa.

A produtividade no desenvolvimento de software não é exceção. Há muito mais do que simplesmente o volume de código escrito e se está realmente bug-free (livre de erros).

Métricas como Deployment Frequency (frequência de distribuição), Cycle Time (tempo de produção), Pull Request Throughput (alteração de código), Code Activity (atividade no código) e Lead Time (tempo para chegar ao usuário) ajudam a trazer alguma perspectiva, mas existem muito mais coisas que precisam ser feitas que permanecem invisíveis.

Todo trabalho é valioso: há muito trabalho que precisa acontecer nos bastidores para que um restaurante tenha sucesso; o mesmo se aplica ao desenvolvimento de software.

Esse trabalho invisível aumenta a falha de comunicação entre o mundo oculto e quase abstrato da codificação, de um lado, e, do outro, das partes interessadas de negócio: investidores, executivos e outras partes interessadas no crescimento do negócio. É uma lacuna que pode causar frustração e mal-entendidos que podem levar à rotatividade de colaboradores e desaceleração do crescimento dos negócios. É responsabilidade da liderança fechar essa lacuna.

Como aprendi com meu amigo Peter Bell, fundador e CTO da CTO Connection, existem duas classes de métricas: eficiência e eficácia. A eficiência garante que você está construindo as coisas corretamente. Eficácia significa que você está construindo as coisas certas. As métricas de produtividade se encaixam no guarda-chuva da eficiência e, na maioria das vezes, isso gera uma obsessão em medir apenas as atividades relacionadas ao código.

A eficácia está mais relacionada às métricas de negócios e, geralmente, está alinhada com os objetivos de um trimestre fiscal, especialmente, se a empresa utilizar a metodologia de objetivos e resultados-chave (em inglês, Objectives and Key Results, OKR).

Então, como as equipes de alto desempenho medem a eficácia?

Este artigo usa uma simples metáfora de restaurante para ajudar os leitores a entender que, ao construir software, cada unidade de trabalho é importante e essencial.

Assim, explica por que as métricas de produtividade de software devem ser vistas de maneira mais ampla para que se possa contar uma história mais completa e mais precisa.

Esse entendimento deve ajudar a fechar a lacuna entre as equipes de software e as partes interessadas, validando que a produtividade e o verdadeiro valor entregues vão além de olhar ou analisar “apenas o código”. Aprofundando a analogia com o restaurante, optei por ilustrar essas métricas usando a iguaria gastronômica carpaccio.

Da mesma forma que as metáforas do cupcake e do patinete, a arte de fatiar o carpaccio compartilha a mesma ideia de agregar valor de forma incremental.

Usar metáforas é bem convencional na indústria de software. Já vi metáforas de cupcake, bolo de aniversário e bolo de casamento usadas na área de design thinking e, para a construção de um Produto Mínimo Viável (MVP) bem-sucedido, o autor Henrik Kniberg explica em detalhes como construir um produto em interações usando um patinete, depois uma bicicleta, depois uma motocicleta e, por último, um carro. Então, nesse sentido, o carpaccio se encaixa perfeitamente de um modo simples e fácil para as pessoas de qualquer nível de experiência se conectarem com esse novo conceito de medir produtividade de uma forma mais coesa.

Gosto de me referir às “fatias verticais”, onde cada fatia deve ser “deliciosa”. A ideia é que você agregue valor com cada pedaço entregue. Gosto, também, de ir além do carpaccio apenas como alimento. Existe todo o contexto sobre o restaurante e como é servido. No fim das contas, é fundamental que o restaurante seja um negócio rentável e sustentável – é o que todo investidor almeja, independentemente do tipo de negócio.

Isso significa que o restaurante deve atrair clientes que ficarão felizes em pagar por sua refeição e que retornarão com uma certa regularidade. Para que isso aconteça, existe muito trabalho que precisa acontecer atrás dos bastidores, que vão muito além de deliciosos pratos sendo servidos.

Seguindo essa ideia da vida real, usarei essa analogia de preparar e servir o carpaccio em um restaurante para explicar como o conceito de produtividade nas rotinas de desenvolvimento de software deve ser visto e calculado. O coeficiente de produtividade em Inglês é chamado de “Productivity Ratio” na fórmula abaixo:

Mas, antes de nos aprofundarmos na analogia, vamos primeiro parar um pouco e analisar o reconhecido conjunto de métricas DORA 4, altamente utilizado por empresas e times no mundo todo.

Accelerate e DORA 4

O livro Accelerate de Nicole Forsgren, Ph.D., Jez Humble e Gene Kim se destaca por uma estratégia poderosa e muito respeitada para DevOps. Ele usa pesquisas para apresentar e explicar as métricas de maturidade e produtividade do setor. A maturidade no desenvolvimento de software refere-se à confiabilidade da entrega, enquanto a produtividade ilustra o ritmo de trabalho.

As alterações de código podem ser implantadas com frequência, como várias vezes ao dia ou em escalas de tempo mais longas de vários dias, semanas ou até meses ou anos. Assim, as empresas podem se descrever em termos de maturidade como baixa, média, alta e elite. De acordo com Forsgren, Humble e Kim, o status de maturidade elite pertence às organizações que implantam software de qualidade várias vezes ao dia.

Na LawnStarter, empresa onde trabalho como CTO atualmente, o código chega ao ambiente de produção cerca de 10 a 12 vezes por dia. Na Schoology, onde trabalhei anteriormente, a frequência era um pouco menor, em torno de três ou quatro vezes por dia, mas com uma equipe três vezes maior.

Em algumas das minhas experiências de trabalho mais antigas, o código chegava ao ambiente de produção entre uma vez a cada três meses ou uma vez a cada doze, com investimentos ainda maiores. Atingir níveis mais altos de maturidade não é mais privilégio exclusivo de empresas de alto nível como o Google, Netflix ou outras grandes empresas; qualquer empresa pode alcançá-lo, mas requer investimentos cujo retorno costuma ser difícil de visualização para executivos ou investidores.

O trabalho necessário para melhorar a eficácia das equipes de software não é barato e leva tempo para se pagar. Porém, é tão crucial quanto qualquer nova funcionalidade que venha a ser entregue para os usuários finais.

Deployment Frequency representa um quarto da coleção de métricas DORA 4, que juntas formam um componente central do livro Accelerate. DORA significa DevOps Research and Assessment, que era o nome do grupo de pesquisa DevOps independente dos autores, adquirido pelo Google em 2018. As outras três métricas DORA 4 são:

• • Lead time for changes,
  • Mean time to recovery (MTTR) e
  • Change failure rate.

Ao todo, as métricas Accelerate e DORA 4 têm sido o principal impulsionador dos KPIs na indústria de software nos últimos anos.

Precisamos de uma perspectiva mais humana

Essa abordagem do DORA 4 coloca uma forte ênfase na alteração do código propriamente dito. Mas, onde fica a perspectiva humana e todo o trabalho que precisa ser feito, mas que não resulta em mudança de código? As métricas atuais, na minha opinião, acabaram ficando muito despersonalizadas.

Ao buscar o status de maturidade de elite, devemos garantir que não estamos apenas escrevendo código pelo simples ato de entregar apenas mais uma versão. Precisamos de equipes que, além de escrever o código, também entendam intimamente as necessidades do usuário final e do negócio.

Precisamos de engenheiros que também entendam intimamente as necessidades do usuário final e do negócio.

Essa observação sobre o entendimento do negócio não deve ser negligenciada ou minimizada. É um aspecto humano e tem que ser levado em consideração. Isso se aplica às atividades de colaboração, compartilhamento de conhecimento e formação de equipes. As organizações de sucesso criam produtos que os clientes realmente amam, o que só pode acontecer quando as pessoas certas são envolvidas e tratadas corretamente. As equipes não podem se dar ao luxo de contratar pessoas que simplesmente pressionam o teclado para escrever código sem qualquer compreensão profunda ou conexão com o usuário final.

Entender o negócio significa entender seus processos e objetivos e garantir o alinhamento total da equipe com sua Estrela do Norte. O alinhamento com a Estrela do Norte requer, ainda, uma melhor compreensão das diferentes personas dentro da equipe e como elas interagem (isso é algo que exploro em mais detalhes em meu livro).

Agora, vamos explorar mais essa analogia do carpaccio

Carpaccio é um aperitivo italiano que consiste em fatias finas de carne, geralmente servidas cruas ou mal passadas. Parte de seu apelo vem da espessura com que é fatiado. Quanto maior área de superfície de sua espessura, maximizada a sensação de sabor, tornando-o uma iguaria.

Mas, o carpaccio também pode ser usado como símbolo de “valor entregue”, tanto em restaurantes quanto por analogia no desenvolvimento de software. Confesso que sou um gourmand e adoro saborear pratos sempre que possível. Tenho uma grande satisfação em poder trazer essas experiências da vida real e correlacionar com a ciência e arte de desenvolver software. Também gosto de utilizar analogias que ajudam as equipes a se desenvolverem, crescerem e prosperarem, por meio de técnicas melhores e mais modernas. Felizmente, o carpaccio parece se encaixar em todas essas prioridades.

A experiência do usuário é fundamental, tanto na entrega do carpaccio quanto na entrega de software.

O que eu quero dizer é: quando as equipes correm para entregar software, isso se assemelha à preparação apressada do carpaccio, com as fatias cortadas incorretamente, o que posteriormente diminuirá sua experiência tátil, olfativa e de sabor. Ocasionalmente, clientes exigentes podem devolver seus pratos à cozinha se as fatias de carpaccio não atenderem ao padrão de qualidade. No software, chamamos essa experiência insatisfatória de defeito (ou bug, em inglês). Em ambos os casos, nas cozinhas ou no mundo do software, um esforço com custo adicional deve ocorrer para corrigir o problema.

No mundo do desenvolvimento de software, nos encontramos em uma era de mudanças aceleradas, prazos curtos e concorrentes agressivos. Isso significa que qualquer empresa que desenvolve software deve equilibrar seus investimentos na construção de novos recursos com os custos de manutenção dos produtos já existentes. De qualquer forma, existe muito trabalho que deve acontecer para que as equipes possam entregar valor aos usuários e garantir um negócio lucrativo e bem-sucedido.

Equipes de alto desempenho devem investir tempo em apoiar outras atividades que são vitais apesar de não serem alterações de código ou mudanças visíveis aos usuários.

Alguns exemplos podem incluir:

• • Atividades de planejamento;
  • Documentação técnica e não-técnica;
  • Investigação de código legado para aprender sua intenção original;
  • Construção de ferramentas de desenvolvimento para aumentar a eficácia das equipes;
  • Melhoria da observabilidade, escalabilidade e segurança;
  • Atualização obrigatória da plataforma e componentes críticos para funcionamento;
  • Refatoração para melhorar a manutenibilidade e performance;
  • ou, até mesmo, tocar em qualquer coisa no ambiente de produção que não utilize infra-as-code (IaC).

Todas as atividades que não parecem resultar diretamente em novas funcionalidades e não têm receita monetária diretamente associada a elas tornam o trabalho de medir a produtividade das equipes de software extremamente mais desafiador.

Para muitas empresas, esse ainda é o caminho. As métricas de produtividade permanecem focadas na quantidade de código entregue ou modificada – mas elas tendem a ficar aquém da necessidade. Aplicativos como o Code Climate fazem um trabalho excelente de medição das atividades no código, mas, no final das contas, existe muito mais que precisa acontecer para entender algo tão subjetivo quanto a produção de valor.

O que é fundamental na entrega de software é uma combinação de muitas atividades, que vão desde a ideia/concepção em si, até existência de um cliente satisfeito e disposto a pagar pelo produto. Entre esses dois pontos, você tem seres humanos que precisam trabalhar sabiamente juntos, a ponto de construir um negócio de sucesso.

A analogia do carpaccio ilustra três componentes vitais:

1. 1. Consideração de todo o trabalho necessário para criar o produto;
   2. A entrega ao cliente; e
   3. A importância de encantar os clientes para que os mesmos possam comprar o produto de forma recorrente.

Imagine uma empresa de software típica, a qual reúne um pequeno grupo de pessoas: uma com conhecimento na área de produto, algumas da área de desenvolvimento com habilidade de escrever código e uma do design, apaixonada pela experiência do usuário. Esse pequeno grupo de pessoas representa as três disciplinas do desenvolvimento de software, às quais refiro em meu livro como um triângulo de ferro (Iron triangle, em Inglês). Agora, imagine que eles estão na cozinha de um restaurante badalado, mundialmente famoso por seus antepastos, entre eles o carpaccio. No mundo ideal, seria de se esperar que essas três disciplinas (produto, design, engenharia) se concentrassem no produto final, ao invés de olharem apenas para suas especialidades.

A pessoa do design considerará a aparência final – sua apresentação no prato é servida ao cliente, pois isso contribuirá muito para a satisfação do cliente. O responsável pelo produto, provavelmente, vai querer saber se o restaurante está preparando as coisas “certas” e também vai querer explorar oportunidades para aumentar o número de carpaccios vendidos sem comprometer a qualidade. Isso é vital para aumentar os lucros sem minimizar a experiência do usuário. O engenheiro analisará a melhor forma de preparar e entregar com mais eficiência.

Portanto, não é muito difícil ver como processos bem definidos são necessários em uma cozinha, bem como em um ambiente de desenvolvimento de software. Sem eles, as pessoas estarão pisando no calo umas das outras e os clientes e a empresa sofrerão as consequências. No caso do carpaccio, se não houver faca ou fatiador devidamente afiados, o produto sairá muito grosso ou será fatiado de forma inconsistente. Quando isso acontece no desenvolvimento de software, é um bug e isso vai aumentar o Change Failure Rate (uma das métricas DORA) ou, como gosto de chamar, o Carpaccio Defect Rate.

Contudo, até mesmo essa lógica não é boa o suficiente. O sistema deve funcionar melhor do que isso para criar valor e manter um negócio sustentável. No desenvolvimento de software, houve um tempo em que era aceitável a existência de bugs quando o código era colocado em ambiente de produção e disponibilizado aos usuários. Mas agora os consumidores são mais exigentes e, provavelmente, abandonarão o produto de maneira imediata e permanente, no caso de isso acontecer. Os níveis de tolerância a erros são muito mais baixos hoje em dia. Em um restaurante, um cliente insatisfeito pode nunca mais voltar e, pior, pode deixar comentários negativos nas redes sociais, principalmente, se for apaixonado por um carpaccio excepcional.

O desafio de satisfazer o cliente

Uma boa comida não se limita apenas à qualidade dos ingredientes e à técnica de preparo. Uma grande parte do sucesso de um restaurante vem da entrega do prato à mesa. Em um restaurante, os clientes esperam que todos na mesa recebam suas refeições exatamente ao mesmo tempo e cada refeição deve estar ao seu gosto. Ninguém gosta de ser a única pessoa em uma mesa cuja comida não chega ao mesmo tempo que os demais.

Esse é um elemento implícito da experiência gastronômica e não está impresso em nenhum menu. É um daqueles pilares estruturais que, apesar de invisíveis, suportam a qualidade do produto final. A preparação do prato e a entrega do prato à mesa são dois processos separados e é a essência da gestão eficiente de um restaurante.

Servir comida à mesa pode ser comparável a entregar código ao ambiente de produção.

A ideia principal por trás do CI/CD é entregar código com mais frequência, entregando valor com riscos menores. Às vezes, essa não é tida como uma atividade trivial, ou sequer possível, se investimentos contínuos não forem adicionados durante os ciclos de planejamentos estratégicos.

Dependendo da arquitetura do aplicativo – monolítico, microsserviços ou serveless – e como as equipes são organizadas, várias pessoas de equipes diferentes necessitam contribuir para o mesmo repositório de código. Isso acaba levando a uma alta complexidade para coordenar todo o código a ser entregue aos usuários, impedindo a cadência desejada ou necessária. Do ponto de vista do restaurante, é como ter um único garçom para levar a comida da cozinha para todos os clientes. Nesse exemplo, o tempo de espera para cada mesa será maior do que os clientes estão dispostos a aceitar.

O objetivo é que cada aplicação de software possa ser lançada várias vezes ao dia, sempre que o código estiver pronto para os usuários finais. Em um restaurante, a comida deve ser servida sempre que todos os pratos de uma mesa estiverem prontos. Mesmo no livro Accelerate, os autores falam sobre a necessidade das equipes serem autossuficientes e capacitadas, o que implica na entrega rápida de código.

Eu, particularmente, gosto de ressaltar que todo o código vem com dependências. Os aplicativos se entrelaçam, o que significa que raramente é possível liberar um sem interromper uma conexão em outro ponto. As equipes de desenvolvimento de software podem utilizar técnicas para criar APIs robustas, estratégias de teste sofisticadas, codificação defensiva etc, tudo na tentativa de tornar cada componente de software o mais independente possível.

No mundo ideal, as equipes teriam a liberdade de alterar qualquer componente sem impactar suas dependências.

Mas, na realidade, é muito provável que haverá dependência e complexidades envolvidas. Isso significa que, mais cedo ou mais tarde, as equipes terão que se coordenar para contribuir com a mesma base de código e gerenciar os lançamentos de código a produção.

A realidade é que o processo para entregar o software aos usuários leva tempo e o processo em si tem limitações. No LawnStarter, leva cerca de 30 a 40 minutos para colocar nossa API principal em produção. Toda vez que o Time A e o Time B quiserem lançar alterações na API, eles podem ter seus códigos enviados juntos.

Quando ambas as mudanças vão bem, isso é ótimo. Mas, quando uma delas dá errado, as duas mudanças de código devem voltar para a cozinha, mesmo que apenas uma esteja com defeito. Elas estão presas uma à outra e isso tem um custo.

Então, usando novamente a analogia da cozinha do restaurante, é como um garçom dizendo à cozinha o que é necessário para uma mesa que tem dois pedidos de carpaccio com estilos diferentes. Para o chef, isso significa dois pedidos de carpaccio em uma mesma remessa. Essa remessa adicionará outro dígito à métrica de Deployment Frequency. O valor final para o restaurante será a entrega bem-sucedida dos dois pedidos de carpaccio diferentes no prazo e corretamente. O problema é que, quando as coisas dão errado com um prato, o garçom deve trazer todos os pratos de volta para a cozinha, mesmo que apenas um deles não esteja ao gosto do cliente. Mesmo que isso possa não acontecer na prática, seria a coisa certa a fazer.

Situações como essa afetam, como um todo, a satisfação do cliente, os lucros do restaurante e, possivelmente, sua reputação.

Fatias de carpaccio no desenvolvimento de software

Para entender os níveis de cuidado envolvidos no desenvolvimento de software, sugiro que as equipes de produto e desenvolvimento de software usem a seguinte abordagem ao dividir o trabalho, inspirada no jeito que as equipes da Atlassian fazem, ou seja, em que cada um é um subconjunto do anterior:

Rocks->

            Initiative-

                        >Epic

                                ->Stories
                                -> Bugs
                                ->Tasks

Na analogia do carpaccio, você pode imaginar stories e bugs como um pedaço individual e o mais granular. Uma story é um pedaço de carpaccio recém fatiado com perfeição que está ao gosto do cliente.

Uma story não deve ser tão grande, que, ao prepará-la, demore muito mais do que os clientes estariam dispostos a esperar, ou tão grande que os clientes não gostem de comê-la. Uma story também não deve ser cortada tão fina, o que poderia fazer com que os clientes não fiquem dispostos a pagar por ela. Nas minhas equipes, gosto de definir como meta que as stories não demorem mais de cinco dias, desde o início do trabalho até a entrega aos clientes. Se precisar de mais tempo, precisará ser fatiado em fatias ainda mais finas.

Um Bug acontece quando entregamos um carpaccio que não correspondeu às expectativas e foi mandado de volta para a cozinha. Conforme mencionado na seção anterior, às vezes, os clientes em um restaurante podem enviar seus pratos de volta quando ele não atende às expectativas. Em ambos os casos, várias atividades e despesas extras serão incorridas para corrigir o problema.

É importante ressaltar que corrigir bugs é essencial para qualquer negócio sustentável e as correções nunca devem ser contabilizadas como novos pedaços de carpaccio, da mesma forma que um cliente em um restaurante não pagaria duas vezes por um prato insatisfatório, que foi enviado de volta à cozinha e substituído posteriormente.

As tasks são compostas por todas as atividades necessárias para produzir o carpaccio. As tasks não representam a entrega direta do produto aos clientes, mas são essenciais para o preparo do carpaccio na cozinha. Tarefas como afiar as facas e limpar a cozinha são bons exemplos de contribuições igualmente essenciais para o resultado final. Como mencionado anteriormente, no software, isso inclui atividades valiosas, como planejamento, escrever documentação, investir tempo, entender o código de uma funcionalidade etc.

As epics são como servir pratos cheios de carpaccio. Quando combinamos vários pratos, temos uma Initiative com carpaccio suficiente para servir uma ou mais mesas cheias. Várias Initiatives comporiam o Rock inteiro, representando carpaccio suficiente para servir a todos no salão de um restaurante. Um Rock seria quando entregamos iniciativas suficientes para atingir uma meta, o que seria suficiente para contribuir com o crescimento do negócio.

No mundo real do desenvolvimento de software e agora descrito na ordem inversa, um Rock é um objetivo mensurável da empresa, revisado trimestralmente e que pode abranger vários trimestres. É uma área de foco que pode abranger várias equipes e departamentos, o que, em última análise, ajuda a contar a história de como eles estão construindo a visão da empresa. Um Rock é composto de várias Initiatives.

Uma Initiative é um escopo de trabalho com limite de tempo que avança em direção a uma meta definida para um dos Rocks da empresa. Produz valor comercial quantificável e apresenta soluções significativas para o usuário como um projeto. Toda Initiative deve responder às seguintes perguntas:

1. 1. Qual é o objetivo?
   2. Que problema estamos resolvendo e por que fazê-lo agora?
   3. Quais as métricas de sucesso?

Uma Initiative é composta por um grupo de Epics, Stories, Tasks e SubTasks. Todo o trabalho executado deve fazer parte de uma Initiative, salvo algumas exceções, tais como corrigir um bug antigo.

Uma Epic é um marco dentro de uma Initiative e representa um conjunto coeso de Stories (às vezes, também inclui bugs), que atingem os objetivos declarados. As Epics devem ter um começo claro e um fim planejado. Além disso, as Epics devem ter um propósito/escopo definido representando com um marco/lançamento. Uma Epic conecta Stories de usuários que podem ser enviados individualmente para uma iniciativa, agrupando um conjunto de Stories com uso ou valor comercial semelhante. As Epics devem representar fatias verticais de trabalho que fornecem valor de ponta a ponta e não entregas de forma isolada.

Stories, Bugs e Tasks são pequenos incrementos (cinco dias ou menos) de trabalho necessários para ajudar na composição e entrega de uma Epic.

A taxa de produtividade de Carpaccio

Há anos, utilizo Deployment Frequency e as outras DORA métricas. Ainda assim, sempre encontro desafios grandes para demonstrar a produtividade dos meus times, principalmente, por causa do “trabalho invisível que acontece na cozinha”. É por essa razão, que acabei chegando ao Coeficiente de Produtividade (Productivity Ratio) mencionado anteriormente. Ao meu ver, é uma maneira mais completa de explicar a produtividade em times que desenvolvem software. Mais uma vez, a fórmula é assim:

O Coeficiente de Produtividade pode ser medido dividindo-se a quantidade de carpaccio servida (código em produção) pela quantidade de carpaccio produzida (todo o trabalho realizado).

O ROI tem uma dependência do Coeficiente de Produtividade. Por exemplo:

• • Quando o Coeficiente de Produtividade = 0%, muita coisa está acontecendo na cozinha, mas nenhum carpaccio está sendo servido. Portanto, o restaurante não pode ser sustentável.
  • Quando o Coeficiente de Produtividade = 100%, todo o trabalho da cozinha resulta diretamente no carpaccio servido aos clientes. Isso é uma utopia e impossível, na minha opinião.

Os números ideais, na minha experiência prática e utilizando dados reais quando aplicado nas minhas equipes, são:

• • Coeficiente de Produtividade < 70%: As equipes precisam se concentrar mais na entrega de carpaccio/código em produção.
  • Coeficiente de Produtividade >= 70% e <= 85%: Bom equilíbrio entre atividades que são necessárias e código entregue em produção.
  • Coeficiente de Produtividade > 85%: Oportunidade de investir em atividades que possam promover melhor compartilhamento de conhecimento, colaboração mais efetiva, melhorias na experiência do usuário, melhorias nos processos etc. Qualquer coisa que possa tornar a cozinha mais eficiente em geral ou atividades para ajudar a escalar o negócio.

A ilustração a seguir destina-se a representar as métricas conhecidas do setor e como os novos A) Carpaccio Served e C) Carpaccio Production se conectam a eles:

A) Carpaccio Served ou Carpaccio Servido: Todo o carpaccio que é servido aos clientes. O resultado é receita direta para o negócio.

B) Carpaccio Frequency ou Frequência de Carpaccio Servido: A velocidade com que os carpaccios estão sendo servidos, que sejam entregues individualmente ou em grupos. A indústria de software chama isso de “Deployment Frequency”.

C) Carpaccio Production ou Produção do Carpaccio: Todo o trabalho necessário para produzir o carpaccio. Isso inclui afiar facas, limpar pratos, organizar a cozinha e cortar o próprio carpaccio.

D) Carpaccio Production Time ou Tempo de Produção do Carpaccio: O tempo que leva entre o carpaccio ser cortado e preparado até ser servido ao cliente. A indústria de software chama isso de “Cycle Time”.

E) Defective Carpaccio Rate ou Números de Carpaccios Defeituosos = Carpaccio Defeituoso / Carpaccio Servido. A indústria de software chama isso de “Change Failure Rate”.

F) Carpaccio Lead Time (Não representado na figura): O tempo que leva desde que o cliente faz o pedido até que o carpaccio chegue à mesa. A indústria de software chama isso de “Lead Time for Change”.

Fatorando uma dívida estratégica

Quando planejada corretamente, a noção de dívida também pode ser considerada como uma contribuição positiva e equilibrada para o Coeficiente de Produtividade. Por um lado, uma decisão de tomar emprestado no futuro permite que você consiga algo mais cedo, mas, por outro lado, quando você contrai muitas dívidas, limita sua produtividade devido ao montante de juros que tem que pagar, ser pago.

Em um cenário de restaurante em um sábado movimentado, você pode decidir não sobrecarregar a equipe lavando todos os pratos, liberando-os para garantir que possam fazer sua parte atendendo os clientes prontamente (aumentando sua taxa de produtividade). Mas, se você não lavar toda a louça antes do próximo dia agitado, não conseguirá atender a todos os clientes (portanto, uma taxa de produtividade menor). Agora, de volta ao ROI.

Os investidores sempre querem ver um negócio sustentável e lucrativo.

Suponha que eles invistam $1 milhão para adicionar mais pessoas, comprar maquinário mais moderno ou introduzir nova tecnologia para aumentar a capacidade de entrega no restaurante. Nesse caso, eles esperam $1 milhão + X multiplicador em Y período de tempo. No restaurante, se não for servido carpaccio, nenhum cliente está pagando, o que significa que o negócio não é sustentável. Se o restaurante atingir 100% de Coeficiente de Produtividade, pode ter um ótimo desempenho no curto prazo, mas não será sustentável. Os pratos ficarão sujos, as facas ficarão sem fio e, mais cedo ou mais tarde, as pessoas vão acabar pisando umas nas outras devido a processos subotimizados. Uma taxa de produtividade ideal e realista seria entre 70% e 85%.

Como já foi dito, os investidores querem que os clientes desfrutem de sua experiência gastronômica para que possam retornar com frequência. Quanto mais esse padrão se repetir, mais o negócio se torna previsível. Em termos de negócios, o aumento do ARR (Receita Anual Recorrente) significa que as coisas estão indo na direção certa para um crescimento sustentável.

Vendo o desafio de uma perspectiva de liderança

Testei essa analogia do carpaccio e do restaurante com meu público-alvo – os líderes executivos e os investidores da LawnStarter. Depois de muita conversa, eles já tinham a noção que se basear apenas em métricas de código era inadequado para medir a produtividade da equipe. Essas métricas não estavam dando a transparência necessária para visualizar todo o trabalho sendo entregue.

Os membros executivos tinham perguntas como: “por que estamos investindo X milhões de dólares para adicionar mais pessoas à equipe quando a frequência em que o código chega no ambiente de produção não está aumentando proporcionalmente?”

Eu sempre achei esse questionamento justo. Mesmo que todos estivessem trabalhando muito duro, a melhoria não era visível. Meus colegas executivos tinham todo o direito de me pedir para explicar o ROI, especialmente, pelo fato de que estávamos aumentando o investimento. Voltando à analogia carpaccio/cozinha do restaurante, a minha resposta foi: “É fato que, quando aumentamos o número de pessoas na cozinha, vamos conseguir produzir mais carpaccio. Mas, isso resulta que os garçons passam a ter suas bandejas mais cheias de pratos e é aí que o gargalo acontece. A cozinha está trabalhando a todo vapor, mas há um limite na quantidade que os garçons conseguem servir!”

Esse foi o momento em que eles conseguiram visualizar as limitações que enfrentamos todos os dias enquanto estamos desenvolvendo software. Temos algumas aplicações em que o CI/CD é limitado e várias equipes contribuem para a mesma base de código, dificultando nossa habilidade de entregar aos usuários com mais frequência. Mas, eles queriam saber mais sobre como servir mais carpaccio aos clientes para que se pudesse aumentar o faturamento visto o aumento no investimento. “OK, estamos produzindo mais carpaccio”, disseram eles, “mas, como saber se estamos gastando muito tempo afiando facas ou organizando coisas que não são necessárias? Como encontrar o equilíbrio certo entre tudo que produzimos e o que conseguimos servir aos clientes?”

Foi aqui que consegui descrever as métricas de um jeito que eles pudessem entender:

• • A métrica principal, eu disse, é a quantidade total de carpaccio servido, a métrica Carpaccio Served. Esse é o número que trará os lucros para o restaurante.
  • A métrica de contrapeso é todo o trabalho necessário para produzir esses carpaccio, a métrica de Carpaccio Produced.
  • A métrica de produtividade real necessária para ajudar a entender o ROI vem da proporção da quantidade servida dividida pela quantidade produzida, como expliquei anteriormente.
  • Deployment Frequency continua sendo uma métrica válida para medir a maturidade e ajudar as equipes a entender as melhorias que precisam ser feitas para acelerar o processo de colocar o carpaccio na frente dos clientes.

Sem entender a fórmula da produtividade, alguns riscos aparecem:

• • Corremos o risco de produzir muito carpaccio, a maioria dos quais não chegarão ao prato dos clientes.
  • Corremos o risco de trabalhar demais em atividades internas da cozinha, mas que não necessariamente produziriam carpaccio suficiente para ser servido.
  • Corremos o risco de não poder servir o carpaccio quando este estiver disponível para ser servido.

O ponto principal é que escalar não é uma tarefa fácil, mas é necessária para qualquer empresa de sucesso. Todo CTO ou líder de equipes de software lida com o mesmo desafio: “como maximizar a eficiência para que as equipes possam entregar mais valor em menos tempo”. Isso é esperado, visto que as equipes que criam o software fazem parte, geralmente, do departamento mais caro de qualquer empresa SaaS. Por esse motivo, as métricas de produtividade têm que trazer a transparência de todo o trabalho feito por todos no departamento.

Conclusão

A indústria precisa de uma maneira melhor de medir a produtividade. As métricas disponíveis, incluindo as métricas DORA, não consideram todo o trabalho feito e são obcecadas em olhar apenas da perspectiva do código. Já o Coeficiente de Produtividade reduz a lacuna na comunicação do desempenho de uma equipe, permitindo que ela possa focar e trabalhar nas atividades que vão levar ao sucesso da empresa.

*Alberto Silveira é um líder executivo de sucesso, atuando no mercado norte americano por quase duas décadas. Ele é um entusiasta em tecnologia e apaixonado por construir equipes de alto desempenho que agregam valor às organizações. Desde sua adolescência, desmontando e reconstruindo hardware de computadores, até sua vida profissional codificando e automatizando quase tudo o que via pela frente, sua trajetória o tornou um exemplo. Sua abordagem One Team, One Heart para gestão de pessoas está incorporada em seu último livro, Building and Managing High-Performance Distributed Teams. O livro é compilado de seus anos como desenvolvedor de software e líder, bem como em sua outra vida como navegador competitivo e tripulante. Em seu livro e em suas apresentações, Alberto oferece uma coleção de técnicas ​​para gerenciar equipes. Isso inclui técnicas de comunicação e colaboração e estilos de liderança vitais que ajudam a envolver e inspirar as equipes a trabalhar juntas, não importa onde cada membro esteja.

Versão original do artigo em Inglês – clique aqui para conferir.

Gostou deste conteúdo?

O autor, junto à Caroli.org, está organizando um Treinamento sobre este tema. Se você tem interesse, participe deste grupo de WhatsApp, onde iremos definir as datas: