Eu tinha que fazer alguma coisa.
Os engenheiros de software eram cegos após o ambiente de desenvolvimento. As equipes de produção lutavam com incidentes sem conhecimento dos aplicativos.
Os gerentes de versão foram pressionados a implantar alterações de software como batatas quentes para a próxima etapa, sem deixar tempo para revisão, muito menos para testes.
Não era mais tolerável.
Todos ficaram frustrados, inclusive os mais importantes: nossos utilizadores.
A iniciativa foi liderada na La Redoute, uma e-commerce pure-player com $1b que renasceu das cinzas várias vezes, agora em crescimento acelerado.
Eu estava liderando uma equipe de engenharia de back-end com mais de 70 pessoas quando decidi focar a equipe em um objetivo comum: o pipeline de entrega.
Este artigo compartilha uma experiência concreta de evolução de uma organização existente para entregar Quality Engineering.
Segue a QE Unit para mais conteúdo de Quality Engineering da comunidade.
Crie um senso de urgência em um objetivo comum simples
A simplicidade permite o foco. A primeira coisa foi reunir os atores em um objetivo comum, criando um senso de urgência.
Procurei primeiro por fatos internos, como incidentes recentes com impactos no cliente, tempo de resolução lento, mostrando vazamentos factuais nos processos.
Um benchmark externo usando Accelerate complementou a abordagem para demonstrar nossa diferença em relação a um padrão de mercado conhecido, impactando igualmente os negócios.
Com todos os lançamentos a chegarem, tivemos que mudar.
Metodologias de foco nos fatores limitantes
Decidi focar a equipe no pipeline sendo um fator limitante que acumulava muita dívida organizacional e técnica.
A mensagem era entregar Quality at Speed sem depender de um novo projeto técnico, seguindo estes princípios:
- Medir o resultado do negócio;
- Entregar pelo menos uma vez por dia;
- Entregue com estabilidade, ou recupere rápido.
A restrição da entrega diária gerou a maioria das reclamações: “Não é possível com etapas manuais”, “É muito arriscado hoje”, “O negócio não pode testar todos os dias”.
De fato, esses problemas eram os que deviam ser resolvidos.
Eu então estabeleci dois conjuntos principais de metodologias a serem implementadas:
- Lean software factory
- Pipeline standard de CI/CD;
- Trunk-based desenvolvimento mantendo Merge Request.
- Automação de testes (mínimo unitário, funcional, integração).
- Lean software measurement
- Pipeline de observabilidade;
- Métricas de negócios;
- Métricas do Accelerate.
Só então, chegou a hora de falar sobre tecnologia.
Use a arquitetura para sustentar processos sistemáticos
A fábrica de software que construímos tinha pipelines de CI/CD em todos os ambientes, mas estava aquém do fluxo, segurança e design de teste.
Os engenheiros de software não tinham acesso para implantar após o primeiro ambiente de teste; os ambientes restantes foram reservados à equipe operacional devido aos processos legados.
Acredito que a autonomia faz a diferença.
As funções foram distribuídas para permitir que os desenvolvedores iteram até a produção, mantendo as etapas de aprovação para o negócio ou líder de equipe para requisitos de auditoria.
O próximo passo foi aumentar os requisitos de teste de portões de qualidade com:
- Tempo máximo de construção para tempo de ciclo rápido e testes unitários mínimos;
- Número mínimo de testes funcionais para garantir a sua presença;
- Verificações sistemáticas de sanidade pré e pós-implantação para feedback rápido.
Em seguida, passamos para as medições de software Lean, começando por “Medir o resultado do negócio”.
Use a tecnologia para dar suporte aos resultados de negócios
A equipe de operações realizou a maior parte do monitoramento com painéis técnicos e orientados à infraestrutura.
As métricas de negócios empurraram os desenvolvedores para os impactos nos negócios fora de seu ambiente de desenvolvimento‒e o pessoal de operações começou a olhar para a mesma coisa.
A medição do “Entregue com estabilidade, recupere rapidamente” foi medida com métricas de aceleração em painéis padrão.
Contei com um engenheiro motivado para construir um painel de observabilidade simples, mas padrão, com várias métricas.
Era então hora de conduzir essas mudanças.
Conduza a equipe com responsabilidade pelos resultados
Da engenharia às operações, as equipes precisavam de segurança psicológica para se tornarem verdadeiras unidades de Quality Engineering.
Eu assumi total responsabilidade se algo desse errado, quaisquer que fossem os problemas de engenharia (minha equipe), produção ou qualquer outra coisa.
“A falha era aceitável, mas a falha na melhoria contínua não.”
Antoine Craske
Também esclarecemos com os líderes da equipe que o poder de iterar até a produção vem com a responsabilidade de garantir as operações.
O próximo requisito era definir o ritmo.
Defina o ritmo com marcos mínimos
As equipes tiveram 90 dias para melhorar seu desempenho, alinhando o status e os planos de ação em uma reunião semanal de 30 minutos.
O escopo definido dos componentes de software foi avaliado em sua prontidão de arquitetura e avaliação de desempenho, tanto em métricas de negócios quanto aceleradas.
Objetivo simples, pergunta simples: “Está agora a entregar diariamente?”
Usamos painéis de negócios para vincular as saídas aos resultados, garantindo que os aplicativos tivessem as métricas disponíveis e com índices de monitoramento.
Nossa abordagem enxuta permitiu resultados mais rápidos.
Aceitamos a troca de não ter tudo o que queríamos – não estávamos medindo o change fail rate– o tempo de espera, o ciclo e a estabilidade foram suficientes.
As conquistas de resultados possibilitaram vitórias antecipadas para comemorar com a equipe; primeiro em pequenos grupos, depois dentro da organização.
Os embaixadores eram uma forma de influenciar a organização em evolução.
Alinhar a estrutura organizacional para interações valiosas
A estrutura organizacional impulsiona as fontes de poder. As mudanças são necessárias para ter sucesso após as primeiras vitórias com o modelo existente.
De antemão, o poder era claramente para as equipes de operações responsáveis pela produção, criando gargalos no fluxo de mudanças de software.
A adaptação da organização concentrou-se em uma colaboração mínima viável:
- Equipe, componentes e fluxos orientados ao domínio;
- Gerenciamento de liberação central a descentralizado;
- Automação com autoatendimento e APIs.
As mensagens visuais também são importantes. Veja abaixo as equipes de software entrando em produção com as equipes de plataforma e infraestrutura de suporte.
Uma empresa tem dinheiro limitado. Alterar uma estrutura organizacional requer escolher entre recursos dedicados ou compartilhados:
- Dedicado para equipes alinhadas ao fluxo por domínio, exigindo iteração rápida sem transferências e onde o tempo ocioso suporta velocidade;
- Compartilhado para equipes menores, fornecendo componentes reutilizáveis para outras equipes ou isolando uma complexidade específica (por exemplo, middleware, DBA).
Como parte dessas mudanças, também afetamos claramente um engenheiro de garantia de qualidade e um contato de suporte da plataforma para cada equipe.
A próxima etapa foi medir os fluxos da estrutura organizacional.
Alinhar a organização aos fluxos de sistema desejados
As implantações diárias definem uma restrição para agilizar as atividades necessárias para atingir um objetivo específico.
O value stream foi essencial para remover os fatores limitantes, focando na experiência do desenvolvedor para alcançar mudanças rápidas e estáveis.
A responsabilidade da experiência do desenvolvedor foi definida entre a equipe da plataforma para fornecer os meios necessários e os líderes da equipe para melhorar continuamente.
Estabeleci um objetivo global da equipe para entrega diária, esclarecendo a prioridade compartilhada. Além disso, estabeleço Quality at Speed em objetivos individuais de engenharia.
O alinhamento de incentivos do sistema é necessário para ampliar as mudanças organizacionais.
Os departamentos de produto e operações não estavam alinhados com esses mesmos objetivos, criando melhorias que limitavam o atrito.
“Aprendizagem: Envolve as partes interessadas desde a fase de ideação.”
Antoine Craske
Tentei sozinho, mas falhei com o sistema anual de RH (infelizmente, não trimestral), não abordando o assunto na hora certa e faltando mais suporte executivo.
O aprendizado: dê um passo atrás e envolva o C-level e outras partes interessadas desde a etapa de idealização.
A mudança é possível aproveitando as habilidades dos atores.
Aproveite as habilidades existentes para alcançar resultados com prazo determinado
As habilidades afetam diretamente a capacidade de mudar as formas de trabalhar nos níveis organizacional, de processo e de tecnologia.
A relação usando soft-skills de empatia, escuta ativa e influência foi essencial para embarcar as pessoas na mudança.
A escuta ativa, a reformulação e o interesse nas anotações e no envio de resumos fazem a diferença na consideração futura.
As hard skills foram valiosas principalmente nos aspectos de design para fluxo de processos confiáveis, orquestração de autoatendimento e tratamento de dados.
Não havia necessidade do último especialista em observabilidade: saiba o que quer construir, procure formas padronizadas e comece com pessoas motivadas.
Agir com curiosidade, perseverança e uma mentalidade de crescimento foi o aspecto mais importante da construção do mecanismo de mudança.
Sim, o Quality Engineering exige que atuemos fora da nossa zona de conforto.
Quality Engineering com foco no pipeline
Após 90 dias, implantamos uma forma replicável de realizar implantações diárias controladas no perímetro restante.
Passada a fase de revelação, deixei a liderança da equipe conduzir a expansão mais ampla, permanecendo no suporte e delegando o status e o plano de melhorias.
Voltamos à autonomia; dar às pessoas expectativas claras e apoio para experimentar faz a diferença no desempenho organizacional.
“O elemento essencial foi definir as regras do jogo com medição de negócios, entrega diária e estabilidade operacional.”
Antoine Craske
Este caso é um exemplo de aplicação do Quality Engineering, restringindo todo o ciclo de vida do software à entrega contínua de valor.
Tivemos outras mudanças em andamento, como evolução do modelo de negócios, adaptação da arquitetura funcional à técnica e mudanças organizacionais.
A coisa era ter uma prioridade com marcos de curto e médio prazo, realisticamente alcançáveis em 90 dias com recursos mínimos.
Então, qual é o seu próximo foco no pipeline?
Siga a QE Unit para mais Quality Engineering.