Código Amarelo: Quando as operações não são perfeitas

De vez em quando, as equipas de engenharia vão ter problemas por várias razões. Às vezes, o crescimento explosivo apanha a equipa de surpresa. Ou, o tempo de plantão ficou fora de controle, com os alertas disparando a cada cinco minutos. Ou, as equipas de desenvolvimento e operações simplesmente deixaram de estar de acordo. Independentemente do motivo, a equipe está em um ponto ruim e algo precisa ser feito para resolvê-lo.

Se for um novo problema, a correção pode ser fácil: Adicione mais alguns servidores, volte para uma boa versão conhecida da aplicação ou reúna todos em cima de pizza e cervejas para limpar o ar. Muitas vezes, no entanto, o problema se assusta com o tempo e, de repente, o buraco é tão profundo que você não consegue encontrar a saída. No LinkedIn, uma equipe que chegou a este ponto frequentemente declarará um estado conhecido como “Código Amarelo”

Alerta Amarelo

Algumas pessoas assumem que o nome Código Amarelo é baseado em semáforos, mas mais precisamente – e com um twist- é na verdade da sua série favorita “Star Trek”. Mais precisamente, é como a tripulação da Nave Estelar Enterprise indica a sua condição defensiva actual. De qualquer forma, a definição é clara: algo está errado, e precisamos avançar com cautela. Fiel às duas metáforas, também temos um Código Vermelho. Isso é melhor descrito como uma crise imediata, com todos trabalhando 24 horas por dia até que seja resolvido. O Código Amarelo é um pouco mais descontraído: Este é o foco principal de todos, mas apenas durante o horário de trabalho. O Código Amarelo também tende a durar na ordem dos meses, enquanto um Código Vermelho deve durar na ordem dos dias.

Outras empresas podem usar um termo diferente do Código Amarelo, mas o efeito é o mesmo: A equipe está comunicando ao resto da empresa que identificaram um problema grave que é uma prioridade a ser corrigida para garantir o sucesso da equipe e, portanto, da empresa. A capacidade de fazer isso é um aspecto importante da comunicação aberta e honesta, um valor que é crítico para uma cultura saudável e que muitas vezes pode ser negligenciado. Falar dos nossos problemas é igualmente importante, se não mais, do que celebrar os nossos sucessos. As equipes podem aprender mais com a correção de um problema do que com um sucesso total.

Este não é um fracasso

O primeiro passo para iniciar um Código Amarelo é entender que isto não é um fracasso. Não há vergonha em admitir que a equipe tem um problema que precisa ser consertado. Os erros acontecem, apesar dos nossos melhores esforços para evitá-los. A única coisa que podemos fazer é diagnosticar o problema e resolvê-lo. A única vez que falhamos é quando fazemos vista grossa a estes problemas. Isto aplica-se tanto à forma como as nossas equipas de engenharia interagem umas com as outras como ao software e sistemas que produzimos e executamos.

É fundamental, no entanto, que os problemas correctos sejam resolvidos. Na maioria das vezes, nós entramos na situação atual por causa de uma lenta e crescente dívida técnica, muitos pequenos problemas ou quebras em um processo – que eventualmente se transformaram em uma crise. O objetivo do Código Amarelo deve ser não só remediar os problemas atuais (um componente reativo), mas também garantir que eles não sejam repetidos no futuro (o componente proativo).

Planejamento para um Código Amarelo de Sucesso

Existem vários componentes necessários para um Código Amarelo de Sucesso, bem como peças necessárias para obter o buy-in do resto da organização:

  • Declaração de Problemas: Deve haver uma declaração clara e concordante dos problemas enfrentados pela equipe que motivaram o Código Amarelo. Isso deve incluir não apenas quais são os problemas atuais, mas também qual é o entendimento atual da causa raiz deles.
  • Critérios de Saída: A seguir, você precisa ter objetivos específicos para os quais a equipe irá trabalhar para sair do Código Amarelo. Estas devem ser metas SMART tradicionais: específicas, mensuráveis, alcançáveis, relevantes e com limite de tempo. Esses objetivos são o que torna possível para a equipe inserir um Código Amarelo em primeiro lugar, pois ele cobre um escopo fixo e não é aberto.
  • Comunicação: Todas as informações sobre o Código Amarelo, incluindo o anúncio (que inclui a declaração do problema e os critérios de saída), a conclusão bem sucedida e atualizações periódicas de status devem ser enviadas para a organização maior. Este pode ser o seu departamento, ou pode ser toda a organização de engenharia. Pode até ser a empresa inteira, dependendo da natureza dos problemas.
  • Gerenciamento de projetos: Como todos os grandes projetos, precisa haver alguém responsável pela organização do trabalho e pela comunicação de informações. Como isso representa um cenário “todas as mãos no convés” para a equipe impactada, geralmente é útil ter um gerente de projeto (PM) dedicado para ajudar com isso. Este é normalmente um PM que conhece bem a equipa e o trabalho, mas não está directamente envolvido na execução. Isto liberta os gestores e colaboradores individuais para se concentrarem no trabalho em questão.

