O que fazer quando um freelancer entrega código quebrado

O que fazer quando um freelancer entrega código quebrado

Código quebrado não é a mesma coisa que um bug comum. Um bug normal aparece em uma funcionalidade que, em geral, funciona; código quebrado pode travar um lançamento, impedir um login ou tornar um arquivo inutilizável já no primeiro dia. Essa diferença importa porque sua próxima atitude deve acompanhar o estrago, não o seu humor, especialmente em situações de como lidar com freelancer que entregou código quebrado.

Comece com uma pergunta: alguém consegue usar isso com segurança? Se a resposta for não, trate como problema de entrega, não como tarefa de polimento. Se a resposta for sim, mas um caminho falha, você provavelmente está lidando com um defeito que ainda precisa ser corrigido. Simples, mas útil, e é exatamente o raciocínio de como lidar com freelancer que entregou código quebrado sem perder tempo.

O que conta como “código quebrado” em vez de um bug comum?

O código quebrado geralmente aparece de 3 formas: trabalho incompleto, trabalho instável ou trabalho que não roda no ambiente combinado. Um botão de formulário que gera erro no envio é um bug. Um fluxo de checkout que nunca chega ao pagamento porque o freelancer pulou a validação, o arquivo de roteamento ou o hook de API obrigatório é código quebrado.

Olhe primeiro para o escopo. Se o freelancer prometeu um construtor de páginas e entregou só o cabeçalho, isso não é um defeito pequeno. Se o freelancer entregou um script que depende de um arquivo nunca mencionado em lugar nenhum, isso também não é um defeito pequeno. O código pode existir, mas a entrega continua quebrada, o que ajuda a entender o que fazer quando o código do freelancer não funciona.

Um teste prático ajuda: é possível avaliar o código em relação ao resultado combinado em menos de 5 minutos? Se você precisar de conhecimento oculto, passos secretos de configuração ou uma explicação privada para fazê-lo funcionar, o problema é maior do que um erro de digitação. É nesse ponto que muitos clientes deveriam revisar suas anotações e, se necessário, comparar o problema com como contratar um freelancer com segurança para o próximo projeto.

O que você deve verificar primeiro antes de entrar em contato com o freelancer?

Reproduza o problema uma vez antes de escrever. Duas vezes é melhor. Use o mesmo navegador, o mesmo dispositivo e a mesma conta, se possível. Anote exatamente no que você clicou, o que aconteceu e onde a falha apareceu. “Não funciona” é vago demais para ajudar alguém, por isso vale definir logo o que fazer quando o código do freelancer não funciona.

Depois, registre o ambiente. Anote o nome e a versão do navegador, o sistema operacional, a URL do servidor e se você usou staging ou produção. Um caminho de código que funciona no Chrome em um laptop pode falhar no Safari em um celular, e essa diferença pode economizar muito vai e volta depois.

Reúna as provas enquanto tudo ainda está fresco: capturas de tela, mensagens do console, logs do servidor, IDs de erro e o horário exato da falha. Se o bug apareceu depois de um deploy, anote o arquivo ou a versão exata que você recebeu. Esses detalhes transformam uma reclamação vaga em um relatório útil, inclusive quando você precisa de como reportar bug para freelancer corrigir rápido.

Não altere três coisas ao mesmo tempo. Se você editar a configuração, substituir o conjunto de dados e reiniciar o serviço, ninguém consegue dizer qual mudança causou a falha. Mantenha um caminho de teste fixo.

Como relatar código quebrado sem transformar isso em uma discussão?

Mantenha a primeira mensagem curta, objetiva e datada. Uma boa estrutura é: 1) o que falhou, 2) onde falhou, 3) o que você esperava, 4) o que você precisa agora. Isso basta para abrir uma conversa de correção sem soar acusatório, e é a base de como reportar bug para freelancer corrigir rápido.

Exemplo: “No site de staging, o formulário de contato retorna um erro 500 após o envio. Eu esperava que o formulário enviasse a mensagem e exibisse uma confirmação. Anexei a captura de tela e o log do console. Por favor, confirme a causa e envie uma correção ou uma versão corrigida.”

Essa redação não deixa espaço para teatro. Também evita a armadilha de culpar o freelancer por intenção, algo que você não pode provar de qualquer forma. Mantenha concreta a frase sobre o impacto: “os clientes não conseguem enviar pedidos”, “o painel administrativo trava” ou “o arquivo exportado está vazio”. Esses detalhes importam mais do que emoções.

Se o projeto envolveu trabalho voltado ao público, a mensagem deve mencionar claramente a consequência. Uma landing page quebrada pode desperdiçar um orçamento de marketing em horas; um checkout quebrado pode custar vendas imediatamente. Ninguém precisa de um parágrafo dramático para entender isso.

Que prova você deve compartilhar para que o freelancer corrija mais rápido?

Envie os passos para reproduzir na ordem, não como uma história. Passo 1: fazer login. Passo 2: abrir o painel. Passo 3: clicar em Exportar. Passo 4: o download falha. Esse tipo de lista permite que o freelancer refaça seu caminho exatamente.

Inclua os dados de teste que dispararam o problema, como uma conta demo, um registro de exemplo ou um nome de arquivo específico. Se o código depender de uma configuração de idioma, de uma extensão do navegador ou de uma variável de ambiente específica, mencione isso. Um detalhe ausente pode desperdiçar uma tarde.

Compartilhe informações de versão sobre o entregável em si. Se você recebeu a “v3”, diga isso. Se o freelancer enviou um patch depois da sua última revisão, diga qual patch. Se houver um repositório privado, inclua o nome da branch e o hash do commit.

