Como medir a produtividade de desenvolvedores: casos reais do Google, Notion e outras empresas

xguru · 2024-01-22T11:06:01+09:00

Uma análise aprofundada de como 17 empresas de tecnologia, como Google, LinkedIn, Peloton, Amplitude, Intercom, Notion e Postman, medem a produtividade de desenvolvedores 1. Métricas de produtividade de desenvolvedores em 17 empresas de tecnologia Medir a produtividade de desenvolvedores é um problema complexo, e o próprio significado de ser “produtivo” em engenharia de software, um trabalho baseado em conhecimento, é ambíguo Equipes chamadas de produtividade de desenvolvedores (DevProd) ou experiência do desenvolvedor (DevEx) ajudam desenvolvedores a implantar software de alta qualidade com mais facilidade Essas equipes precisam de métricas de produtividade de desenvolvedores para medir a produtividade e os obstáculos das equipes de engenharia, e acompanhar se seu trabalho está realmente gerando impacto Métricas de produtividade de desenvolvedores usadas por essas empresas Facilidade de entrega (Amplitude, GoodRx, Intercom, Postman, Lattice) Velocidade de experimentação (Etsy) Estabilidade de serviços/apps (DoorDash) Métricas SPACE (Microsoft) Tempo semanal de foco por engenheiro (Uber) Quatro empresas foram selecionadas por faixa de tamanho Google: mais de 100.000 funcionários LinkedIn: mais de 10.000 Peloton: entre 1.000 e 10.000 Scale-ups (entre 100 e 1.000 engenheiros): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. A abordagem do Google O Google é frequentemente citado como referência em medição de produtividade de desenvolvedores, mas também há quem diga que imitar o nível de investimento do Google é inviável para a maioria das empresas A Developer Intelligence team do Google é uma área especializada que mede a produtividade de desenvolvedores e fornece insights para líderes O Google acredita que uma única métrica não consegue capturar a produtividade, e analisa o tema em três dimensões: velocidade, facilidade e qualidade Speed velocidade: quanto tempo leva para uma revisão de código ser concluída? Ease facilidade: quão fácil ou difícil é para um desenvolvedor passar pelo processo de code review? Quality qualidade: qual é o nível de qualidade do feedback recebido na revisão de código? O Google calcula métricas combinando medições qualitativas e quantitativas 3. LinkedIn O LinkedIn opera de forma independente dentro da Microsoft e emprega mais de 10.000 pessoas No LinkedIn, existe a equipe Developer Insights, que mede produtividade e satisfação dos desenvolvedores e compartilha insights com o restante da organização O LinkedIn captura métricas usando pesquisas trimestrais, um sistema de feedback em tempo real e métricas baseadas em sistemas Pesquisas trimestrais: A equipe Developer Insights avalia a experiência do desenvolvedor em várias ferramentas, processos e atividades por meio de pesquisas trimestrais A pesquisa inclui cerca de 30 perguntas, e os desenvolvedores conseguem responder em aproximadamente 10 minutos As pesquisas são distribuídas por uma plataforma proprietária desenvolvida e gerenciada pela equipe Developer Insights, que permite personalização avançada das perguntas com base em dados coletados pelos sistemas de feedback em tempo real e de métricas Sistema de feedback em tempo real: Para coletar feedback entre as pesquisas trimestrais, o LinkedIn desenvolveu um sistema de feedback em tempo real que rastreia eventos e ações executados por desenvolvedores dentro das ferramentas de desenvolvimento e envia pesquisas direcionadas com base em gatilhos específicos Esse sistema usa um mecanismo inteligente de limitação para evitar excesso de solicitações de feedback aos desenvolvedores Métricas baseadas em sistemas: O LinkedIn também usa dados dos sistemas para calcular métricas, oferecendo medições de alta precisão para itens como tempo de build e frequência de deploy A equipe Developer Insights mantém um sistema global para coletar e analisar esses dados, chamado Developer Insights Hub, ou iHub Por meio desse sistema, todas as equipes do LinkedIn podem criar dashboards e métricas personalizadas conforme suas necessidades O LinkedIn considera métricas qualitativas e quantitativas Developer Net User Satisfaction (NSAT): mede o quanto os desenvolvedores estão satisfeitos, de forma geral, com os sistemas de desenvolvimento do LinkedIn. É medido trimestralmente Developer Build Time (P50 e P90): mede em segundos quanto tempo os desenvolvedores esperam para um build local ser concluído durante o desenvolvimento Code Reviewer Response Time (P50 e P90): mede quanto tempo os revisores de código levam para responder a cada atualização de code review feita pelo autor, com base em horário comercial Post-Commit CI Speed (P50 e P90): mede em minutos quanto tempo cada commit leva para passar pelo pipeline de integração contínua (CI) CI Determinism: conceito oposto à instabilidade de testes. Refere-se à probabilidade de que o resultado da suíte de testes seja válido e não um erro Deployment Success Rate: mede com que frequência deploys em produção são bem-sucedidos Winsorized Means: uma forma de reconhecer melhorias em métricas com outliers. O cálculo substitui os valores mais altos e mais baixos por números mais próximos do centro The Developer Experience Index: uma métrica especial fornecida pelo LinkedIn às equipes. Esse índice é uma pontuação composta baseada em várias métricas, como as listadas acima 4. Peloton A Peloton é uma empresa grande, com cerca de 3.000 a 4.000 funcionários, embora seja bem menor que o LinkedIn A abordagem de medição da Peloton começou pela obtenção de insights qualitativos por meio de pesquisas de experiência do desenvolvedor, depois complementadas com métricas quantitativas A Peloton mede produtividade com foco em quatro áreas principais: engajamento, velocidade, qualidade e estabilidade Engagement engajamento: pontuação de satisfação dos desenvolvedores Velocity velocidade: tempo até o primeiro e o décimo PR de cada novo contratado, lead time e frequência de deploy Quality qualidade: proporção de PRs com menos de 250 linhas, cobertura de linhas e taxa de falha de mudanças Stability estabilidade: tempo de recuperação de serviços A pesquisa de experiência do desenvolvedor, que mede boa parte dessas métricas, é liderada pela equipe de suporte técnico e experiência do desenvolvedor da Peloton, parte da organização de operações de produto A equipe de suporte técnico e experiência do desenvolvedor também é responsável por analisar os resultados da pesquisa e compartilhá-los com líderes de toda a organização 5. Scale-ups e empresas menores Várias scale-ups, como Notion, Postman, Amplitude, GoodRx, Intercom e Lattice, empregam entre 100 e 1.000 engenheiros Essas empresas focam em “métricas acionáveis” (Moveable Metrics) Métricas acionáveis são métricas que a equipe de produtividade de desenvolvedores consegue “mover”, impactando positiva ou negativamente o trabalho. Elas são úteis para mostrar a influência da equipe de produtividade de desenvolvedores Métricas comuns Facilidade de entrega (Ease of Delivery, moveable): A maioria das empresas mede a facilidade de entrega, uma medida qualitativa de quão fácil ou difícil os desenvolvedores sentem que é realizar seu trabalho Vários líderes de DevProd dizem que usam essa métrica como a “estrela do norte” do time, porque o objetivo da equipe é tornar a vida dos desenvolvedores mais fácil Como essa métrica é bastante passível de mudança, ela também é útil para demonstrar impacto Do ponto de vista teórico, essa métrica também captura aspectos centrais da experiência do desenvolvedor, como carga cognitiva e loops de feedback Engajamento (Engagement) Também acompanham o engajamento, que mede o quanto os desenvolvedores se sentem interessados e estimulados em relação ao trabalho Em geral, o engajamento é medido em pesquisas de RH, mas equipes de DevProd também o priorizam por esse motivo Engajamento e produtividade de desenvolvedores estão intimamente ligados. Em outras palavras, como diz o ditado, “desenvolvedores felizes são desenvolvedores produtivos”, então o engajamento pode ser visto como um indicador de produtividade O verdadeiro benefício de medir engajamento é equilibrar outras métricas que enfatizam velocidade. Entregar software mais rápido é bom, mas não às custas de reduzir a felicidade dos desenvolvedores Perda de tempo (Time Loss, moveable) GoodRx e Postman dão atenção à perda média de tempo Ela é medida como a proporção do tempo dos desenvolvedores perdida por causa de obstáculos no ambiente de trabalho Essa métrica é parecida com facilidade de entrega por oferecer uma métrica acionável que pode ser diretamente impactada pelo trabalho da equipe de desenvolvimento Uma grande vantagem é que pode ser convertida em custo, permitindo que líderes de negócio entendam facilmente a perda de tempo Por exemplo, se uma organização com custo de mão de obra de engenharia de US$ 10 milhões reduz a perda de tempo de 20% para 10% por meio de uma iniciativa, isso gera uma economia de US$ 1 milhão Taxa de falha de mudanças (Change Failure Rate) Esta é uma das quatro métricas principais do programa de pesquisa DORA (DevOps Research and Assessment) É uma métrica de topo acompanhada por várias empresas, incluindo Amplitude e Lattice A equipe DORA define taxa de falha de mudanças da seguinte forma: “A porcentagem de mudanças liberadas para produção ou para usuários que resultam em degradação do serviço (por exemplo, indisponibilidade ou interrupção) e depois exigem correção, como hotfix, rollback, correção posterior ou patch” 6. Descobertas interessantes Métricas DORA e SPACE são usadas de forma opcional, e todas as empresas usam tanto medições qualitativas quanto quantitativas DORA: DevOps Research and Assessment SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow Há grande ênfase em “tempo de foco”, e Stripe e Uber compartilham métricas específicas como “número de dias com tempo de foco suficiente” e “tempo semanal de foco por engenheiro” Métricas únicas Adoption Rate (DoorDash, GoodRx, Spotify) Design Docs Generated per Engineer (Uber) Experiment Velocity (Etsy) Developer CSAT/NSAT (Chime, LinkedIn) 7. Como escolher suas próprias métricas É recomendável usar o framework Goals, Signals, Metrics (GSM) do Google para orientar a escolha de métricas Primeiro defina o objetivo do problema que quer resolver, depois encontre os sinais que indiquem que esse objetivo foi alcançado e então escolha as métricas adequadas Definir o objetivo Google: “Capacitar desenvolvedores a entregar ótimos produtos com rapidez e facilidade.” Slack: “Oferecer um ambiente de desenvolvimento fluido para todos os engenheiros.” Stripe: “Tornar a engenharia de software mais fácil.” Trabalhar de trás para frente a partir do objetivo para definir métricas de topo Quão fácil é para desenvolvedores entregar software? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate Quão rápido desenvolvedores entregam software? (Speed): Perceived Delivery Speed, Perceived Productivity Qualidade do software entregue (Quality): Incident frequency, Perceived Software Quality Se você é CTO, VPE ou líder de engenharia O melhor conselho é “reformular o problema” (reframe the problem) Escolha métricas em três grupos Impacto no negócio Por que isso precisa ser construído agora? De que forma esse projeto gera receita ou apoia objetivos do negócio? Esse projeto está avançando bem ou está atrasado? Performance do sistema Os sistemas de engenharia são rápidos e estáveis? A infraestrutura é segura e bem mantida? Os usuários estão satisfeitos com os serviços que usam? Eficiência de engenharia Misturar métricas qualitativas e quantitativas é algo comum em todas as empresas Vale se inspirar nas diferentes medições usadas por cada empresa Há grandes diferenças nos itens priorizados por cada empresa para medição, de acordo com suas prioridades e cultura de engenharia