Após cada um destes aspectos ter sido pensado, e a decisão ter sido tomada para introduzir o Código Amarelo, o primeiro acto da equipa é reorganizar as suas prioridades em torno dos critérios de saída. Isto muitas vezes significa colocar metas trimestrais na prateleira. Também pode ser necessário estabelecer uma reunião dedicada em torno da discussão do status do critério de saída.

Espaço para respirar

Está tudo bem e bom para uma equipe entrar no Código Amarelo e trabalhar com um único foco nos objetivos que foram definidos para fazer as coisas certas, mas isso não é suficiente para que a equipe tenha sucesso. Para o verdadeiro sucesso, todos ao redor da equipe devem entender a situação e dar-lhes o espaço para fazer o seu trabalho. Este é o lugar onde uma cultura de engenharia saudável se levanta para enfrentar o desafio.

  • Esperar Atrasos: A forma mais comum de uma equipa tangencial ser afectada é através de atrasos. Eles devem esperar que quaisquer solicitações que tenham sido feitas à equipe impactada possam ser atrasadas se não estiverem dentro do escopo do critério de saída. O Código Amarelo envolve, no seu núcleo, uma reordenação de prioridades para resolver o problema declarado. As equipes externas precisam levar isso em consideração e entender que seus próprios cronogramas de projeto podem precisar ser ajustados.
  • Minimizar Novas Solicitações: Outras equipes também devem se abster de pedir à equipe impactada por coisas novas que estejam fora do escopo do critério de saída definido. Minimizar essas solicitações, além de aceitar atrasos em quaisquer solicitações existentes, permite que a equipe impactada gaste suas horas limitadas de engenharia para chegar ao outro lado do Código Amarelo.
  • Solicitações de Assistência de outras equipes: A equipe em Código Amarelo pode achar que precisa de ajuda externa para alcançar seus objetivos. Por exemplo, se houver um crescimento súbito e explosivo do tráfego, eles podem precisar acelerar o provisionamento de novo hardware. Encontrar-se na extremidade receptora de um pedido como este pode exigir a mudança de suas próprias prioridades. Lembre-se sempre que a equipe faz parte da mesma empresa e, como tal, todos são bem-sucedidos ou falham juntos.

Equipe de engenharia raramente fica sozinha, e é importante que todos entendam o valor de ter essas equipes trabalhando bem, e trabalhando bem juntos. Um pequeno atraso temporário nos objectivos para garantir que este é o caso vale bem a pena.

Luz ao fundo do túnel

Código Amarelo representa uma quantidade significativa de trabalho de alta prioridade e trabalhar através dele será muitas vezes stressante para a equipa. Dizer “não” aos colegas que estão fazendo um pedido razoável é difícil, e o trabalho que está no escopo raramente envolve gastar tempo com novas características interessantes. Além disso, se os problemas que estão sendo tratados incluem questões de comunicação entre grupos, haverá algumas conversas difíceis que precisam acontecer. No entanto, à medida que a equipe se aproxima do fim do trabalho, será muito mais fácil ver o que está do outro lado do critério de saída.

O objetivo final do Código Amarelo é tirar a equipe de um modo reativo onde eles estão correndo de crise em crise e para um estado proativo onde eles são capazes de trabalhar nos grandes projetos certos. Atingir o critério de saída significa que os engenheiros são mais eficazes e capazes de trabalhar proativamente. Isto é uma equipe mais forte – os engenheiros estão mais felizes porque não estão sob uma grande tensão de trabalho operacional, a equipe está trabalhando bem porque estão falando uns com os outros de forma eficaz, e os clientes estão satisfeitos porque os pedidos são tratados através da automação ou em um período de tempo razoável.

A sua empresa tem um processo interno que é semelhante a como o LinkedIn faz um Código Amarelo?

– Todd Palino

Deixe um comentário