Arquivos ajudam, mas só os certos. Uma captura de tela de uma tela em branco é útil. Uma gravação de tela de 4 minutos pode ser ainda melhor se mostrar os cliques e a falha em uma única passada. É aqui que a expressão avaliações de freelancers às vezes se torna relevante, porque um padrão de entregas pouco claras costuma aparecer ali antes de aparecer no código.

Quando você deve pedir uma correção, um rollback ou um reembolso?

Escolha a solução pela gravidade, não pela frustração. Se o bug for pequeno e a base de código ainda estiver utilizável, peça a correção. Se o código quebrado bloquear um lançamento ou corromper dados, um rollback pode ser a medida mais rápida e segura. Se o entregável estiver inutilizável ou for inseguro de reparar, um reembolso passa a ser razoável.

Pergunte uma coisa de forma direta: isso pode ser corrigido sem prejudicar outras partes do projeto? Se a resposta for incerta e o freelancer estiver apenas chutando, fazer rollback pode protegê-lo melhor do que esperar. Um patch ruim pode transformar um módulo quebrado em três módulos quebrados.

Reembolso não deve ser a primeira ameaça na mensagem 1. Ele vem depois de uma revisão clara das evidências e dos termos da entrega. Ainda assim, se o trabalho não puder ser reparado no local, ou se o freelancer admitir que a arquitetura está errada, você deve parar de tratar o arquivo como se estivesse a apenas um passo de ficar pronto.

Há um ponto prático aqui. Se um lançamento está bloqueando receita, cada hora de atraso tem um custo, mesmo que você não calcule isso centavo por centavo. Se o projeto for privado e de baixo risco, a correção pode esperar mais. O contexto importa.

E se o freelancer disser que o código funciona do lado dele?

Não trate essa resposta como uma briga. Trate como uma pista. Em muitos casos, o problema é incompatibilidade de ambiente: uma máquina tem dependências em cache, outra usa uma versão diferente do Node, ou um servidor esconde um arquivo ausente atrás de um passo de configuração local.

Pergunte qual foi exatamente o ambiente usado pelo freelancer. Solicite os números de versão, os passos de instalação e quaisquer etapas manuais que ele seguiu após clonar ou enviar os arquivos. Se ele disser “funcionou localmente”, você precisa da receita local, não de uma garantia. Esse é o ponto.

Às vezes, o código depende de uma suposição silenciosa. O freelancer pode ter presumido que existe uma conta de administrador, ou que um arquivo de configuração já estava presente, ou que o banco de dados já contém um registro inicial. Essas suposições deveriam ter sido documentadas, mas agora a tarefa imediata é expô-las uma por uma.

Mantenha o tom calmo, mesmo que a resposta pareça evasiva. Uma frase como “Por favor, envie os passos exatos de configuração que você usou para eu compará-los com o meu ambiente” já basta. Se o freelancer colaborar, a lacuna muitas vezes se fecha rápido. Se não, você ao menos sabe que o problema já não é apenas técnico.

Quando o código quebrado vira um problema de entrega ou de propriedade?

O código quebrado se torna um problema de entrega quando os arquivos chegam sem os passos necessários para executá-los. Isso inclui notas de instalação ausentes, detalhes de acesso ausentes, arquivos de ambiente ausentes e instruções de deploy ausentes. O código pode estar presente; a posse, não.

Isso acontece com frequência em projetos que dependem de uma equipe, não de uma pessoa. Um desenvolvedor envia um repositório, mas as credenciais do servidor estão em uma mensagem privada. Um designer entrega um tema de site, mas a ferramenta de build nunca é mencionada. Um script de backend roda apenas na máquina do freelancer porque o restante da configuração nunca foi escrito.

Nesse ponto, o problema não é apenas “corrija este bug”. É “minha equipe consegue adotar esse trabalho de fato?” Se a resposta for não, a entrega está incompleta, mesmo que todos os arquivos pareçam organizados. É aqui que as regras de as regras do site 24freelance.pro. freelance podem servir como referência útil sobre como trabalho, arquivos e comunicação devem ser tratados.

Algumas equipes também precisam de uma lista de transferência antes de aceitar o projeto. Uma linha para acesso. Uma linha para hospedagem. Uma linha para credenciais de administrador. Uma linha para a estrutura de pastas. Sem isso, a transferência pode falhar mesmo quando o código em si está correto.

Como evitar o mesmo problema de entrega da próxima vez?

Escreva critérios de aceitação antes de o trabalho começar. Não um parágrafo. Uma lista. “O login funciona com credenciais válidas.” “A exportação gera um CSV com 3 colunas.” “O formulário envia o e-mail e mostra uma mensagem de sucesso.” Essas linhas tornam o código quebrado mais fácil de identificar porque o alvo fica visível.

Peça casos de teste com antecedência, especialmente para recursos com 2 ou mais caminhos. Se o freelancer souber como você vai testar, é mais provável que ele construa para a verificação real, e não para uma imaginária. A revisão em staging também ajuda, porque pega código quebrado antes que alguém o considere finalizado.

Defina “concluído” com uma frase que inclua arquivos, acesso e prova. Por exemplo: “Concluído significa que o código roda no nosso servidor de staging, o README lista os passos de configuração e a conta de teste verifica o fluxo principal.” Essa definição não conserta trabalho ruim, mas torna o trabalho ruim visível mais cedo.

Para tarefas complexas, peça uma breve nota de transferência. Até 5 tópicos podem poupar você depois: ambiente, dependências, limites conhecidos, dados de teste e quem assume o próximo passo. É um pedido pequeno, com grande retorno.

Um último hábito prático: mantenha o chat do projeto e a lista final de arquivos no mesmo lugar. Se o freelancer enviar uma correção por e-mail, mas a nota de deploy estiver no chat e a senha do servidor estiver numa planilha, a transferência fica frágil. Transferências frágeis falham sob pressão.