(newsletter.pragmaticengineer.com)

53 pontos por xguru 2024-01-22 | 1 comentários | Compartilhar no WhatsApp

Uma análise aprofundada de como 17 empresas de tecnologia, como Google, LinkedIn, Peloton, Amplitude, Intercom, Notion e Postman, medem a produtividade de desenvolvedores

1. Métricas de produtividade de desenvolvedores em 17 empresas de tecnologia

Medir a produtividade de desenvolvedores é um problema complexo, e o próprio significado de ser “produtivo” em engenharia de software, um trabalho baseado em conhecimento, é ambíguo
Equipes chamadas de produtividade de desenvolvedores (DevProd) ou experiência do desenvolvedor (DevEx) ajudam desenvolvedores a implantar software de alta qualidade com mais facilidade
Essas equipes precisam de métricas de produtividade de desenvolvedores para medir a produtividade e os obstáculos das equipes de engenharia, e acompanhar se seu trabalho está realmente gerando impacto
Métricas de produtividade de desenvolvedores usadas por essas empresas
- Facilidade de entrega (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Velocidade de experimentação (Etsy)
- Estabilidade de serviços/apps (DoorDash)
- Métricas SPACE (Microsoft)
- Tempo semanal de foco por engenheiro (Uber)
Quatro empresas foram selecionadas por faixa de tamanho
- Google: mais de 100.000 funcionários
- LinkedIn: mais de 10.000
- Peloton: entre 1.000 e 10.000
- Scale-ups (entre 100 e 1.000 engenheiros): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. A abordagem do Google

O Google é frequentemente citado como referência em medição de produtividade de desenvolvedores, mas também há quem diga que imitar o nível de investimento do Google é inviável para a maioria das empresas
A Developer Intelligence team do Google é uma área especializada que mede a produtividade de desenvolvedores e fornece insights para líderes
O Google acredita que uma única métrica não consegue capturar a produtividade, e analisa o tema em três dimensões: velocidade, facilidade e qualidade
- Speed velocidade: quanto tempo leva para uma revisão de código ser concluída?
- Ease facilidade: quão fácil ou difícil é para um desenvolvedor passar pelo processo de code review?
- Quality qualidade: qual é o nível de qualidade do feedback recebido na revisão de código?
O Google calcula métricas combinando medições qualitativas e quantitativas

3. LinkedIn

O LinkedIn opera de forma independente dentro da Microsoft e emprega mais de 10.000 pessoas
No LinkedIn, existe a equipe Developer Insights, que mede produtividade e satisfação dos desenvolvedores e compartilha insights com o restante da organização
O LinkedIn captura métricas usando pesquisas trimestrais, um sistema de feedback em tempo real e métricas baseadas em sistemas
- Pesquisas trimestrais:
  - A equipe Developer Insights avalia a experiência do desenvolvedor em várias ferramentas, processos e atividades por meio de pesquisas trimestrais
  - A pesquisa inclui cerca de 30 perguntas, e os desenvolvedores conseguem responder em aproximadamente 10 minutos
  - As pesquisas são distribuídas por uma plataforma proprietária desenvolvida e gerenciada pela equipe Developer Insights, que permite personalização avançada das perguntas com base em dados coletados pelos sistemas de feedback em tempo real e de métricas
- Sistema de feedback em tempo real:
  - Para coletar feedback entre as pesquisas trimestrais, o LinkedIn desenvolveu um sistema de feedback em tempo real que rastreia eventos e ações executados por desenvolvedores dentro das ferramentas de desenvolvimento e envia pesquisas direcionadas com base em gatilhos específicos
  - Esse sistema usa um mecanismo inteligente de limitação para evitar excesso de solicitações de feedback aos desenvolvedores
- Métricas baseadas em sistemas:
  - O LinkedIn também usa dados dos sistemas para calcular métricas, oferecendo medições de alta precisão para itens como tempo de build e frequência de deploy
  - A equipe Developer Insights mantém um sistema global para coletar e analisar esses dados, chamado Developer Insights Hub, ou iHub
  - Por meio desse sistema, todas as equipes do LinkedIn podem criar dashboards e métricas personalizadas conforme suas necessidades
O LinkedIn considera métricas qualitativas e quantitativas
- Developer Net User Satisfaction (NSAT): mede o quanto os desenvolvedores estão satisfeitos, de forma geral, com os sistemas de desenvolvimento do LinkedIn. É medido trimestralmente
- Developer Build Time (P50 e P90): mede em segundos quanto tempo os desenvolvedores esperam para um build local ser concluído durante o desenvolvimento
- Code Reviewer Response Time (P50 e P90): mede quanto tempo os revisores de código levam para responder a cada atualização de code review feita pelo autor, com base em horário comercial
- Post-Commit CI Speed (P50 e P90): mede em minutos quanto tempo cada commit leva para passar pelo pipeline de integração contínua (CI)
- CI Determinism: conceito oposto à instabilidade de testes. Refere-se à probabilidade de que o resultado da suíte de testes seja válido e não um erro
- Deployment Success Rate: mede com que frequência deploys em produção são bem-sucedidos
- Winsorized Means: uma forma de reconhecer melhorias em métricas com outliers. O cálculo substitui os valores mais altos e mais baixos por números mais próximos do centro
- The Developer Experience Index: uma métrica especial fornecida pelo LinkedIn às equipes. Esse índice é uma pontuação composta baseada em várias métricas, como as listadas acima

4. Peloton

A Peloton é uma empresa grande, com cerca de 3.000 a 4.000 funcionários, embora seja bem menor que o LinkedIn
A abordagem de medição da Peloton começou pela obtenção de insights qualitativos por meio de pesquisas de experiência do desenvolvedor, depois complementadas com métricas quantitativas
A Peloton mede produtividade com foco em quatro áreas principais: engajamento, velocidade, qualidade e estabilidade
- Engagement engajamento: pontuação de satisfação dos desenvolvedores
- Velocity velocidade: tempo até o primeiro e o décimo PR de cada novo contratado, lead time e frequência de deploy
- Quality qualidade: proporção de PRs com menos de 250 linhas, cobertura de linhas e taxa de falha de mudanças
- Stability estabilidade: tempo de recuperação de serviços
A pesquisa de experiência do desenvolvedor, que mede boa parte dessas métricas, é liderada pela equipe de suporte técnico e experiência do desenvolvedor da Peloton, parte da organização de operações de produto
A equipe de suporte técnico e experiência do desenvolvedor também é responsável por analisar os resultados da pesquisa e compartilhá-los com líderes de toda a organização

5. Scale-ups e empresas menores

Várias scale-ups, como Notion, Postman, Amplitude, GoodRx, Intercom e Lattice, empregam entre 100 e 1.000 engenheiros
Essas empresas focam em “métricas acionáveis” (Moveable Metrics)
- Métricas acionáveis são métricas que a equipe de produtividade de desenvolvedores consegue “mover”, impactando positiva ou negativamente o trabalho. Elas são úteis para mostrar a influência da equipe de produtividade de desenvolvedores
Métricas comuns
- Facilidade de entrega (Ease of Delivery, moveable):
  - A maioria das empresas mede a facilidade de entrega, uma medida qualitativa de quão fácil ou difícil os desenvolvedores sentem que é realizar seu trabalho
  - Vários líderes de DevProd dizem que usam essa métrica como a “estrela do norte” do time, porque o objetivo da equipe é tornar a vida dos desenvolvedores mais fácil
  - Como essa métrica é bastante passível de mudança, ela também é útil para demonstrar impacto
  - Do ponto de vista teórico, essa métrica também captura aspectos centrais da experiência do desenvolvedor, como carga cognitiva e loops de feedback
- Engajamento (Engagement)
  - Também acompanham o engajamento, que mede o quanto os desenvolvedores se sentem interessados e estimulados em relação ao trabalho
  - Em geral, o engajamento é medido em pesquisas de RH, mas equipes de DevProd também o priorizam por esse motivo
  - Engajamento e produtividade de desenvolvedores estão intimamente ligados. Em outras palavras, como diz o ditado, “desenvolvedores felizes são desenvolvedores produtivos”, então o engajamento pode ser visto como um indicador de produtividade
  - O verdadeiro benefício de medir engajamento é equilibrar outras métricas que enfatizam velocidade. Entregar software mais rápido é bom, mas não às custas de reduzir a felicidade dos desenvolvedores
- Perda de tempo (Time Loss, moveable)
  - GoodRx e Postman dão atenção à perda média de tempo
  - Ela é medida como a proporção do tempo dos desenvolvedores perdida por causa de obstáculos no ambiente de trabalho
  - Essa métrica é parecida com facilidade de entrega por oferecer uma métrica acionável que pode ser diretamente impactada pelo trabalho da equipe de desenvolvimento
  - Uma grande vantagem é que pode ser convertida em custo, permitindo que líderes de negócio entendam facilmente a perda de tempo
  - Por exemplo, se uma organização com custo de mão de obra de engenharia de US$ 10 milhões reduz a perda de tempo de 20% para 10% por meio de uma iniciativa, isso gera uma economia de US$ 1 milhão
- Taxa de falha de mudanças (Change Failure Rate)
  - Esta é uma das quatro métricas principais do programa de pesquisa DORA (DevOps Research and Assessment)
  - É uma métrica de topo acompanhada por várias empresas, incluindo Amplitude e Lattice
  - A equipe DORA define taxa de falha de mudanças da seguinte forma:
  “A porcentagem de mudanças liberadas para produção ou para usuários que resultam em degradação do serviço (por exemplo, indisponibilidade ou interrupção) e depois exigem correção, como hotfix, rollback, correção posterior ou patch”

6. Descobertas interessantes

Métricas DORA e SPACE são usadas de forma opcional, e todas as empresas usam tanto medições qualitativas quanto quantitativas
- DORA: DevOps Research and Assessment
- SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
Há grande ênfase em “tempo de foco”, e Stripe e Uber compartilham métricas específicas como “número de dias com tempo de foco suficiente” e “tempo semanal de foco por engenheiro”
Métricas únicas
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)

