O desenvolvedor sumiu: como assumir o sistema da sua empresa

Quando o desenvolvedor some, a primeira providência é garantir os acessos (domínio, servidor, banco de dados, repositório do código e contas de serviços ligadas ao sistema) antes de mexer em qualquer coisa. Depois, alguém precisa analisar o código e explicar, em linguagem clara, o estado real do sistema. Só então dá para decidir entre manter, refatorar aos poucos ou reescrever, sem parar a operação.

O que fazer primeiro quando o desenvolvedor some?

O impulso natural é chamar alguém para “arrumar logo” o que está quebrado. O risco é mexer sem saber do que o sistema depende e transformar um problema em dois. A ordem que protege a operação é esta:

1. Não altere o que está funcionando até saber como o sistema é publicado, onde ele roda e quais integrações dependem dele.
2. Tente um contato formal com quem desenvolveu, por escrito, pedindo a entrega do código, dos acessos e de qualquer documentação. Mesmo uma passagem parcial economiza muito trabalho.
3. Levante o que está no nome da empresa e o que está no nome da pessoa: contas, cartões cadastrados, e-mails de recuperação de senha.
4. Reúna o que a equipe sabe: o que o sistema faz, o que costuma dar problema, quem usa cada parte. Esse conhecimento raramente está escrito em algum lugar.

Quais acessos garantir antes de qualquer mudança?

Um sistema de empresa raramente é uma coisa só. Ele depende de várias contas, e cada uma delas pode estar no nome de quem desenvolveu.

Quando tiver o controle das contas, troque as senhas e revogue o acesso de quem saiu. Faça isso com cuidado: chaves de API e senhas costumam estar gravadas na configuração do sistema, e trocá-las sem atualizar o sistema pode derrubar uma integração.

Há também uma razão legal. Se o sistema guarda dados pessoais de clientes, a LGPD chama de controlador quem toma as decisões sobre o tratamento desses dados (art. 5º, VI), papel que em geral é da própria empresa, e de operador quem trata os dados em nome do controlador (art. 5º, VII), como um desenvolvedor ou um serviço de hospedagem. O operador deve seguir as instruções do controlador (art. 39), e os agentes de tratamento devem adotar medidas de segurança para proteger os dados de acessos não autorizados (art. 46). Um ex-fornecedor que ainda tem acesso ao banco de dados é uma situação a resolver o quanto antes. Para o seu caso específico, consulte um advogado, e veja o guia de LGPD em automações e sistemas.

Onde está o código, e de quem ele é?

Com os acessos em mãos, a próxima pergunta é se você tem o código-fonte completo e atualizado. Há três situações comuns:

• O código está num repositório (GitHub, GitLab ou similar), na conta da empresa ou do desenvolvedor. É o melhor cenário, desde que a versão do repositório seja a mesma que está rodando.
• O código está só no servidor. Em algumas tecnologias, como PHP, os arquivos publicados são o próprio código-fonte; em outras, o que está no servidor é uma versão compilada ou empacotada, que não serve para dar manutenção. Mesmo quando dá para recuperar o código, falta o histórico de alterações.
• O código está só no computador de quem desenvolveu. Aqui, a entrega depende da pessoa e do que foi combinado em contrato.

Sobre a titularidade, a Lei do Software (Lei 9.609/1998) diz no art. 4º que, “salvo estipulação em contrário”, pertencem ao empregador ou ao contratante de serviços os direitos sobre o programa desenvolvido durante o contrato, quando o desenvolvimento é a atividade prevista nele. O ponto de partida, portanto, é o que o contrato diz. Ter o direito, porém, não coloca os arquivos nas suas mãos: por isso a entrega do código e dos acessos precisa estar prevista por escrito. Em caso de disputa, quem orienta é um advogado.

Como avaliar o estado real do sistema?

Antes de orçar qualquer correção, alguém precisa ler o código e o ambiente e responder, em linguagem que o gestor entenda:

• o que o sistema faz hoje e quais partes são críticas para a operação;
• em que tecnologias e versões ele foi construído, e se elas ainda recebem atualizações de segurança;
• como uma nova versão é publicada e se existe ambiente de testes;
• se há backup e se alguém já testou restaurá-lo;
• onde estão os pontos frágeis: partes que quebram quando se mexe em outra, lentidão, erros recorrentes;
• o que existe de documentação e o que precisa ser escrito.

O resultado deve ser um diagnóstico que um gestor sem formação técnica consiga ler, com riscos e prioridades, e não uma lista de termos. Ao assumir um sistema feito por outra pessoa ou empresa, a Lutz Solution entrega esse diagnóstico antes do orçamento, inclusive quando a recomendação é reescrever. Veja como funciona a manutenção e evolução de sistemas.

Manter, refatorar ou reescrever: como decidir?

Com o diagnóstico em mãos, há três caminhos:

• Manter: corrigir o que está quebrado, atualizar o que é urgente e documentar. Faz sentido quando o sistema é estável e atende o processo.
• Refatorar: reorganizar o código por partes, sem mudar o que o sistema faz, com a operação rodando. É o caminho indicado quando a base é aproveitável, mas o código ficou difícil de manter.
• Reescrever: construir de novo. Faz sentido quando a tecnologia não tem mais suporte, a base não permite evoluir com segurança ou o processo mudou tanto que o sistema já não o representa.

Reescrever parece a opção mais limpa, mas tem um custo escondido: o sistema antigo carrega regras de negócio que ninguém documentou, como o desconto especial de um cliente ou a exceção do fechamento do mês. Se a decisão for reescrever, levante essas regras antes e mantenha o sistema antigo rodando até o novo provar que faz o mesmo trabalho. Também vale revisar a decisão de base: compare software pronto e sistema sob medida antes de investir numa reescrita.

Como evitar que isso aconteça de novo?

A dependência de uma pessoa não se resolve trocando de fornecedor, e sim com regras que valem para qualquer fornecedor:

• Contas no nome da empresa: domínio, servidor, repositório e serviços de terceiros registrados em nome da empresa, com um e-mail corporativo; o desenvolvedor entra como convidado, com um acesso que pode ser retirado.
• Senhas num cofre da empresa: um gerenciador de senhas compartilhado, e não a memória ou o computador de alguém.
• Documentação mínima: como publicar uma nova versão, onde cada parte roda, quais integrações existem e como restaurar o backup.
• Contrato escrito: o que a sustentação inclui, qual o prazo de resposta, como novas funcionalidades são orçadas e como código, acessos e documentação são entregues se o contrato terminar.
• Backup testado: um backup que nunca foi restaurado é uma suposição, não uma garantia.

Se você está escolhendo quem vai cuidar do sistema daqui para a frente, leve as perguntas do guia como escolher uma empresa de automação e sistemas para a primeira conversa.

Primeiro os acessos, depois o diagnóstico, por último a decisão. Inverter essa ordem é o jeito mais caro de assumir um sistema.