Um novo programador poderá terminar o seu software se conseguir verificar o que funciona, obtiver acesso autorizado ao que precisa e mostrar uma forma viável de concluir uma tarefa importante. Peça primeiro uma avaliação breve. Um ecrã pode parecer pronto e, ainda assim, o processo parar antes de guardar o resultado. Uma cópia do código pode não incluir as instruções ou os serviços necessários para executar o software.
Se já há pessoas que dependem de uma versão em produção, combine quem a vai manter em funcionamento durante a avaliação. Pode assegurar a manutenção agora e decidir mais tarde se a substitui.
O que pode entregar a um novo programador?
Peça a última versão do código-fonte que foi utilizada ou testada, juntamente com as instruções e dependências necessárias para a compilar. Saiba quem controla as contas usadas para colocar o software em produção e ligá-lo a outros serviços. Identifique onde estão os registos da empresa e as cópias de segurança e o que os seus acordos lhe permitem partilhar ou alterar. Ter acesso ao repositório não comprova, por si só, essas permissões.
Verifique estes pontos separadamente. Uma equipa pode conseguir executar uma cópia e ainda assim não ter acesso para atualizar a versão em produção. Também pode ter acesso ao alojamento sem conseguir reconstruir o software a partir dos elementos entregues. Se for preciso transferir registos, teste separadamente uma exportação que o novo sistema consiga utilizar.
O que deve demonstrar a nova equipa?
Escolha uma tarefa importante para a empresa. Imagine uma ferramenta inacabada de coordenação de serviços: um trabalhador consegue enviar um pedido, mas ainda ninguém demonstrou que um responsável o consegue aprovar e consultar a decisão mais tarde. Peça à equipa que compile uma versão conhecida e teste essa tarefa num ambiente separado e autorizado. Use registos fictícios e desative notificações reais, pagamentos e outras ações com efeito na operação. Mantenha o sistema em produção fora do teste.
Siga o pedido até onde for possível e registe onde para. Se o responsável o consegue aprovar, mas a decisão desaparece quando volta a abrir o pedido, a equipa tem um problema concreto para investigar. Se uma dependência em falta impedir o arranque do software, registe que o processo ainda não pôde ser demonstrado e identifique o que falta. O próximo passo será diferente do que tomaria perante uma falha confirmada na aprovação.
A compilação mostra que a equipa conseguiu preparar aquela versão naquelas condições. Não comprova a segurança do sistema, a facilidade de manutenção, a autorização para o colocar em produção ou se está pronto para esse uso. A descrição da Google sobre a transferência da responsabilidade pela operação ilustra essa decisão separada: a análise contempla as dependências e a preparação para operar o sistema, com formação e melhorias quando necessário.
Deve continuar, corrigir uma parte ou substituir o software?
Compare as opções com base na mesma tarefa e no trabalho necessário para manter o resultado. O guia de compras públicas do governo britânico mostra como comparar a adaptação e o desenvolvimento de raiz tendo em conta as necessidades, os custos e a capacidade de operar a solução escolhida.
Continuar o desenvolvimento
A equipa consegue compilar uma versão conhecida, o processo atual funciona no ambiente de testes e a etapa em falta pode ser acrescentada sem afetar o funcionamento do resto do sistema.
Corrigir uma parte
O processo principal funciona, mas uma área específica, como a publicação de uma nova versão ou uma integração, precisa de uma correção. Pergunte como a equipa a testaria antes de voltar a usar essa parte.
Substituir o software
As opções que aproveitam o software existente não cumprem um requisito essencial com um custo ou risco aceitável. Antes da mudança, planeie como transferir os registos e o trabalho em curso.
Se a substituição parecer a melhor opção, decida separadamente como dar continuidade ao trabalho em curso. Usar os dois sistemas em paralelo por algum tempo é uma forma de fazer a transição, com custos próprios e a necessidade de definir quem responde pelos registos.
O que deve ficar por escrito depois da avaliação?
Peça um resumo breve que possa ler com quem usa o software. Deve indicar o que a equipa demonstrou, o que falhou ou ficou por testar, que acessos ou autorizações faltam e o que pode interromper o trabalho atual. Para cada opção viável, identifique a fase seguinte, quem deve agir e o que verificará antes de aprovar mais trabalho.
Na ferramenta do exemplo, o próximo passo poderia ser perceber por que desaparece uma aprovação guardada e depois demonstrar que o responsável consegue voltar a encontrar a decisão no sistema de testes. Se estiver a avaliar equipas para esse trabalho, consulte o que perguntar a um programador de software à medida antes de o escolher.
Perguntas sobre como retomar software por terminar
Basta ter o código-fonte?
O código dá à nova equipa algo para analisar. Confirme a que versão corresponde, se pode conceder acesso autorizado ao que a equipa precisa e se esta consegue compilar a versão e testar uma tarefa importante fora do sistema em produção.
Quando é suficiente uma correção pontual?
Considere essa opção se o processo principal funciona e a equipa consegue delimitar e testar a correção numa única área. Pergunte que problemas ficariam por resolver e quem poderia manter o software depois.
O que devo receber no fim da avaliação?
Um resumo do que funcionou nos testes, do que falta verificar, do que está em falta e do que cada opção exigiria. Esclareça quem manterá a funcionar a versão já em uso, se existir, e qual o próximo passo que aprovaria.