7. Como escolher suas próprias métricas

É recomendável usar o framework Goals, Signals, Metrics (GSM) do Google para orientar a escolha de métricas
Primeiro defina o objetivo do problema que quer resolver, depois encontre os sinais que indiquem que esse objetivo foi alcançado e então escolha as métricas adequadas
- Definir o objetivo
  - Google: “Capacitar desenvolvedores a entregar ótimos produtos com rapidez e facilidade.”
  - Slack: “Oferecer um ambiente de desenvolvimento fluido para todos os engenheiros.”
  - Stripe: “Tornar a engenharia de software mais fácil.”
- Trabalhar de trás para frente a partir do objetivo para definir métricas de topo
  - Quão fácil é para desenvolvedores entregar software? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - Quão rápido desenvolvedores entregam software? (Speed): Perceived Delivery Speed, Perceived Productivity
  - Qualidade do software entregue (Quality): Incident frequency, Perceived Software Quality
Se você é CTO, VPE ou líder de engenharia
- O melhor conselho é “reformular o problema” (reframe the problem)
- Escolha métricas em três grupos
  - Impacto no negócio
    - Por que isso precisa ser construído agora?
    - De que forma esse projeto gera receita ou apoia objetivos do negócio?
    - Esse projeto está avançando bem ou está atrasado?
  - Performance do sistema
    - Os sistemas de engenharia são rápidos e estáveis?
    - A infraestrutura é segura e bem mantida?
    - Os usuários estão satisfeitos com os serviços que usam?
  - Eficiência de engenharia
Misturar métricas qualitativas e quantitativas é algo comum em todas as empresas
- Vale se inspirar nas diferentes medições usadas por cada empresa
- Há grandes diferenças nos itens priorizados por cada empresa para medição, de acordo com suas prioridades e cultura de engenharia

1 comentários

demorier 2024-01-24

Eu já vinha me interessando por isso desde o post anterior sobre a McKinsey, então foi bom ter um resumo e um lembrete.