Você gerencia a melhor equipe da empresa: o tempo de ciclo mais rápido, a maior precisão de planejamento e a menor quantidade de retrabalho. Sua equipe tem o menor tempo de revisão, o maior número de implantações semanais e a melhor relação bugs/KLOC. E então alguém de alto escalão encerra seu projeto - o que aconteceu?

O paradoxo da saída

Como desenvolvedor júnior, aprendi que mesclar pequenas alterações com frequência é a chave para agregar valor rapidamente. Como gerente de engenharia júnior, disseram-me que o rastreamento e a otimização de métricas eram vitais para o trabalho do gerente. O primeiro resultado do Google me indicou vários termos e acrônimos, e essas foram minhas primeiras introduções às métricas de desenvolvimento.

As métricas de desenvolvimento são essencialmente um conjunto de métricas que ajudam as equipes de engenharia a rastrear sua velocidade (movimento rápido) e qualidade (sem quebrar as coisas). Diferentes métricas podem ser usadas para medir esses atributos. Tempo de ciclo, contagem de PRs ou problemas fechados acompanham a velocidade. Para rastrear a qualidade, monitore a contagem de defeitos, o tempo médio de resolução ou o número de implementações que causam falha. Cada uma dessas métricas fornecerá informações diferentes sobre o atributo que você inspeciona. Algumas métricas também ajudam na análise de atributos de proxy. Rastreie o retrabalho para analisar a eficiência, que afeta a velocidade. A precisão do planejamento é um bom indicador de previsibilidade, que permite velocidade e qualidade e tem valor por si só.

O problema com todas as métricas acima é que, embora façam um excelente trabalho ao medir a eficiência, geralmente não são suficientes para medir o sucesso. A principal razão é que eles estão totalmente desconectados dos KPIs de negócios (indicadores-chave de desempenho, outro nome sofisticado para métricas). Essa desconexão geralmente leva a uma comunicação ineficaz entre as organizações da empresa, principalmente produto e engenharia. Afinal, a organização do produto (e o restante do negócio) não se preocupa apenas com a velocidade ou a qualidade, já que eles rastreiam a produção . A organização do produto geralmente se preocupa com o resultado - que receita nosso novo recurso produziu? Quantos novos usuários atraímos?

Como um novo gerente de engenharia, isso foi desconcertante para mim. Por um lado, ficou claro que continuar medindo minha equipe com base em métricas de desenvolvimento em vez de métricas de negócios levaria a um desalinhamento com a equipe de produto. Por outro lado, parecia injusto medir minha equipe com base em métricas de negócios: como elas podem afetá-los? É nosso trabalho? Estarei pisando no calo da organização do produto?

Avalie o que importa

Dei um salto de fé e tentei usar métricas de negócios como minha estrela norteadora. Com o passar do tempo, isso levou a melhores resultados.

Primeiro, simplificou a comunicação. é mais fácil para sua contraparte do produto entender por que é essencial priorizar a atualização do banco de dados quando você o coloca em termos de KPI compartilhado que será prejudicado. Só porque está claro para você que, se você não priorizar a atualização do banco de dados, as histórias de usuário a seguir levarão o dobro do tempo e você terá que gastar tempo com manutenção, o que atrasará o lançamento do recurso a um ponto em que você ganhou 'não tem tempo suficiente para atingir a meta de uso que você definiu como KPI, não significa que esteja claro para a contraparte do produto. Quero dizer, isso é muito salto; por que não começar com o que importa? (não, não é a atualização do banco de dados)

Em segundo lugar, medir minha equipe com base em métricas de negócios me fez ver que podemos impactá-los bastante:

• Podemos identificar recursos em que podemos construir 80% do valor do usuário para 20% do esforço. Isso pode liberar recursos para ajudar a mover nossos KPIs ainda mais rapidamente. Para fazer isso, a equipe deve entender claramente os objetivos de negócios, as necessidades do usuário e a motivação para melhorá-los.
• Podemos usar os KPIs para orientar qual dívida de tecnologia devemos acumular: estamos tentando obter nossos primeiros usuários de recursos e a falha de recursos é uma opção? Vamos lançar o mais rápido possível e nos preocupar com dívidas de tecnologia depois. Estamos tentando melhorar a retenção de uma grande base de clientes? Vamos garantir alta qualidade para este.
• Podemos sugerir soluções para pontos problemáticos que o produto nem sabia que poderiam ser solucionados, com base em um novo avanço tecnológico ou em um ângulo de engenharia inovador.
• Podemos (por mais chato que seja) usar os KPIs para entender que não adianta buscar uma solução tecnológica legal específica que queremos implementar porque o problema em si não é crucial para o negócio.

Como medir o sucesso?

