Félicitations, c'est votre chance de briller et de faire une impression vraiment positive sur vos patrons. Ce que vous avez ici est une opportunité inestimable. Alors, que devez-vous faire et comment?
Tout d'abord, récupérez le code. Il n'a peut-être pas tout vérifié (le gars qui nous a fait ça ne l'a pas fait) et donc quelqu'un avec des droits d'administrateur le retire de son ordinateur et le vérifie pour vous.
Ensuite, triez le problème. Prenez les exigences et notez quelles parties semblent avoir du code écrit et lesquelles ne le font pas. Ceci est la liste approximative de ce qui n'est pas terminé. Il grandira à mesure que vous ferez la prochaine étape. Parcourez ensuite le code et évaluez-le, exécutez-le et voyez ce qui fonctionne actuellement et ce qui semble ne pas fonctionner même s'il y a du code écrit. Ajoutez les pièces non fonctionnelles à la liste. Recherchez les tests unitaires (je serais surpris si vous les trouviez, les gens qui renflouent juste avant une date limite parce qu'ils savent qu'ils échouent ont tendance à ne pas les écrire). Maintenant, au moins, vous avez une bonne idée de sa gravité. Consultez également les exigences et voyez à quelles questions vous avez besoin de répondre. Souvent, les échecs du projet sont dus à de mauvaises exigences et à un développeur qui ne veut pas (pour une multitude de raisons) de poser d'autres questions.
Maintenant, vous faites votre plan de projet. Commencez par une liste des questions que vous vous posez sur les exigences (écrivez-les officiellement dans un document), puis énumérez les choses que vous devez faire pour terminer le travail. Faites une estimation du temps que cela prendra. Déterminez si ce qui existe actuellement est récupérable (et sinon, soyez prêt à justifier pourquoi pas).
Maintenant, rencontrez le chef de projet (et votre patron s'il s'agit de deux personnes différentes) et dites-lui les mauvaises nouvelles. (C'est presque toujours une mauvaise nouvelle quand quelqu'un part soudainement et que vous devez reprendre là où il s'est arrêté, les bons développeurs ne laissent pas les gens dans l'embarras - ils partent au moins avec une liste de ce qu'ils ont fait et de ce qu'il reste à faire L'exception peut être si quelqu'un est parti en raison de problèmes de santé.) Dans votre discussion, vous pouvez obtenir certaines des réponses dont vous avez besoin et vous et le PM pouvez retravailler un peu le plan du projet.
Faites le suivi de la réunion en envoyant le PM et d'autres parties prenantes essentielles (le PM identifiera qui), une copie de vos questions auxquelles il faut répondre et le plan de projet que vous avez élaboré.
Maintenant, vous avez ce dont vous avez besoin pour commencer le codage réel, alors mettez-vous au travail.
En attendant, vous avez probablement été retiré de quelque chose d'autre pour sauver ce projet. Assurez-vous que votre travail est en forme pour que quelqu'un d'autre le récupère ou pour que vous le récupériez une fois le projet terminé. Cela signifie les mêmes types de choses, un document où vous dites ce qui est fait et ce qui ne l'est pas et un archivage de tout le code source (pas nécessairement au coffre si ce n'est pas fait, mais quelque part où quelqu'un d'autre peut y accéder .
Si vous n'avez pas été retiré de votre travail actuel, vous devez déterminer avec votre patron combien de temps vous consacrerez à la journée de travail. C'est l'un de ces moments où des heures supplémentaires peuvent être nécessaires et seront appréciées. Plus il est proche de l'échéance réelle, plus la gestion est désespérée, vous pourrez peut-être calculer la rémunération des heures supplémentaires ou un gros bonus si l'échéance est proche. Si ce travail va retarder considérablement l'autre travail, vous devez vous assurer que les parties prenantes de ce projet en sont conscientes.
Une fois que vous avez réussi à sauver le projet, assurez-vous de vous en vanter lors de votre prochaine évaluation des performances.