Meu desenvolvedor sumiu: o que fazer agora

Ele parou de responder. A mensagem fica sem resposta, o e-mail também, e o site (ou o sistema que a empresa usa todo dia) continua no ar. Por enquanto. Ninguém sabe dizer por quanto tempo.

Acontece mais do que parece, e quase nunca por má-fé: o programador freelancer arrumou um emprego, a pequena agência fechou, o sobrinho que cuidava do site foi estudar fora. O problema não é o motivo. É descobrir, de uma hora para outra, que a empresa depende de alguém que não está mais lá.

A boa notícia: na maioria dos casos dá para retomar o controle sem perder nada. O que decide é a ordem em que as coisas são feitas.

Primeiro: descubra o que é seu

Antes de qualquer conserto, faça um inventário. São quatro perguntas, e cada “não sei” é um risco:

1. O domínio está no nome da empresa? É o endereço do site. No Brasil, quem registra os endereços .br é o Registro.br: confira quem aparece como titular.
2. Quem é o dono da hospedagem? É onde o site ou o sistema fica guardado. Descubra em nome de quem está a conta e quem paga a fatura.
3. Onde está o código? É o projeto em si. Se ele só existe no computador de quem sumiu, você tem o sistema funcionando, mas não tem como mudá-lo.
4. Existe cópia de segurança dos dados? Cadastro de clientes, pedidos, histórico. Pergunte onde fica e quando foi feita a última.

Não esqueça os acessos que ficam em volta: o e-mail da empresa, o painel administrativo, a conta do Google, a da plataforma de pagamento. Se algum deles foi criado com o e-mail pessoal de quem sumiu, anote. Vai precisar ser transferido.

Onde a retomada costuma dar errado

Com o susto, o impulso é sair trocando tudo no mesmo dia. É exatamente aí que a situação costuma piorar:

• A empresa trancada do lado de fora. Senhas trocadas na ordem errada, com o domínio ou a hospedagem no nome de outra pessoa, e o acesso que restava se perde de vez.
• Mudança sem rede de proteção. Qualquer alteração feita antes de existir uma cópia segura transforma um susto em perda definitiva.
• Portas que continuam abertas. Trocar a senha não fecha todos os acessos, e quem tinha acesso ao sistema pode continuar enxergando os dados dos seus clientes. A LGPD cobra da empresa o cuidado com quem enxerga esses dados.

Retomar o controle é um trabalho de ordem e de cuidado, e vale ser feito por quem já fez antes.

E se o domínio ou a hospedagem estiverem no nome dele?

É o cenário mais delicado, e o mais comum quando o site foi feito “por um conhecido”.

O caminho é pedir a transferência por escrito, com calma e sem acusação: na maioria das vezes a pessoa só não deu prioridade, e resolve em minutos. Se não houver resposta, a questão deixa de ser técnica e passa a ser jurídica. Guarde o contrato, os comprovantes de pagamento e as conversas, e procure a orientação de um advogado.

Enquanto isso, ter uma cópia segura do sistema é o que garante que a empresa não para, aconteça o que acontecer com a conta antiga.

Como saber se o sistema está em risco agora

Sistema sem dono não para de um dia para o outro. Ele vai acumulando sinais:

• ninguém atualiza nada há meses;
• aparece um erro e não tem quem corrija;
• ninguém sabe dizer onde está a cópia de segurança;
• o navegador começa a avisar que o site não é seguro;
• cada mudança pequena vira um projeto, porque ninguém conhece o código.

Se três ou mais itens dessa lista soam familiares, vale agir antes que o problema escolha a hora por você.

Como assumir um sistema herdado sem começar do zero

Assumir o sistema de outra pessoa é diferente de começar um projeto novo, e não deveria começar por “vamos refazer tudo”. Refazer é a opção mais cara e quase nunca a primeira de que você precisa.

O caminho responsável tem três etapas:

1. Diagnóstico. Levantar o que existe: acessos, código, dados, cópias de segurança e o que está quebrado. No fim, você sabe exatamente o que tem nas mãos.
2. Estabilização. Cópia em lugar seguro, acessos no nome da empresa, correção do que é urgente. O sistema volta a ter dono.
3. Documentação. O mínimo para que qualquer profissional competente consiga continuar dali. É o que impede que o problema se repita.

Só depois disso faz sentido discutir melhorias ou, em casos raros, uma reconstrução.

É um trabalho que a Customer faz: já assumimos sites, lojas virtuais e sistemas deixados por outros fornecedores, inclusive lojas que não podiam parar de vender durante a mudança.

Para não acontecer de novo

Quatro regras simples evitam quase todo esse sufoco:

• Tudo no nome da empresa: domínio, hospedagem e contas de serviço, com o e-mail da empresa, nunca o pessoal de quem desenvolve.
• Você sempre com acesso de administrador, mesmo que nunca use.
• Cópia de segurança fora do servidor, automática e testada de vez em quando.
• Alguém que responde. Um sistema que a empresa usa todo dia precisa de quem cuide dele todo mês, não só de quem o construiu um dia.

A última regra é exatamente o que um contrato de sustentação resolve: um time de desenvolvimento contratado, sem contratar ninguém, com a fila de melhorias andando e alguém que atende quando você chama.

Se o seu desenvolvedor sumiu e você não sabe por onde começar, uma conversa de 30 minutos costuma bastar para entender o que é seu e o que está em risco.