Depois de mudar para métricas importantes para os negócios, eu e minha contraparte de produto tivemos que escolher uma estrutura para medi-las. Na Epsagon, usamos a estrutura OKR . Não vou entrar em detalhes, pois existem muitos recursos excelentes para implementar OKRs disponíveis online. A essência é que esta é uma excelente estrutura para organizações de médio a grande porte, geralmente na fase pós-produto-adequação ao mercado. Ele ajuda a alinhar diferentes equipes, grupos e organizações dentro da empresa em direção aos mesmos objetivos orientados a resultados.

Na Epsagon, tínhamos OKRs para cada equipe de produto, e eles eram os objetivos dos engenheiros, do produto e do pessoal de design que compunham a equipe de produto. Uma vez implementado, tivemos uma melhor colaboração entre produto e engenharia. Menos discussão sobre requisitos e mais cooperação para resolver problemas. Também notamos que o aumento da autonomia causado pelo estabelecimento de metas sobre as tarefas aumentou a inovação e a apropriação dos resultados. As equipes definiram o roteiro e as soluções vieram tanto da engenharia quanto do produto.

A desvantagem dessa metodologia é que ela exige algum esforço na implementação e também requer que você seja capaz de estabelecer suas metas ao longo de meses. Isso geralmente é difícil para pequenas empresas iniciantes, especialmente antes do ajuste do mercado do produto. Para os estágios iniciais, não há problema em trabalhar com uma métrica principal e ainda ser conduzido por um objetivo de negócios, mantendo-se ágil o suficiente para alterar suas metas e focar na granularidade de semanas ou dias.

Quer sua equipe seja grande ou pequena, tenha uma missão ou prioridades concorrentes – contanto que você meça o que importa, você terá uma chance maior de sucesso. O “como” é apenas uma otimização.

A comunicação é a chave

Depois de estabelecer os KPIs de negócios, a próxima etapa é seguir em frente. Na minha experiência, há dois aspectos críticos para comunicar e implementar essa mudança. A primeira é a consistência: não basta definir essas métricas e revisitá-las três meses depois para descobrir que erramos. Como líderes, é nosso trabalho monitorar constantemente essas métricas e garantir que seu estado e roteiro para melhorá-las sejam sempre comunicados a toda a nossa equipe.

O segundo aspecto é o comprometimento: é tentador voltar aos velhos hábitos de medir indivíduos usando métricas de desenvolvimento para otimizá-los. Isso enviará a mensagem errada para sua equipe, sugerindo que, embora você diga que se preocupa com os KPIs de negócios, o que realmente importa são as métricas de desenvolvimento. Certifique-se de mudar seus hábitos para refletir suas prioridades: comemore os resultados de negócios, corte recursos não obrigatórios em vez de cumprir prazos e levante bandeiras quando os KPIs de negócios estiverem inativos. Você ainda pode usar métricas de desenvolvimento como indicadores; apenas lembre-se de vinculá-los ao seu efeito nos KPIs de negócios.

As métricas de desenvolvimento estão obsoletas?

Apesar do título de isca de cliques deste artigo, a resposta é não – eles devem apenas ser usados ​​corretamente. Por um lado, as métricas de desenvolvimento são ferramentas poderosas para solucionar problemas de métricas de negócios. Por exemplo, um declínio na retenção de usuários pode ser explicado por um aumento na contagem de defeitos. Nesse caso, você pode usar a métrica dev como um indicador importante: em vez de esperar que a retenção caia, você deve monitorar a contagem de defeitos para evitar que ela caia (semelhante a como você monitoraria o uso da CPU para evitar a contagem de erros de API 5xx de aumentar e causar danos reais aos usuários). Outro caso de uso são as métricas de desenvolvimento como um indicador importante da experiência e satisfação do desenvolvedor (o que, por sua vez, afeta a retenção do desenvolvedor).

No entanto, o importante a lembrar é que você nunca deve otimizar as métricas de desenvolvimento. Você deve sempre otimizar as métricas de negócios e usar a otimização de métricas de desenvolvimento apenas como uma ferramenta para atingir esse objetivo. E, é claro, você só deve definir, rastrear ou otimizar as metas de métricas de desenvolvimento depois de ter uma noção clara do resultado comercial que está tentando alcançar e dos KPIs comerciais que está tentando atingir. Grandes estatísticas de engenharia não salvarão seu projeto se ele não tiver valor.

Qual é o próximo?

Se você estiver liderando uma organização de engenharia, mudar para a otimização de resultados de negócios em vez de métricas de desenvolvimento aumentará as chances de sua equipe criar um impacto real para os negócios. Se você está empenhado em se tornar um líder orientado a resultados, recomendo que se faça as seguintes perguntas:

• Eu sei quais resultados de negócios são esperados de mim?
• Estou fazendo tudo o que posso para otimizar esses resultados?
• Como estou acompanhando o sucesso? Quais são os critérios para levantar uma bandeira ou mudar meus planos?
• Minha equipe está ciente das metas de negócios e do roteiro para alcançá-las? Qual é a opinião deles sobre isso?
• Quais dos meus KPIs de negócios podem ser aprimorados ao melhorar quais métricas de desenvolvimento?