Comment gérez-vous les projets laissés par les autres employés? [fermé]

15

Il arrive que quelqu'un quitte soudainement l'entreprise. Maintenant, son travail doit être terminé et on vous le confie. N'ayant aucune idée de ce qu'il faisait (90% ou 9%), comment gérez-vous les restes?

  1. Dois-je repartir de zéro? Et si c'était fait à 90%?
  2. Dois-je essayer de comprendre ce qu'il a fait? Et si c'était juste un non-sens?
Shirish11
la source
10
+1 pour contrer le downvote non mérité à mon humble avis. Je pense que c'est une question assez décente, réelle et fiable qui est sur le sujet ici. Il est triste de voir ce site devenir de plus en plus hostile et impatient, suivant le chemin de SO lui-même :-(
Péter Török
2
@ PéterTörök Je pense qu'il obtient des votes serrés parce que n'importe qui peut écrire une réponse qui a à voir avec n'importe laquelle de la multitude de meilleures pratiques lorsqu'il travaille avec d'autres codes. Jusqu'à présent, les réponses ci-dessous sont excellentes BTW mais je peux voir cela générer 50 réponses boiteuses.
maple_shaft
Tout ce dont j'ai besoin, c'est d'une stratégie décente, car lorsque de telles situations surviennent, tout le monde est juste foutu .
Shirish11
2
@maple_shaft, à mon humble avis, cela pourrait s'appliquer à presque toutes les questions sur ce site ;-)
Péter Török
Dans une entreprise raisonnable, la personne qui partait aurait rapporté quotidiennement dans le standup quels étaient ses progrès et, en plus de ses tâches, elle aurait été divisée en morceaux raisonnables de toute façon.
MSalters

Réponses:

7

Pour savoir quoi faire, vous devez savoir ce que vous avez et comment il est en forme.

Alors, commencez par avoir un aperçu rapide de toutes les sources et voyez ce que vous avez. S'il est clair, il est plus facile de terminer ce qui manque. Faites des tests unitaires pour découvrir ce qui fonctionne et ce qui ne fonctionne pas.

Si ce n'est pas vraiment clair, commencez à comprendre ce qui fonctionne avec les nouveaux tests unitaires. Si cela est impossible, dites à votre chef d'équipe que vous avez un problème et que vous ne pourrez peut-être pas le résoudre. Il peut alors décider si le travail à gauche doit être récupéré de toute façon ou s'il est tout simplement trop mauvais et vous devez le refaire.


la source
Déterminer quelles sont les exigences serait également important de comprendre ce qui vous manque?
Svish
7

En plus de ce que les autres ont écrit, je vous suggère de parler à toute personne qui a eu un contact direct avec le gars. Je comprends de votre description qu'il travaillait seul, il devait quand même faire rapport à quelqu'un? Et il peut y avoir du personnel QA ayant testé ce qu'il avait produit ... Ces personnes devraient (normalement) avoir au moins une idée approximative de la distance que le gars a parcourue avec son projet avant de partir. À moins bien sûr que les informations / produits fournis par lui se soient avérés être totalement non fiables, contribuant à sa mise à pied.

Discutez-en avec votre responsable et allouez un laps de temps pour l'exploration / test initial du code restant et la compréhension des spécifications et des exigences. Cela pourrait être à peu près une journée pour un projet sur une échelle de temps de quelques mois-personne, au plus une semaine pour un projet d'une ou plusieurs années-personnes, etc.

Après cette exploration initiale, vous devriez avoir une estimation approximative de

  • ce que le produit est censé faire,
  • que peut-il faire actuellement et dans quelle mesure,
  • combien de temps et de risques il faudrait pour réécrire à partir de zéro,
  • combien de temps et de risque il faudrait pour terminer ce qui a déjà été fait.

Ensuite, vous pouvez vous asseoir à nouveau avec votre manager pour prendre une décision.

Péter Török
la source
Essayer de prendre contact avec le gars semble hors de question car ils disparaissent.
Shirish11
1
Je voulais contacter le chef de projet des gars , ou quelqu'un dans un rôle similaire qui supervisait son travail.
Péter Török
les gestionnaires ne sont pas pleinement conscients de ce qui se fait réellement dans la partie codage.
Shirish11
1
@ Shirish11, bien sûr que non, mais tout gestionnaire de projet digne de ce nom devrait être au moins grossièrement informé de la mesure dans laquelle son ou ses membres d'équipe sont actuellement en train de terminer une tâche / un projet donné.
Péter Török
6

D'après mon expérience, ce n'est pas une situation rare. Malheureusement, vous avez vraiment deux problèmes ici :

1) Les restes de ce projet 2) Les raisons pour lesquelles vous êtes entré dans ce pétrin en premier lieu

Pour (1), vous devez tenir compte de la taille / complexité du projet. S'il s'agit d'une semaine de travail, vous devrez probablement tout recommencer. S'il s'agit d'une année de travail, vous devrez peut-être voir ce que vous pouvez récupérer du code existant.

