O que é go-live: significado, go/no-go e plano da virada

Go-live é o momento em que a entrega do projeto passa a ser usada de verdade: o sistema entra em produção e os usuários reais começam a trabalhar nele, a loja nova abre as portas, o processo novo substitui o antigo. Em português, o termo aparece também como entrada em produção, entrada em operação ou simplesmente virada.

É um marco do cronograma, mas não um marco qualquer. Até o go-live, os problemas aparecem em ambiente de teste, com usuários que sabem que estão testando. A partir dele, cada falha atinge clientes, faturamento ou a rotina de quem depende da entrega. Por isso o go-live pede uma decisão formal, um plano para o dia e um plano para voltar atrás.

Este artigo trata de como conduzir esse momento, da decisão de seguir até os primeiros dias de uso.

Go-live, deploy, lançamento e soft launch

Os termos se misturam no dia a dia, mas não são a mesma coisa:

Um projeto pode ter dezenas de deploys e um único go-live. E o go-live pode acontecer sem lançamento nenhum, como na troca de um sistema interno, que só os funcionários percebem.

A decisão de go/no-go

Antes da virada, quem tem autoridade decide se ela acontece na data marcada. Essa decisão costuma ser tomada numa reunião curta, chamada de go/no-go, que compara a situação real com critérios combinados semanas antes. Critérios definidos na véspera tendem a ser ajustados para caber na data, e aí a reunião perde a função.

Critérios comuns de go/no-go:

• Testes de aceitação aprovados pelos usuários que vão operar a entrega, com os defeitos pendentes classificados e nenhum impeditivo em aberto.
• Dados migrados e conferidos, por amostragem ou por reconciliação de totais com o sistema antigo.
• Pessoas treinadas e com acesso liberado no ambiente real.
• Suporte preparado: quem atende, em que horário, por qual canal e com que prazo de resposta.
• Plano de retorno ensaiado, com responsável e horário-limite para a decisão de voltar.
• Comunicação pronta para usuários, clientes e áreas afetadas.

O resultado da reunião é uma de três respostas: segue na data, segue com condições registradas, ou adia com nova data e o que precisa mudar até lá. Adiar não é fracasso. Fracasso é virar sabendo que um critério importante não foi atendido e descobrir o problema com o usuário real.

Tipos de virada

A forma de colocar a entrega em operação muda o risco do go-live:

• Big bang: todos passam para a entrega nova ao mesmo tempo. É mais simples de coordenar, mas concentra o risco num único momento.
• Em fases: a entrega entra por partes, por módulo, unidade ou região. Cada fase ensina algo para a seguinte, e o projeto fica mais longo.
• Em paralelo: o sistema antigo e o novo funcionam juntos por um período, e os resultados são comparados. Reduz o risco, mas dobra o trabalho de quem opera.
• Piloto: um grupo pequeno usa a entrega primeiro, e os demais entram depois de corrigidos os problemas encontrados.

A escolha depende do custo de uma falha. Uma folha de pagamento pede mais cautela que a troca da ferramenta interna de reserva de salas.

O plano de go-live: antes, durante e depois

Antes. Monte um roteiro da virada com cada passo, o responsável, o horário previsto e como confirmar que o passo deu certo. Ensaie o roteiro inteiro pelo menos uma vez em ambiente de teste, inclusive a volta atrás. Combine a janela da virada com as áreas afetadas, de preferência num período de menor movimento.

Durante. Siga o roteiro e registre o horário real de cada passo. Mantenha uma sala de controle, presencial ou virtual, com quem decide, quem executa e quem fala com os usuários. Defina antes o critério de retorno: em que situação a implantação será desfeita e até que horário essa decisão pode ser tomada. Decidir isso no calor do momento costuma levar a insistir além do razoável.

Depois. Os primeiros dias pedem acompanhamento próximo, o período que muitas empresas chamam de hypercare: suporte reforçado, reunião diária curta para revisar os problemas abertos e critérios claros para devolver a operação à equipe permanente. Só depois disso o projeto segue para o encerramento, com aceite formal e lições aprendidas.

A lista de verificação de go-live da Projeto Diário reúne esses itens num checklist para conferir antes da virada.

As pessoas no go-live

A virada técnica pode dar certo e o go-live fracassar mesmo assim, porque as pessoas continuam trabalhando do jeito antigo. Treinamento na véspera, comunicação clara sobre o que muda e um canal fácil para dúvidas pesam tanto quanto o roteiro técnico. O artigo sobre gestão de mudanças em projetos trata dessa parte, e o guia para preparar a equipe para o go-live detalha o que fazer com o time nas semanas anteriores.

Em implantações de sistemas para clientes, o go-live também não encerra a relação: o cliente só considera o projeto bem-sucedido quando usa o sistema e obtém o resultado combinado, como mostra o artigo sobre implementação de software B2B.

Erros comuns

• Data de go-live tratada como promessa intocável. Quando a data não pode mudar, os critérios de go/no-go viram formalidade.
• Plano de retorno que nunca foi testado. Voltar atrás costuma ser mais difícil do que parece, principalmente quando dados novos já foram gravados no sistema.
• Equipe do projeto desmobilizada no dia seguinte. Os problemas mais difíceis aparecem nos primeiros dias de uso real.
• Comunicação só para a área técnica. Usuários que não sabem o que muda abrem chamados que não são defeitos e ocupam o suporte.
• Virada no fim do dia anterior a um feriado. Se algo der errado, falta gente para resolver.

Resumo

Go-live é a entrada em uso real da entrega do projeto. Ele pede critérios de go/no-go combinados com antecedência, um roteiro ensaiado, um plano de retorno com horário-limite e acompanhamento reforçado nos primeiros dias. Com essas peças, a virada deixa de ser um salto no escuro e vira um marco planejado do cronograma do projeto.