Alison Polton-Simon é uma engenheira de software na ThoughtWorks e ex-membro da equipe de GoCD Analytics, onde esteve envolvida em auxiliar desenvolvedores, atores de negócios e operações realizando melhores decisões dirigidas a dados.
Polton-Simon palestrou sobre 'Metrics That Matter' (Métricas que importam) na DevOpsDays NZ em Outubro, onde compartilhou seus insights sobre métricas chave que provaram ser mais efetivas nas organizações ajudando-as a entender e melhorar seus processos de entrega contínua.
O InfoQ convidou Polton-Simon para uma sondada em suas atuais área de interesse e métricas que ela recomenda começarmos a medir.
InfoQ: Pode, por favor, nos dizer qual seu papel atual e quais suas área de interesse sobre DevOps?
Alison Polton-Simon: Atualmente trabalho como engenheira de software na ThoughtWorks, uma consultoria de software global. Nos últimos 5 meses, tenho trabalhado em uma equipe para migrar uma aplicação de monitoramento de performance de uma companhia para uma nova infraestrutura construída. Portar uma base de código monolítica e construir um sistema sobre repositórios mais independentes tem sido uma grande oportunidade de desenhar um novo sistema de baixo pra cima, com a vantagem de já entender muitos dos mais complicados casos de ruptura.
Em termos de práticas e tecnologias, estou bastante animada com a crescente tendência de Infraestrutura como Código (Infrastructure as Code). Nesse projeto, configuramos todos nossos fluxos com um DSL, que nos permitiu colher os benefícios de leitura e reusabilidade comumente encontrados em desenvolvimento tradicional de software. Também alocamos em contêineres a maioria de nossos serviços de construção (build agents), o que nos permitiu assegurar ambientes de construção mais confiáveis e disponibilizar aos desenvolvedores formas fáceis de configurar ambientes locais de teste mais consistentes com os ambientes dos servidores.
Como nossos clientes são os desenvolvedores com quem trabalhamos diariamente, consigo ouvir diretamente quão impactante essas mudanças foram, o que é extremamente gratificante.
InfoQ: Sua palestra no DevOpsDays NZ tem o título de 'Metrics That Matter' (Métricas que importam). Pode falar um pouco sobre essa palestra e como escolheu esse conjunto específico de medidas?
Polton-Simon: Antes de meu projeto atual, trabalhei em uma oferta para o servidor de entrega contínua de GoCD da ThoughtWorks. Nosso objetivo era desenvolver um servidor de análises que fornecesse às equipes grandes inspirações em como poderiam melhorar seus processos de construção (build) e entrega (delivery). Como era uma oferta inédita, começamos conversando com um grupo de praticantes de entrega contínua e consultores sobre as métricas que achavam valiosas para entender seus progressos. A palestra foi uma síntese dos temas e armadilhas comuns quando conduzimos essas entrevistas.
InfoQ: Quais tipos de métricas deveríamos estar observando?
Polton-Simon: O objetivo principal de uma equipe de desenvolvimento de software deve ser constantemente entregar valor aos clientes. Independente de seus papéis, todos já tiveram experiências frustradas com alguma ineficiência no processo do dia a dia.
Para desenvolvedores isto é visto como longos ciclos entre um commit e um build bem sucedido.
Para os indivíduos de DevOps, os desafios podem aparecer quando publicamos uma aplicação. As métricas que escolhemos - medidas como tempo de ciclo e tempo médio para recuperação - quantificam esses pontos críticos, e possibilitam equipes a seguir e entender seu crescimento.
InfoQ: Em que medida o valor dessas métricas é afetado pelo contexto local das equipes que as coletam?
Polton-Simon: Visamos selecionar as métricas que atendam preocupações universais na área de desenvolvimento de software, e sentimos relevante por todos os membros da equipe. No entanto, não podemos dizer que o contexto local é irrelevante.
Uma das formas mais significativas em que o contexto local pode impactar no valor dessas métricas é quando elas começam a ser coletadas em um ambiente onde há pouca credibilidade em suas validades, ou nos indivíduos ou grupos coletando-as e analisando-as.
Métricas consideradas essenciais por uma equipe, que as identificaram como pessoalmente relevantes, ou creditadas pela liderança da organização, podem ser tratadas como sem sentido ou tóxicas por outras equipes.
Tomando um exemplo clássico, equipes que identificam velocidade como pessoalmente relevante podem refletir cada retrospectiva em como eles podem melhorar suas taxas de entrega, enquanto outras que consideram essa métrica irrelevante podem simplesmente tentar inflar as estimativas para criar um aumento de velocidade aparente.
Dado o potencial das abordagens dirigidas a métricas a inspirar medo ou esquemas de jogos no sistema, é importante investir energia ao estabelecer confiança e uma missão comum durante os primeiros estágios de uma nova iniciativa.
InfoQ: Como fazer abordagens mais tradicionais, como top-down, KPIs e métricas de nível organizacional se enquadrarem nesse cenário?
Polton-Simon: Métricas no nível das equipes devem ser construídas em alinhamento com os objetivos da empresa e seus KPIs. Indivíduos e organizações com métricas conflitantes cairão na tensão de iniciativas competindo entre si. KPIs organizacionais devem prover um alto nível de direção para as prioridades da empresa, enquanto indicadores no nível das equipes podem ser usadas para guiar esforços diários.
InfoQ: Você já presenciou exemplos de colaboração entre entrega e outras métricas de negócios ao melhorar ao mesmo tempo eficácia local e organizacional?
Polton-Simon: Alinhar métricas locais e organizacionais geralmente é a chave do nosso trabalho de consultoria. Uma ferramenta que achamos promissora para identificar oportunidades de melhorar tanto a eficácia local quanto a organizacional é abordar diversas equipes e mapear seus caminhos individuais para a produção.
Nesse exercício, os passos do processo são anotados com seus respectivos tempos, tempos de espera e pontos críticos. Ao destacar essas três áreas, as equipes podem identificar suas próprias áreas de crescimento locais (por exemplo, testes problemáticos ou muito demorados), assim como áreas de melhorias da eficácia organizacional (a falta de colaboração entre equipes pode resultar em muitos retrabalhos por causa de expectativas mal comunicadas).
Equipes e organizações podem identificar seus problemas mais críticos, e identificar ações para encaminhá-las aos respectivos níveis da empresa. Esse exercício facilita o desenvolvimento de um entendimento compartilhado por toda organização, e empodera as equipes a direcionar suas principais preocupações.
InfoQ: Qual sua recomendação para medir indicadores mais subjetivos ou qualitativos de sucesso, como satisfação ou experiência do cliente?
Polton-Simon: Acredito que há duas formas complementares de lidar com esses tipos de indicadores. Uma é usar a abordagem tradicional, como Net Promoter Score que pede aos usuários uma avaliação do quanto estão dispostos a recomendar um produto ou serviço em particular a um amigo, e é uma prática com longo legado nos negócios.
A outra é usar uma abordagem menos tradicional, e/ou mais qualitativa, para entender a performance de sua organização. O ponto importante é tecer essas segunda abordagem aos valores da companhia.
Um exemplo rápido que me impressionou é o da Zappos, que se orgulha de seu excelente atendimento ao consumidor e comemora por longas chamadas do suporte quando estas atendem totalmente às necessidades do cliente. Em um caso bem documentado, um representante do atendimento ao cliente ficou 11 horas no telefone com um cliente, auxiliando-o em uma compra, como também conversando sobre férias e experiências da infância - indo mais e além para causar uma boa impressão ao cliente.
Seguir métricas inovadoras como essas podem ajudar a reforçar o que o distingue de outros competidores.
InfoQ: Pode dividir alguma boa história em que as características da cultura DevOps tenha sido estimulada pelo processo de medir e revisar?
Polton-Simon: Criar mudança cultural é um dos maiores desafios para qualquer organização, mas colaboração pode geralmente crescer ao envolver equipes no processo de identificar o que medir.
Em uma companhia na qual trabalhamos, as equipes raramente se comunicavam, e o extenso conjunto de testes de regressão (levava 14 horas pra rodar) não era confiável, com alguns testes falhando sempre. As pessoas tinham o hábito de ignorar os resultados dos testes e perdido as esperanças de que o fluxo poderia se tornar totalmente verde.
Para abordar esses problemas técnicos e culturais, a equipe da ThoughtWorks realizou uma oficina de três dias para identificar as áreas de maior prioridade para melhorias, e ofereceu às equipes a oportunidade de compartilhar seus processos e maiores dores entre elas.
Na etapa seguinte, as equipes escolheram as mudanças que poderiam iniciar imediatamente para abordar os desafios que tinham identificado. Essas sessões também ofereceram uma oportunidade de colaboração entre as equipes para selecionar um conjunto de métricas de alto nível e identificar áreas de melhoria que superassem os limites das equipes.
Nos meses seguintes, os testes se tornaram verdes, e o tempo de uma alteração ir de um commit à sua publicação foi de 18 dias para 10 dias. Também percebemos um crescente interesse no estado do fluxo de construção (build), e mais comunicação entre as equipes para retorná-lo a um estado saudável na ocorrência de falhas. As equipes continuam identificando novas áreas que podem realizar progressos para reduzir o tempo do commit à publicação.
Dito isso, métricas não são uma bala de prata ou uma panacéia. Colaboração verdadeira e melhoria cultural requer tempo, e um sério investimento em esforço.
InfoQ: Quais recomendações você daria para quem está iniciando essa jornada e que começar a medir?
Polton-Simon: Eu encorajaria os interessados em medir seus progressos a tomar uma abordagem colaborativa e iterativa.
Geralmente quando começamos um projeto novo temos a equipe sem um mapa do processo de entrega de código do commit à produção. Conforme fazemos isso, perguntamos sobre pontos de dor ou áreas de atrito. Para algumas equipes, a maior dor começa cedo, com builds problemáticos e fluxos não confiáveis. Para outras, os problemas aparecem mais tarde no processo, na forma de testes de integração demorados, ou publicações que frequentemente falham.
Uma vez que as equipes têm esses pontos de dor enumerados, elegemos aquele que se mostra mais pesado, determinamos uma forma de quantificá-lo e identificamos alguns experimentos rápidos que podem melhorá-lo.
Eu encorajaria as equipes que querem iniciar medições a procurar processos similares. Também encorajaria a se sentirem confortáveis iterando - se pegarmos uma métrica e após algumas sprints ela não parece mais relevante, repetimos o processo e tentamos algo novo.
Melhoria contínua é mais impactante quando usada para abordar seus maiores pontos de dor, e quando há comprometimento genuíno.
O DevOpsDayz NZ aconteceu em Auckland dias 03 e 04 de outubro, onde Alison Polton-Simon e diversos palestrantes locais e internacionais discutiram uma extensa variedade de temas técnicos e culturais.