Mission bad
Hello,
Je suis en mission depuis presque un an, à la base je suis développeur, mais depuis le début de cette mission, je me consacre principalement à la correction de bugs et à quelques retouches. Je ne me sens donc pas vraiment productif. Le projet était déjà terminé à mon arrivée, et la livraison traîne.
Actuellement, je suis quasiment le seul sur le projet. Qu'en pensez-vous ?
- Utilisateur supprimé
Bonjour,
Bienvenue dans le vrai monde de la MOE. En retard, vache, rêche, pointé du doigt par la MOA et l'AMOA, aux technos dépassées, aux ordres de missions changeant, culpabilisant, éreintant.
-
Bonjour,
La maintenance fait aussi partie du métier, c'est même tout un art. Est-ce que l'activité est totalement déphasée de ce qui a été présenté en entretien ?
-
Pour ma part, quand je développais, j'adorais la TMA. Ca m'éclatait de chercher l'origine d'une anomalie, de comprendre le pourquoi du comment, et j'avais un réel plaisir lorsque je trouvais la solution. Encore maintenant, j'adore faire de l'analyse d'incident, même si ce n'est plus ma principale activité.
Je m'ennuie plus en projet, ou pendant une période donnée (le temps du projet), je développais matin midi et soir sur le même sujet.
Ce n'est que ma vision personnelle, et je crois qu'assez peu de dev la partage.
-- Yann EURL IS depuis 2019Utilisateur suppriméDisons que "ça dépend". Quand il s'agit d'une anomalie parce qu'on a codé en dur une liste de produits et qu'il y a soudainement un ou produits en plus (rajoutés ou oubliés), on râle un peu à cause du manque de l'architecture peu flexible.
Quand il y a gros legacy sur une architecture bancale parce qu'on n'avait pas prévu de rajouter une cave et un garage et un immeuble, mais qu'il faut "surtout pas toucher"... Perso, j'ai déjà eu des ordres contradcitoires et qui me sont retombés dessus parce que ça plantait. Et si j'essayais d'être proactif en anticpant les problèmes, c'était "on est sur une TMA, y a le nouveau produit qui arrive, fait au mieux, applique un patch". Quand le patch est toujours là 3 ans après et demande tous les mois des actions manuelles alors qu'un dev d'une demi-journée aurait suffi...
Un petit exemple : On a fait une migration. J'ai voulu faire un test de fond pour vérifier la non-régression mais le Directeur de projet a juste fait "on lance, on regarde si ça plante, on livre". J'ai mis mon veto, on m'a dit que ça coûtait trop cher, on n'a pas le temps... Finalement, ça a planté, je m'en suis pris plein la tronche, c'était ma faute, j'avais intérêt à bosser le week-end pour récupérer mes conneries...
J'ai vu après qu'on faisait une jointure sur un libellé, et qu'avec la migration, on avait transformé "données" en "donneés". J'avais vu aussi qu'il y avait un code numérique. J'ai donc voulu changer en passant par le code, j'ai vérifié l'ensemble du projet... le directeur "Ha non ! T'as fait trop de conneries, on n'a pas le temps, on n'a pas le budget, on va donc faire une astreinte chaque mois pour charger à la main".
Bref, quand t'as un legacy immuable, des CP et des DP qui veulent prendre 0 prise de risques mais se retrouvent avec un run remplis d'incohérence... Que tu prouves par à A+B qu'il n'y aura pas de régression, alors que l'architecture avait été mauvaise dès le développement, c'est fatigant. Et surtout, te prendre une rouste alors que tu n'avais eu aucun choix sur l'architecture et la qualité du code...
-
Sois proactif.
Sur ton projet, si ce n'est déjà fait :
- mets en place des tests unitaires, des tests d'intégration, et refactorise le code, ce qui facilitera la maintenance
- documente ton projet : doc d'installation, doc d'utilisation, tutoriel, guide pour un nouveau développeur, guide de reprise après panne, ...
- ajoute des fonctionnalités qui te seront utiles (pour mieux gérer les incidents, pour faciliter les futurs développements ...)
intéresse-toi à ce qui se passe dans l'entreprise: les aspects métier, les projets des collègues...
forme-toi pour monter en compétence (méthodes de travail, technologies ...)
Et fais un point avec ton client final pour savoir ce qu'il pense de ton travail, et ce qu'il prévoit pour les prochains mois.
-
La correction de bugs fait partie du métier de développeur. Après, tu es arrivé à une phase du projet où tu ne vois plus rien à créer mais "juste" à corriger des problèmes. Ca ressemble à ma mission actuelle sauf que ... c'est ce que je cherchais !! alexis-beuraud-1 donne un éclairage différent et si tu en as la latitude (ainsi que la curiosité), tu peux trouver de l'épanouissement si tu arrives à te sentir autrement que celui qui corrige les bugs, sur un produit parfois pas super satisfaisant.
Est-ce qu'en entretien on t'as présenté le projet ainsi ? Sens-tu que tu peux faire des choses où on te dit "ah, si ça avait été il y a un an, tu aurais pu mais là on modifie le moins possible" ou "non, mais là, le projet est terminé" ... Un projet est rarement terminé. Il y a des bugs à corriger, il y aura des demandes d'évolution, etc. C'est en réalité rarement trop tard ? Le projet a-t-il une CI ? Mets-en une en base. Pareil pour les tests. Il faut juste commencer. Ou comme le refactoring, le clean de code .... Par petites touches. Ca peut devenir très gratifiant quand tu vois que la qualité s'améliore, que la confiance remonte un peu, que la compréhension se révèle peu à peu ...
Travailler dans le contexte que tu décris peut-être très difficile. Surtout si tu es jeté là-dedans sans préparation. Et il y a aussi le fait d'être tout seul. C'est le genre de position qui peut être au final extrêmement intéressante mais il faut être un peu câblé pour ... Surtout préparé et avoir un spectre de compétences un peu élargi (outils de développement au sens large, test, CI, pratiques de documentation, méthode de refactoring et travail sur du code legacy, etc.).
-
