Hydrolix assume contas de dados de registro altíssimas
10 de junho de 2024
Como dimensionar o RAG e construir LLMs mais precisos
11 de junho de 2024
NOTA DO EDITOR: O autor também contribui regularmente com artigos não patrocinados para The New Stack.
A lição de Yoda: “Faça ou não. Não há tentativa” realmente não funciona para a produtividade e experiência do desenvolvedor.
A engenharia é uma ciência que só pode ser melhorada através da experimentação. Você deve medir, idealizar, experimentar e medir novamente. As métricas de produtividade do desenvolvedor isoladamente são inúteis sem um plano de ação.
“É uma intenção baseada em métricas”, disse Diogo Correia, gerente de produto de experiência de desenvolvedor da Pipedrive, ao The New Stack. Ao aplicar essa estratégia de experiência do desenvolvedor (DevEx) em toda a sua organização, afirma ele, você promove a melhoria contínua.
Veja como o Pipedrive funciona para conseguir exatamente isso.
Invista em desenvolvedores
Em 2020, a Pipedrive buscou elevar sua estratégia de engenharia de plataforma e descobriu que precisava de um gerente de produto para atender às expectativas dos desenvolvedores ao adotar a plataforma como mentalidade de produto.
“Houve um aumento da insatisfação dos nossos promotores em termos das ferramentas que oferecíamos”, disse Correia, “e em particular com a qualidade do nosso ambiente de desenvolvimento local”.
À medida que a empresa estoniana de software como serviço (SaaS) escalava para centenas de microsserviços e centenas de implantações por dia, o ambiente de desenvolvimento local simplesmente não conseguia lidar com a complexidade crescente. Eles precisavam de mais do que apenas ferramentas e bibliotecas. “Como não havia ninguém que realmente visse quais eram as necessidades das equipas e construísse aquelas bibliotecas comuns, começaram a reinventar coisas diferentes” e a construir soluções ad-hoc para lidar com os problemas, explicou Correia.
A liderança de engenharia precisava identificar o que estava funcionando e construir caminhos dourados que ajudassem a orientar os desenvolvedores na direção certa.
“Havia a necessidade de alguém cuidar da produtividade da engenharia (e) da experiência em engenharia para garantir que as coisas fossem muito fáceis”, disse ele. Assim, ele foi promovido de engenheiro principal a gerente de produto DevEx. É seu trabalho ter uma visão geral, entrevistar os desenvolvedores, medir o impacto e planejar.
Inicialmente, ele entrevistou desenvolvedores individuais para descobrir e resolver problemas conhecidos — como reconstruir completamente o ambiente de desenvolvimento, padronizar bibliotecas e melhorar o pipeline de CI/CD.
Isso funcionou bem, mas eles chegaram a um ponto em que não conseguiam descobrir o que restava para consertar.
Dimensione as métricas de produtividade do desenvolvedor após a entrevista
Em 2022, decidiram que era altura de olhar para os processos de melhoria contínua dentro das equipas “para lhes fornecer os dados e ferramentas para evidenciar os problemas e depois trabalhar neles”, disse Correia.
O Pipedrive começou a testar a plataforma de insights do desenvolvedor DX para os aspectos menos facilmente mensuráveis da experiência do desenvolvedor. O DX foi implementado em toda a organização em março de 2023.
Embora ele já tenha realizado pesquisas com desenvolvedores antes, “elaborar as perguntas certas é muito difícil”, disse ele. Então é especialmente desafiador visualizar os resultados “e colocá-los de uma forma que facilite o uso pelos desenvolvedores ou pelas equipes”.
DX usa uma combinação de questões baseadas em pesquisas extraídas de métricas DevEx, da estrutura SPACE e outras métricas qualitativas. Mas não se trata apenas de fazer as perguntas certas; é fazer com que os desenvolvedores respondam a eles.
“Normalmente, o problema com uma pesquisa criada manualmente é que preciso enviar ping constantemente aos desenvolvedores para preenchê-la e, em seguida, preciso processar os dados. E depois há um enorme atraso entre os dados se tornarem acionáveis”, disse Correia.
O DX envia ping aos desenvolvedores diariamente até que eles preencham a pesquisa e, em seguida, gera um relatório em uma semana. Mas o relatório não é só para ele. “Esse relatório é totalmente transparente para os desenvolvedores”, disse ele, “e eles têm acesso imediato a ele, tanto acesso quanto eu ou como liderança de engenharia”. Isso gera confiança para os desenvolvedores, que estão mais dispostos a responder à próxima pesquisa.
Mantendo uma taxa de participação de 95% na primeira semana de cada pesquisa trimestral DevEx 360, Correia disse que isso “confirma que os desenvolvedores aqui continuam a ver o valor dessas pesquisas e estão felizes em interagir com elas”.
Quando o Pipedrive lançou as pesquisas trimestrais em abril de 2023, elas estavam abaixo do percentil 50 em relação aos padrões do setor. Se a tendência continuar, eles estarão no percentil 90 15 meses depois.
O Pipedrive usa o Índice de Experiência do Desenvolvedor da DX, uma métrica abrangente que permite às organizações comparar sua experiência de desenvolvedor com os padrões do setor. Os recursos de benchmarking do DX permitem que as equipes vejam como elas se comparam a outras pessoas do Pipedrive e de empresas da base de usuários do DX — um forte motivador, disse Correia, para melhoria contínua.
“Começamos há um ano um pouco acima do 50º benchmark da indústria”, disse Correia. “Desde então temos melhorado constantemente. Ultrapassámos o benchmark p75 e estamos no bom caminho para ultrapassar o p90”, o que significa que o seu DevEx deverá em breve estar entre os 10% melhores da indústria.
Aja com um workshop de métricas de produtividade do desenvolvedor
Uma estratégia de experiência do desenvolvedor nunca pode ser apenas sobre os dados, mas sobre as ações planejadas por causa deles.
“Desde que implantamos, estou vendo o impacto dos gerentes de engenharia aproveitando a ferramenta, fazendo workshops dentro das equipes, identificando problemas como lidar com documentação e dívida técnica”, disse Correia.
Correia desenvolveu e abriu um workshop de experiência de desenvolvedor de uma hora para ajudar as equipes a identificar ações com base nas métricas DX, com foco nos três sentimentos mais baixos e nas três prioridades principais, conforme avaliado pelos desenvolvedores. Cada etapa leva cerca de 15 minutos:
- Identifique problemas. Examine as tendências individuais da equipe e compare-as com a média da empresa antes de escrever ideias em post-its.
- Agrupe tópicos semelhantes e depois vote.
- Idealize soluções.
- Esclareça os itens de ação nos quais a equipe deve se concentrar no próximo trimestre.
Para as equipas que fizeram este workshop, disse Correia, “tem um impacto imediato em termos do sentimento e das prioridades que reportam no próximo trimestre”.
Por exemplo, as três principais prioridades de uma equipe eram:
- Eficiência do teste
- Colaboração entre equipes
- Documentação
E seus sentimentos mais baixos foram:
- Experiência de base de código
- Eficiência do teste
- Documentação
“Eles não estão dizendo que se sentem mal com a colaboração entre equipes, mas para eles é importante”, explicou Correia. Por outro lado, a eficiência dos testes e a documentação impactam a experiência do desenvolvedor e são as principais prioridades, que a equipe deve procurar melhorar.
As pesquisas com desenvolvedores da DX capturam as mudanças no sentimento e nas ações com base em subquestões, trimestre após trimestre. Essas métricas de sentimento — chamadas de motivadores — permitem que os desenvolvedores respondam com Ruim, Mais ou menos ou Bom, com base na estrutura SPACE e outras pesquisas sobre produtividade de desenvolvedores. DX também inclui questões de fluxo de trabalho, como: Quanto tempo você normalmente gasta esperando a implantação do seu serviço? Isso permite que as equipes reflitam sobre números “suspeitos”, explicou ele, e depois realizem um workshop para investigar mais a fundo.
Isto permite-lhes melhorar a sua própria experiência de desenvolvimento ao nível da equipa, disse Correia, quer se trate de automação, práticas de documentação negligentes, testes instáveis ou pagamento de dívidas técnicas. Também surgiram problemas anteriormente desconhecidos em toda a empresa, incluindo a velocidade de testes e implementação.
“Com o DX, você fornece essas ferramentas, a evidência desses problemas”, disse ele, e os gerentes de equipe da Pipeline fornecem “o tempo para resolvê-los no trabalho”.
Priorize a dívida técnica de forma inteligente
Com base nos resultados da pesquisa DX 360, os gerentes de produtos de engenharia e não técnicos tiveram que redirecionar parte do foco do lançamento de novos recursos para o pagamento de dívidas técnicas.
“Os desenvolvedores reclamam da dívida técnica, mas a maioria não age proativamente”, disse Correia. Está mais borbulhando no fundo. “É aí que eu entro, onde tento explicar qual é o impacto e tento detalhar a dívida técnica” identificada nos resultados do DX durante os workshops.
Com a combinação dos dados qualitativos e quantitativos recolhidos na DX e nos workshops, podem identificar problemas exatos e ações a tomar e estimar quanto tempo levará para implementá-los.
No momento, diversas equipes de desenvolvimento do Pipedrive estão refatorando e reescrevendo bastante o código, sem deixar de agregar valor aos clientes.
O Pipedrive tem uma organização de 240 engenheiros mais gerentes de engenharia, organizados em 19 equipes de cerca de 14 pessoas cada. Dentro das equipes, a cada dois meses, eles alternam intencionalmente quem se concentra nos recursos e quem trabalha no débito técnico e na manutenção.
Outra mudança é que algumas equipes removeram algumas reuniões de seus calendários, enquanto outras, disse ele, tornaram-se mais intencionais sobre quem é convidado para reuniões ou compartilhando cronogramas com antecedência.
Em toda a organização, as equipes estão reduzindo a dívida técnica refatorando serviços do zero, reescrevendo e otimizando testes e melhorando ou adicionando documentação ausente, entre outras coisas.
“Os workshops ajudam a identificar os serviços ou bibliotecas concretas que uma determinada equipa possui e que incomodam a maioria dos programadores da equipa”, disse Correia. Isso ajuda a equipe a priorizar e planejar a refatoração prontamente, “em vez de sofrer com isso por anos a fio, como antes”.
A prova está na produtividade
Após qualquer workshop, Correia continua a observar uma melhoria no sentimento e um aumento na produtividade dos desenvolvedores ao nível da equipa em DX.
Especificamente, há uma correlação entre as equipes que agem com base nos resultados do DX e na melhoria geral do sentimento da equipe, bem como em seus aspectos, como em torno da base de código. O Pipedrive registrou um aumento de 69% nas pontuações de sentimento dos desenvolvedores devido às melhorias planejadas no ano passado.
Trimestre após trimestre, 13 equipes impulsionaram melhorias nas duas últimas pesquisas. Para uma equipe, “melhorar cronogramas realistas” surgiu como uma prioridade no primeiro trimestre, mas depois de abordada, caiu bastante no próximo. Isto repetiu-se em várias equipas com prioridades variadas – não só o sentimento geral aumentou, como essas ações caíram das três principais prioridades.
O próximo passo de Correia é examinar o que poderia ser replicado e partilhado entre as equipas para melhorar melhor o sentimento geral da organização.
Ele enfatizou: “Não é apenas o aumento dos números da pesquisa – há uma mudança real de sentimento”.
A postagem Métricas de produtividade do desenvolvedor impulsionam a melhoria contínua apareceu pela primeira vez em The New Stack.