Dans tous les cas, vous devez suivre ces étapes immédiatement:

a) Dites à vos managers que vous avez un gros problème

b) Obtenez les spécifications du projet et obtenez une compréhension approfondie de ce que vous devez réaliser - ou parlez aux sponsors du projet s'il n'y a pas de spécifications.

c) Parlez aux gestionnaires / clients, etc. et découvrez si quelqu'un a / pense avoir une idée de l'état du projet.

Une fois que vous avez fait cela, vous serez en mesure de commencer à examiner le code / à élaborer une stratégie.

(Je ne pense pas que les tests unitaires vous aideront beaucoup - ils pourraient vous dire si les fonctions qui ont été écrites fonctionnent réellement, mais ils ne vous disent pas quelles fonctions devraient être là.)

Ce que je n'aurais pas ensuite, c'est obtenir un aperçu de l'architecture du code qui existe, et comment cela correspond au problème défini dans la spécification. Ensuite, déterminez quels sont les sous-composants de chacun de ces composants principaux et voyez comment ils s'intègrent à la vue d'ensemble. Faire cela vous dira (grossièrement) quels composants manquent.

Une fois que vous savez ce qui existe, vous devez commencer à examiner le code existant pour voir s'il fait ce qu'il est censé faire.

Une fois que vous avez fait tout cela, vous serez en mesure d'estimer combien de travail il reste à faire.

En ce qui concerne la partie (2), votre entreprise devra peut-être examiner les politiques d'embauche / politiques de rétention du personnel, trouver des moyens de tenir les programmeurs responsables des progrès.

Enfin, vous devez également réfléchir à la manière dont vous pourriez éviter que cela ne se produise dans l'entreprise si vous partez à la hâte.

Kramii
la source
+1 pour obtenir les spécifications. Parfois, le seul endroit où il existait est à l'intérieur de la tête du développeur et des personnes qui lui ont demandé de le construire.
Spencer Rathbun
5

Vous devez absolument essayer et exécuter le logiciel pour voir ce qui fonctionne et ce qui ne fonctionne pas.

Vous devrez ensuite considérer quelle documentation a été laissée. Y a-t-il des exigences écrites? Y a-t-il des tâches spécifiques - les tâches sont-elles suivies d'une manière ou d'une autre? Quelqu'un l'a-t-il testé? Dans l'affirmative, ils sauront ce qui a été fait et ce qui ne l'a pas été.

Je pense qu'un plan d'action serait:

  1. Cochez les exigences qui ont été remplies (par une analyse rapide du système comme le ferait un testeur)

  2. Regardez le code - pouvez-vous le comprendre? Est-ce bien écrit?

De toute évidence, si c'est fait à 90% et que le code est bien écrit, il suffit de le terminer.

David_001
la source
1
J'ai commencé à écrire une réponse avec exactement la même première phrase (mot pour mot) que la vôtre. Ceci est juste du bon sens. L'autre question serait - pourquoi les gestionnaires / responsables ne savent-ils pas combien de progrès ont été accomplis?
Anonyme
Les @Anonymous Managers ne travaillent pas directement sur le projet, donc le seul progrès qu'ils connaissent leur est communiqué. Si cette personne savait qu'elle partait, elle soufflait probablement de la fumée par dépit ou simplement paresse ou simplement stupidité. J'ai été dans cette situation auparavant et ce n'est pas amusant précisément parce que lorsque la direction se rend compte qu'on leur a menti à environ 90%, cela leur rappelle à quel point ils ont peu de contrôle la plupart du temps.
maple_shaft
@maple_shaft - Dans ce cas, les managers en question ne font pas leur travail correctement. Leur travail consiste à gérer une équipe pour arriver à un objectif particulier. S'ils ne suivent pas les progrès et ne délèguent pas les tâches en conséquence, à quoi servent-ils?
Anonyme
1
@ Anonymous- Vous travaillez en tant que développeur de logiciels depuis très longtemps ;-)? Au fil des ans, mon opinion sur un bon manager est tombée sur une personne qui reste hors de mon chemin et qui efface parfois les barrages routiers .
maple_shaft
1
@maple_shaft - Lol, c'est assez juste. De toute évidence, ce style de gestion n'a pas fonctionné pour l'entreprise de l'op. :-p
Anonyme
3

Pas encore mentionné.

Essayez de contacter le gars qui est parti. Ce n'est pas possible dans tous les cas. Mais s'il est en bonne santé et qu'il aime au moins un peu son travail, il vous aidera et vous donnera une réponse honnête des progrès et des parties manquantes. Et il pourrait vous expliquer la situation dans son ensemble.

matcauthon
la source
+1: Si possible, c'est probablement la solution la plus simple et la plus efficace.
Leo
1

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.

HLGEM
la source