Como você gerencia os projetos deixados por outros funcionários? [fechadas]

Acontece que alguém simplesmente sai da empresa de repente. Agora o trabalho dele precisa ser concluído e você está sendo designado. Não tendo ideia do que ele estava tramando (90% ou 9%), como você gerencia as sobras?

1. Devo começar do zero? E se fosse feito 90%?
2. Devo tentar entender o que ele fez? E se fosse apenas um disparate?

Para descobrir o que fazer, você precisa saber o que tem e como está em boa forma.

Então, comece com uma rápida olhada em toda a fonte e veja o que você tem. Se estiver claramente claro, é mais fácil terminar o que está faltando. Faça testes de unidade para descobrir o que funciona e o que não funciona.

Se não estiver claro, comece a descobrir o que funciona com novos testes de unidade. Se isso for impossível, mostre ao seu líder de equipe que você tem um problema e que talvez não seja capaz de resolver. Ele pode decidir se o trabalho da esquerda deve ser recuperado de qualquer maneira ou se é muito ruim e você precisa refazê-lo.

Além do que os outros escreveram, sugiro que você converse com alguém que tenha contato direto com o sujeito. Entendo pela sua descrição que ele estava trabalhando sozinho, ainda assim ele deve estar se reportando a alguém? E pode haver pessoal de controle de qualidade que testou o que ele havia produzido ... Essas pessoas devem (normalmente) ter pelo menos uma idéia aproximada de quão longe o cara chegou com seu projeto antes de partir. A menos, é claro, que as informações / produtos fornecidos por ele se mostrassem completamente não confiáveis, contribuindo para sua demissão.

Discuta isso com seu gerente e aloque um prazo para a exploração / teste inicial do código restante e para entender as especificações e os requisitos. Isso pode durar aproximadamente um dia para um projeto na escala de tempo de algumas pessoas, no máximo uma semana para um projeto de trabalho de uma ou mais pessoas por ano, etc.

Após essa exploração inicial, você deve ter uma estimativa aproximada de

• o que o produto deve fazer,
• o que ele pode fazer atualmente e quão bem,
• quanto tempo e risco seriam necessários para reescrever do zero,
• quanto tempo e risco seriam necessários para concluir o que já está feito.

Então você pode se sentar com seu gerente novamente para tomar uma decisão.

Na minha experiência, isso não é uma situação incomum. Infelizmente, você realmente tem dois problemas aqui :

1) As sobras deste projeto 2) As razões pelas quais você entrou nessa confusão em primeiro lugar

Para (1) você precisa considerar o tamanho / complexidade do projeto. Se for uma semana de trabalho, você provavelmente precisará começar tudo de novo. Se vale um ano de trabalho, pode ser necessário ver o que você pode recuperar do código existente.

De qualquer forma, você precisa executar estas etapas imediatamente:

a) Diga a seus gerentes que você tem um grande problema

b) Obtenha as especificações do projeto e obtenha um entendimento completo do que você precisa alcançar - ou converse com os patrocinadores do projeto se não houver especificações.

c) Converse com gerentes / clientes etc. e descubra se alguém tem / pensa que tem alguma idéia de qual é o estado do projeto.

Depois de fazer isso, você poderá começar a examinar o código / elaborar uma estratégia.

(Não acho que os testes de unidade o ajudem muito - eles podem dizer se as funções que foram escritas realmente funcionam, mas não dizem quais funções devem estar lá.)

O que não quero em seguida é obter uma visão geral da arquitetura do código que existe e como isso é mapeado para o problema definido na especificação. Em seguida, trabalhe o que são os subcomponentes de cada um desses componentes principais e veja como eles se encaixam no quadro geral. Fazer isso informará (aproximadamente) quais componentes estão faltando.

Depois de saber o que existe, você precisa começar a examinar o código existente para ver se ele faz o que deve fazer.

Depois de fazer tudo isso, você poderá estimar quanto trabalho resta fazer.

Quanto à parte (2), sua empresa pode precisar examinar políticas de contratação / políticas de retenção de funcionários, encontrar maneiras de manter os programadores responsáveis ​​pelo progresso.

Finalmente, você também deve considerar como você pode evitar que isso aconteça à empresa deve você sair com pressa.

Você definitivamente precisa tentar executar o software para ver o que funciona e o que não funciona.

