Por que colocamos uma central telefônica na frente de cada endereço web de cliente
A empresa que hospeda os computadores onde nosso site roda mandou um aviso, e uma frase nele nos deixou paralisados. Se uma peça quebrasse, eles não poderiam mais prometer que conseguiriam substituí-la.
As máquinas continuavam funcionando. Os clientes continuavam usando o produto. Nada tinha saído do ar. Mas aquela frase mudou a situação. Não era uma sugestão para arrumar algo velho. Era um aviso de que o relógio já tinha começado a correr, mesmo que ninguém conseguisse ver os ponteiros.
Parte do site roda num jeito mais antigo de construir um site. Isso importa menos do que o fato simples: ele funciona, as pessoas usam, e ele nos ajuda a atender clientes que pagam todos os dias.
A reescrita que já pagamos
A história fácil é que código velho e computadores velhos devem ser trocados juntos. Máquinas novas, software novo, recomeço do zero. Entendemos por que isso parece sensato. Nós já acreditamos nisso.
Na primeira vez em que tratamos uma mudança grande como chance de reconstruir tudo, as coisas não saíram como esperávamos. O trabalho, que antes andava rápido, caiu para cerca de um terço do seu melhor ritmo. Ficou assim por três anos. A versão do futuro continuava sendo construída enquanto o produto atual mancava. A empresa encolheu durante esses três anos.
Foi um projeto incômodo, e também uma conta paga em doze trimestres de trabalho mais lento e oportunidades perdidas. De que adianta uma cozinha nova e reluzente se você passa três anos sem conseguir fazer o jantar enquanto ela é construída?
Dois problemas com o mesmo casaco
Então separamos dois problemas que tentavam usar o mesmo casaco. Um era urgente: as máquinas antigas podiam falhar e talvez não existisse peça de reposição. O outro era opcional: saber se o código antigo do site deveria ser reconstruído. Um tinha um prazo ditado por metal e eletricidade. O outro devia ser julgado pelo retorno que realmente traria.
A central telefônica
O primeiro passo foi colocar os endereços web públicos atrás de uma espécie de central telefônica. Pense nisso como manter a mesma porta da frente, mas trocar o cômodo que fica atrás dela. Os clientes continuam acessando o endereço que já conhecem. Mais tarde, a central pode direcioná-los para as máquinas novas sem pedir que mudem nada.
A ideia foi fácil de explicar, mas o trabalho levou meses, porque muitos desses endereços web são controlados pelos próprios clientes. Era preciso cuidar de poucos de cada vez. Foi um trabalho lento e comum, e foi ele que tornou a mudança final mais segura. Não precisamos de e-mail em massa. Ninguém teve que atualizar um favorito ou aprender um endereço novo.
A mudança em si ainda não aconteceu. As máquinas antigas continuam no trabalho, e o aviso continua valendo. Mas a parte mais assustadora ficou menor. Quando chegar a hora, as informações dos clientes e o site poderão ir para as máquinas novas, e então a central será apontada para elas. Do lado do cliente, a porta da frente continua onde sempre esteve.
Mantendo o trabalho que paga em andamento
Enquanto isso, as versões do produto continuaram saindo. Isso importa tanto quanto a mudança em si. Usamos ferramentas de IA, software que ajuda a manter várias tarefas pequenas andando ao mesmo tempo, para que o trabalho lento e cuidadoso continue sem engolir o trabalho que paga as contas. Cinco anos atrás, um problema urgente nas máquinas e o trabalho diário no produto pareceriam uma escolha cruel entre duas coisas importantes. Hoje, parte disso é um problema de agenda.
Isso não quer dizer que o computador faz o julgamento. Ele pode ajudar a manter uma lista andando. Não pode decidir se uma reescrita vale três anos de trabalho mais lento, nem se os clientes devem arcar com o risco de uma mudança apressada. Essas decisões são nossas, porque o custo recai sobre pessoas.
O que entrou na lista
Anotamos só o que as máquinas antigas exigiam. Mover a porta da frente pública. Preparar as máquinas novas. Manter qualquer transtorno para o cliente fora do plano. Todo o resto tinha que provar que merecia estar ali. Uma reescrita não podia pegar emprestada a urgência de uma peça de hardware falhando só porque parecia progresso.
Nada disso vai virar manchete no dia em que as máquinas finalmente forem trocadas, porque o objetivo é justamente que os clientes nunca notem que a porta da frente mudou. O problema urgente foi resolvido meses antes de o hardware nos forçar a isso, e a pergunta sobre a reescrita continua intocada, esperando para defender o próprio caso. Uma reescrita é julgada pelo seu próprio retorno, e a que tentamos antes custou três anos de trabalho mais lento.