Seu app já tem usuários, dados salvos e um comportamento com o qual as pessoas contam. Quando você traz um desenvolvedor para corrigir um bug ou adicionar uma funcionalidade, esses compromissos existentes fazem parte do trabalho.
Começo entendendo o sistema atual e a mudança de que você precisa. Você pode ajudar com um exemplo claro, um mapa dos serviços envolvidos e uma lista do que precisa continuar funcionando. Este guia mostra o que preparar e o que esperar da análise.
Descreva a mudança pelo que o usuário faz
“O app está lento” é um ponto de partida útil. “No celular, a página de pedidos leva vários segundos para abrir quando o cliente tem um histórico longo” nos dá algo para investigar. Para uma funcionalidade nova, descreva o que o usuário deveria conseguir fazer e o que ele consegue fazer hoje.
Para um bug, envie os passos que levam até ele, o que você esperava e o que aconteceu no lugar. Informe o dispositivo ou o navegador se parecer relevante. Uma gravação de tela curta ajuda; remova dados de clientes e mensagens privadas antes de compartilhar.
Conte com que frequência o problema acontece, quem ele afeta e se existe uma forma de contornar. Uma falha no pagamento que atinge clientes ativos pede uma resposta diferente de um problema visual em uma página interna.
Este é um relato de bug fictício, com detalhes suficientes para começar a investigar:
Na página de pedidos, escolha “Últimos 30 dias” e abra a segunda página de resultados. O filtro de data volta ao padrão e aparecem pedidos mais antigos.
Esperado: o filtro de data continua selecionado ao passar pelas páginas de resultados.
Isso acontece sempre no Chrome, no meu notebook. A equipe consegue contornar buscando pelo número do pedido, mas revisar os pedidos recentes leva mais tempo.
Me dê um mapa do sistema atual
Você não precisa conhecer cada detalhe técnico. Comece pelo que sabe e me diga quem pode responder perguntas sobre o resto.
Onde o código está guardado, quem é o dono do repositório e qual versão está no ar.
Onde a aplicação roda e como as mudanças são publicadas hoje.
O banco de dados, o armazenamento de arquivos e os serviços externos que ela usa.
Instruções de configuração, verificações automáticas ou documentação existente.
Problemas conhecidos, trabalho inacabado e tentativas anteriores de resolver este problema.
Se o desenvolvedor anterior ou outra equipe está disponível para tirar dúvidas.
Se você tem um ambiente de homologação (uma cópia separada onde as mudanças são testadas antes de chegar aos clientes), me diga como acessar. Se não tiver, planejamos um quando o trabalho exigir.
Diga o que o sistema atual precisa preservar: links existentes, dados salvos, permissões de usuários, integrações ou versões do app que ainda estão nos celulares dos clientes. Isso passa despercebido com facilidade quando a conversa é sobre uma única tela nova.
Dê acesso por convite
Continue sendo o dono do repositório, da hospedagem, do domínio e das contas de pagamento. Convide o desenvolvedor pelo controle de acesso de cada serviço, com as permissões necessárias para o trabalho. Quando o provedor permite, uma análise pode começar com acesso somente leitura e um ambiente de testes.
Não cole senhas, chaves de API de produção, exportações de clientes nem um arquivo de ambiente completo no briefing. Combinamos à parte como passar os segredos necessários. Contas de teste e dados de exemplo costumam ser mais úteis para reproduzir um problema do que acesso irrestrito a dados reais de clientes.
Entenda a análise antes do orçamento
Em um código existente, preciso verificar como ele roda, rastrear o comportamento relevante e entender quais partes uma mudança pode afetar. Uma funcionalidade que parece isolada pode mexer em permissões, cobrança ou em uma migração do banco de dados.
Combinamos o escopo e as condições da análise antes de ela começar. O resultado por escrito deve explicar:
O que foi examinado, o que foi possível reproduzir e quais acessos ou informações ainda faltam.
A mudança recomendada, incluindo alternativas que valem a pena considerar.
Quais funcionalidades ou dados existentes podem ser afetados.
Como o trabalho será verificado, publicado e revertido se houver um problema.
O que já dá para estimar e o que precisa de mais investigação.
Peça um motivo antes de reescrever
Código mais antigo ainda pode fazer bem o seu trabalho. Um framework diferente ou as preferências de um novo desenvolvedor são motivos fracos para substituir um sistema que funciona. Muitas vezes a mudança certa é uma correção pontual, um teste que faltava ou uma atualização feita em etapas.
Às vezes a substituição se justifica. Pergunte quais requisitos o sistema atual não consegue atender de forma razoável, quais partes poderiam ser mantidas e como seria a transição. A comparação precisa incluir a migração dos dados e a preservação do comportamento atual, além de escrever o sistema novo.
Combine como as mudanças chegam aos usuários
Antes de publicar, precisamos saber como a mudança será testada, quem vai revisá-la e o que acontece se algo der errado. Para um produto no ar, quero um plano de publicação combinado e uma forma de voltar atrás. Reverter o código nem sempre desfaz uma mudança nos dados, por isso migrações de banco de dados precisam de um plano próprio.
No exemplo do filtro de data, verificaríamos que a seleção se mantém ao trocar de página e que os outros filtros continuam funcionando. Você deve conseguir conferir esse comportamento em uma prévia antes de a correção chegar ao site no ar.
Na entrega, você deve conseguir ver o que mudou, como foi verificado e o que ficou para depois. Novos passos de instalação, mudanças de configuração e limitações conhecidas vão para a documentação.
O que me enviar primeiro
Este é o produto e quem usa: …
Esta é a funcionalidade ou o problema, com um exemplo: …
Isto precisa continuar funcionando: …
Isto é o que sei sobre o código, a hospedagem e o desenvolvedor atual: …
Este é o impacto, a prioridade e o prazo, se houver: …
Comece enviando esse contexto peloformulário de contato. Você não precisa organizar o projeto inteiro nem escrever documentação técnica antes de pedir ajuda.