Você precisará considerar qual documentação foi deixada. Existem requisitos escritos? Existem tarefas específicas - as tarefas são rastreadas de alguma maneira? Alguém já testou - se sim, saberá o que está feito e o que não está.

Eu acho que um plano de ação seria:

1. Marque quais requisitos foram concluídos (por uma rápida execução do sistema como um testador faria)

2. Veja o código - você consegue entender? Está bem escrito?

Claramente, se estiver 90% pronto e o código estiver bem escrito, você deve terminar.

Ainda não mencionado.

Tente entrar em contato com o cara que saiu. Não é possível em todos os casos. Mas se ele estiver saudável e pelo menos gostar um pouco de seu trabalho, ele ajudará e fornecerá uma resposta honesta do progresso e da falta de peças. E ele poderia explicar o quadro geral para você.

Parabéns, esta é sua chance de brilhar e causar uma impressão realmente positiva em seus chefes. O que você tem aqui é uma oportunidade inestimável. Então, o que você precisa fazer e como?

Primeiro, pegue o código. Ele pode não ter feito o check-in de tudo (o cara que fez isso conosco) e, portanto, alguém com direitos de administrador o retira do computador e faz o check-in para você.

Triagem seguinte do problema. Pegue os requisitos e observe quais partes parecem ter código escrito e quais não. Esta é a lista aproximada do que não está concluído. Ele crescerá à medida que você faz o próximo passo. Em seguida, percorra o código e avalie-o, execute-o e veja o que está funcionando no momento e o que parece não funcionar, mesmo que exista código escrito. Adicione as peças que não estão funcionando à lista. Procure testes de unidade (eu ficaria surpreso se você os encontrasse, as pessoas que pagam pouco antes de um prazo porque sabem que estão falhando tendem a não escrevê-los). Agora, pelo menos, você tem uma boa idéia de quão ruim é. Examine também os requisitos e veja quais perguntas você precisa responder. Muito tempo, as falhas do projeto ocorrem como resultado de requisitos insuficientes e de um desenvolvedor que não deseja (por uma infinidade de razões) fazer mais perguntas.

Agora você faz seu plano de projeto. Comece com uma lista das perguntas que você tem dos requisitos (escreva formalmente em um documento) e, em seguida, liste as coisas que você precisa fazer para concluir o trabalho. Faça uma estimativa de quanto tempo cada um levará. Determine se o que existe atualmente é recuperável (e, caso contrário, esteja preparado para justificar por que não).

Agora faça uma reunião com o gerente do projeto (e seu chefe, se forem duas pessoas diferentes) e conte a ele as más notícias. (Quase sempre são más notícias quando alguém sai de repente e você tem que continuar de onde parou, bons desenvolvedores não deixam as pessoas à vontade - elas pelo menos deixam uma lista do que fizeram e do que resta fazer A exceção pode ser se alguém sair devido a problemas de saúde.) Em sua discussão, você pode obter algumas das respostas necessárias e você e o gerente de projetos podem refazer um pouco o plano do projeto.

Acompanhe a reunião enviando o MP e outras partes interessadas críticas (o MP identificará quem), uma cópia de suas perguntas que precisam ser respondidas e o plano do projeto que você elaborou.

Agora você tem o que precisa para começar a codificação real, então comece a trabalhar.

Enquanto isso, você provavelmente foi contratado para salvar esse projeto. Certifique-se de que seu trabalho esteja em forma para outra pessoa atender ou para você depois que terminar o projeto. Isso significa os mesmos tipos de coisas, um documento em que você diz o que é feito e o que não é e um check-in de todo o código-fonte (não necessário para o tronco, se não for feito, mas em algum lugar que outra pessoa possa acessá-lo .

Se você não foi retirado do trabalho existente, precisará calcular com seu chefe quanto tempo você gastará em cada dia de trabalho. Este é um daqueles momentos em que horas extras podem ser necessárias e serão apreciadas. Quanto mais próximo do prazo real, mais desesperada a administração, você poderá pagar horas extras ou um grande bônus se o prazo estiver próximo. Se este trabalho atrasar significativamente o outro trabalho, você precisará garantir que as partes interessadas nesse projeto estejam cientes disso.

Depois de conseguir salvar o projeto, não deixe de se gabar disso na sua próxima avaliação de desempenho.