Discussion :

[tevious]

Bonjour,

Tout d'abord je précise d'entrée de jeu que je ne travaille pas pour une SSII mais un éditeur de logiciels, comme je ne trouve de rubrique plus appropriée, je poste ici.

J'écris ce soir car je suis en profonde remise en question suite à mon premier job, je me demande même si je ne vais pas quitter le métier.

Je suis de formation ingénieur généraliste en génie électrique, j'ai toujours été doué pour l'informatique (Java et C++ là où j'ai étudié). Profitant d'un master en complément de ma formation, j'ai pu travailler dans le domaine bancaire pour mon stage où j'ai fait de l'info pure et dure, C# et Cobol.
Le sujet lié au système comptable m'a plu et j'ai vraiment adoré mon stage où j'ai fait du développement à temps plein. Malheureusement, le contexte a fait que je n'ai pas pu être embauché là bas, j'ai donc quelques semaines après ma fin de stage trouvé un emploi chez un éditeur de logiciel à l'état de transition startup vers PME technologiques (20 employés, 3 ans d'existence).

J'ai été recruté comme développeur C# (techno utilisées: Silverlight, SQL serveur, Entity et RIA WCF) avec mise en avant de mon master spé (management) pour plus tard avoir des fonctions d'encadrement ou plus commerciales qui viendront avec la croissance de la société.
J'arrive à l'heure actuelle à la fin de ma période d'essai (renouvelable mais aucun signe du côté de mon boss qui laisse entendre que c'est son intention) et je sature de ce job.
Le logiciel sur lequel je travaille a été développé par une SSII à la base pendant 2 ans, les développeurs internes n'ont été recrutés que pour les premiers il y a 1 an, ce qui fait que ce sont les prestataires qui connaissent le mieux le système. Il n'existe aucune (absolument aucune) documentation développeur sur le logiciel, pas plus que de schémas d'architecture sur la BDD, ce qui fait qu'après 4 mois de développement j'avance encore à taton.
Notre chef de projet (qui est lui aussi arrivé il y a 1 an) utilise la méthode Scrum pour la gestion de projet, et je trouve qu'il se passe des choses bizarres:
La nouvelle version du soft a été développé pendant 2 mois cet été, et depuis l'automne, on passe 4 mois à la corriger (spécification non respectée, fonctionnalité bogué, régressions etc...). Je me demande donc s'il est normal qu'on passe 2 fois plus de temps à corriger qu'à développer? J'ai été recruté comme développeur, ça fait 4 mois que je ne fais que du debug, là aussi je ne sais pas si c'est normal, du coup comme je n'ai jamais pu développer par moi même une partie de projet, et donc je maitrise peu les technos que j'ai évoqué plus haut (j'ai heureusement pu faire les tutos à la maison pour comprendre les principes).

A l'heure actuelle c'est très fastidieux d'aller au travail, je corrige certains jours 5 à 10 bugs quand ils sont mineurs, des fois je passe une semaine à en traquer un car il est difficile de localiser la source du problème et la personne ayant codé la partie n'est plus identifiable...
Les conditions de travail sont peu favorables, 39h sans rtt pour un salaire entre 1500 et 1600 net (+13 ème mois).
L'ambiance au sein de l'équipe n'est pas des plus agréables, la société voulant internaliser ses ressources veut sortir les prestataires, ces derniers ont donc tout intérêt à ne pas transférer leurs compétences et à se rendre indispensable, on est donc limite obliger de les supplier pour qu'ils nous expliquent le fonctionnement de tel ou tel module (alors qu'on va corriger un bug dont ils sont probablement responsable), ils nous en disent le minimum pour pas qu'on maitrise le sujet, et quand ils corrigent pour nous on subit leurs moqueries ("à mais c'était pourtant évident").

J'ai été recruté en même temps qu'un collègue qui rame tout autant que moi malgré ses 10 ans d'expériences, et un collègue recruté il y a 1 an n'a toujours pas une vision clair de l'application.

J'ai besoin de vos conseils pour savoir comment sortir de cette situation.
J'ai bien envie d'aller voir le responsable info pour lui dire ce que j'ai écrit ici, à mon avis les presta ne devraient plus développer et passer le temps qu'ils leur restent à faire à écrire la documentation qu'ils n'ont jamais voulu faire, mais comme c'est une startup, la priorité n'est pas de faire de la doc mais de sortir une nouvelle version du produit tous les 6 mois (et après on doit rendre des comptes sur pourquoi on a mis 4 mois à déboguer que le projet est en retard).

Je crois en l'avenir et en la possibilité d'évoluer et d'utiliser ma double compétence pour prendre des postes à responsabilité, en me disant que si le logiciel marche du tonnerre j'aurais fait une super opération, maintenant si je dois me faire remarquer grâce à mes talents de développeurs, c'est pas dans ce contexte que ça va se faire. Notre hierarchie ne nous laissant très peu d'initiative nous n'avons qu'un rôle d'exécutant (nous ne prenons jamais part à l'écriture des specs, on a nos dossiers de dév qui arrivent avec les étapes et le calendrier, et on code), et les rares fois où j'ai pu discuter marketing avec les gens du commercial en discutant d'idées d'évolutions, de marchés pour le logiciel et de promotion du produit, il y a clairement eu une manifestation de défiance de la part des responsables techniques qui m'ont pris pour un requin ambitieux affublé d'un double diplôme d'école de commerce, depuis je me tais et ne fais que mon travail.
En attendant je me coltine un job qui est pas loin de me faire détester la programmation, et je pourrai pas supporter ça pendant des années en attendant une hypothétique promotion vers un poste plus diversifié. J'en viens à me demander si je vais pas quitter ce métier pour retourner dans l'électronique, même si c'est pas ce que je préfère (contrairement à l'info qui était une passion à la base).

Si vous avez des idées de solution, des avis et quoi que ce soit qui pourrait m'aider, je suis preneur et vous remercie d'avance

Enfin, ce que j'adore c'est la R&D, donc au sens littéral du terme c'est développer un produit, puis quand il est fini en développer un nouveau etc...
Est-ce qu'il existe des métiers dans l'informatique où on ne fait que du dév, ou en tout cas très peu de maintenance (à la banque la maintenance occupée entre 25 et 50% du temps), parce que je n'aime vraiment pas ça.
Je pense que les gens qui travaillent sur des missions au forfait dans les SSII font plus ce genre de chose, maintenant je n'ai pas spécialement envie d'aller dans une SSII, sinon il y a le consulting mais je suis trop jeune, existe-t-il d'autres postes orientés dév majoritairement?

Merci beaucoup

[Glutinus]

Salut !

Je vais répondre par à-coup, je pense que les membres plus expérimentés ou chef de projet ont de meilleures réponses.

"Est-ce normal de passer quatre mois en recette alors que la dev dure deux mois", sur le papier, presque. Dans la théorie, je rappelle que la division specification / développement / test doit être de l'ordre de 40 / 20 / 40. Dans la pratique, la tonne de documentation prend du temps à être faite (ou traine) du coup la dev en prend souvent plein la gueule ainsi que les tests unitaires / d'intégration technique.

Et donc forcément quand les recettes prennent en compte une batterie de tests plus chargés ainsi qu'une batterie de tests d'intégration fonctionnelle. Donc de mon côté, j'ai souvent vu une recette prendre beaucoup plus de temps parce qu'une partie ou autre est fautive. Du coup on résoud les problèmes politiquement en désignant qu'une fonctionnalité non respectée a été mal définie, ce qui permet de transformer une "anomalie" en "évolution" et souvent d'autres jolies termes intermédiaires "changement", "innovation", bref tout le dictionnaire de synonyme y passe.

Concernant la maintenance.

"Y a-t-il des métiers où il n'y a pas de maintenance", bref tu en trouveras sûrement en tant que développeur au forfait mais la SSII impose 4 mois pour faire un projet mal dosé, résultat tu pousses un projet mal fait, spécifié à l'arrache, qui prend une recette de fou. Il y a des allers-retours, des menaces de procès entre SSII et client et finalement ça se termine par un pot avec champagne et une signature de référencement de la SSII (pour qu'elle puisse garder la maintenance).

Dans un métier où il y a de plus en plus d'applications, j'ai l'impression qu'il y a de plus en plus de maintenance. Vendue par le client comme des "oui oui il y a des projets et beaucoup d'évolutions" qui sont en fait des anomalies masquées. Et que rajouter le code produit PEEZ dans la liste des tables en lookup parce que ce n'était pas spécifié à la base est considérée comme l'évolution la plus importante de l'année (d'un point de vue client, parce que du point de vue développeur c'est juste rajouter cette donnée dans une table de référence). Bref, c'est très dur de tirer le vrai du faux.

Monde de l'édition
T'as tout compris, un éditeur va faire passer au maximum les délais. J'avais réussi à négocier, en tant qu'"expert" (j'étais le seul sur le produit) de faire une livraison plus tard avec une batterie de tests à défaut d'être parfaite, beaucoup plus complète. Le "directeur des développements" (parce qu'il n'y avait pas vraiment de hiérarchie chez cet éditeur) avait livré à mon insu mon produit qui était encore en correction, résultat boum patatras. Voilà, on livre à telle date, point.

Proactivité
Oui, les gens n'aiment pas que tu te mêles de leurs affaires. Par contre si certains pouvaient déléguer leurs tâches, ça pourrait être pas mal, du moins s'il y a de l'adhérence. On aime quand les gens font beaucoup plus que ce qu'ils savent faire (apprendre d'autres langages pour supporter d'autres équipes, apporter des idées pour améliorer les process) mais quand tu en viens à faire à 100% le projet des autres pour en tirer les lauriers, bizarrement plus personne n'est là.

Je comprends ton désir de ne pas faire de SSII, maintenant les projets, c'est comme les être humains, il y en a de tout : des complets, des gros, des petits, des très techniques, des fonctionnels, des dans le domaine bancaire, dans l'aéronautique, sur des technos donc des modes de fonctionnement ou des contraintes différentes. Tu pourras trouver ton pied sur d'autres projets, réfléchis bien à si tu veux continuer avec cette structure après ta période d'essai. Mais tu vas tomber sur des travers similaires : recette qui s'éternise, maintenance déguisée pour être plus vendeuse (une bonne partie des devs n'aiment bizarrement pas mettre les mains dans la mélasse faite par d'autres).

[Jitou]

J'écris ce soir car je suis en profonde remise en question suite à mon premier job, je me demande même si je ne vais pas quitter le métier.

Tu as le blues de l'informaticien ? T'inquiètes on l'a tous eu a un moment ou un autre.

Il n'existe aucune (absolument aucune) documentation développeur sur le logiciel, pas plus que de schémas d'architecture sur la BDD, ce qui fait qu'après 4 mois de développement j'avance encore à taton.

J'en suis guère étonné car c'est le cas de beaucoup de projets en phase de maintenance. La documentation c'est le parent pauvre de la réalisation technique car le client y voit rarement une valeur ajoutée (une doc pourquoi faire ? Il suffit de relire le code source !).

Notre chef de projet (qui est lui aussi arrivé il y a 1 an) utilise la méthode Scrum pour la gestion de projet, et je trouve qu'il se passe des choses bizarres:

Oui c'est toujours bizarre avec Scrum ...

Je me demande donc s'il est normal qu'on passe 2 fois plus de temps à corriger qu'à développer? J'ai été recruté comme développeur, ça fait 4 mois que je ne fais que du debug, là aussi je ne sais pas si c'est normal, du coup comme je n'ai jamais pu développer par moi même une partie de projet, et donc je maitrise peu les technos que j'ai évoqué plus haut (j'ai heureusement pu faire les tutos à la maison pour comprendre les principes).

Sur mon projet actuel le temps de développement c'est 10% le reste c'est les specs, les tests et le debugage. De mon expérience l'essentiel du temps que l'on passe et celui à comprendre, pardon à déchiffrer le code fait par d'autres développeurs moins expérimentés et à faire évoluer du code pas prévu pour. Parfois on passerai moins de temps à tout refaire mais ça c'est une solution invendable à un client, imagines il a payé un truc très cher et on lui fait comprendre que c'est une merde infâme !

A l'heure actuelle c'est très fastidieux d'aller au travail, je corrige certains jours 5 à 10 bugs quand ils sont mineurs, des fois je passe une semaine à en traquer un car il est difficile de localiser la source du problème et la personne ayant codé la partie n'est plus identifiable...

Tu décris là le quotidien de base du développeur.

Les conditions de travail sont peu favorables, 39h sans rtt pour un salaire entre 1500 et 1600 net (+13 ème mois).

C'est peu en effet, 2000 net serait plus honnête bien que sous évalué mais on est en France

L'ambiance au sein de l'équipe n'est pas des plus agréables, la société voulant internaliser ses ressources veut sortir les prestataires, ces derniers ont donc tout intérêt à ne pas transférer leurs compétences et à se rendre indispensable, on est donc limite obliger de les supplier pour qu'ils nous expliquent le fonctionnement de tel ou tel module (alors qu'on va corriger un bug dont ils sont probablement responsable), ils nous en disent le minimum pour pas qu'on maitrise le sujet, et quand ils corrigent pour nous on subit leurs moqueries ("à mais c'était pourtant évident").

Tu vas rire mais en ce moment je bosse sur un projet dont le code source a été écrit par un éditeur, il y a pléthore de bugs et aucune doc technique mais en tant que presta chez le client de cet éditeur nous n'avons absolument pas le droit de modifier le code source de base (on développe des plugins à la place). Bien que ce ne soit pas notre travail le plus souvent c'est nous qui indiquons à l’éditeur où se trouve les bugs dans leur code et comment les corriger pour être certains que ce soit fait correctement.

J'ai besoin de vos conseils pour savoir comment sortir de cette situation.
J'ai bien envie d'aller voir le responsable info pour lui dire ce que j'ai écrit ici, à mon avis les presta ne devraient plus développer et passer le temps qu'ils leur restent à faire à écrire la documentation qu'ils n'ont jamais voulu faire, mais comme c'est une startup, la priorité n'est pas de faire de la doc mais de sortir une nouvelle version du produit tous les 6 mois (et après on doit rendre des comptes sur pourquoi on a mis 4 mois à déboguer que le projet est en retard).

Je comprends ton désarroi mais ce n'est pas ton problème même si je conçois ton implication dans ta boite. Parfois tes décisionnaires ne cherchent pas la facilité et s'obstinent dans des schémas de "problem solving" complètement dépassés et parfois il y a des enjeux qui te dépasse et aboutissent à ces situations ubuesques.

... et les rares fois où j'ai pu discuter marketing avec les gens du commercial en discutant d'idées d'évolutions, de marchés pour le logiciel et de promotion du produit, il y a clairement eu une manifestation de défiance de la part des responsables techniques qui m'ont pris pour un requin ambitieux affublé d'un double diplôme d'école de commerce, depuis je me tais et ne fais que mon travail.

En dehors du poste de développeur de base les places sont chères car mieux rémunérées donc prépares toi à être stratégique et faire les bonnes alliances pour arriver à tes fins.

En attendant je me coltine un job qui est pas loin de me faire détester la programmation, et je pourrai pas supporter ça pendant des années en attendant une hypothétique promotion vers un poste plus diversifié.

Il fût un temps où une brève expérience de développeur permettait d'accéder en quelques mois au poste de chef de projet mais ce temps est révolu, aujourd'hui c'est plus une question de chance et d'opportunité, changer d'employeur reste à l'heure actuelle le plus sûr moyen de ne pas s'enliser et de concrétiser ses objectifs de carrière même si rien n'est acquis d'avance.

J'en viens à me demander si je vais pas quitter ce métier pour retourner dans l'électronique, même si c'est pas ce que je préfère (contrairement à l'info qui était une passion à la base).

Mais ca c'est un "vrai" métier donc pas vraiment comparable avec l'informatique ...

Enfin, ce que j'adore c'est la R&D, donc au sens littéral du terme c'est développer un produit, puis quand il est fini en développer un nouveau etc...
Est-ce qu'il existe des métiers dans l'informatique où on ne fait que du dév, ou en tout cas très peu de maintenance (à la banque la maintenance occupée entre 25 et 50% du temps), parce que je n'aime vraiment pas ça.

Malheureusement les projets tout neufs partant de presque rien se font rares, le gros du travail c'est la maintenance de l'existant. Lorsqu'on regarde le travail en
en SSII c'est vrai que la variété des missions fait que l'on trouve de temps en temps son bonheur. Je vois les "internes" chez les clients ou les éditeurs et qui passent des années à bosser sur les mêmes logiciels et les même technos, d'ailleurs après 5 ans de bons et loyaux service chez un éditeur j'étais parti car j'avais fait le tour de la question et j'aspirai à voir autre chose.

Dernier conseil va voir de temps en temps tes managers (ou ceux des autres) ou tes commerciaux et fait leur savoir ce que tu aimerai faire et cherche à savoir sur quoi ils bossent en ce moment, cela montrera ton implication et par la même occasion ton intérêt pour trouver une mission qui te valorisera. Plus qu'ailleurs il ne faut pas se laisser porter dans ce métier et être proactif.

... existe-t-il d'autres postes orientés dév majoritairement?

Développeur en SSII ou chez un éditeur ou responsable d'application (TMA en SSII) il n'y pas vraiment d'autres alternatives.

[phili_b]

Monde de l'édition
[...]
Je comprends ton désir de ne pas faire de SSII, maintenant les projets,

Surtout que dans l'affaire contée par tevious, l'éditeur semble loin d'être innocent.

[tevious]

Bonsoir,

Merci pour vos réponses.
Pour l'heure j'avais postulé par hasard dans un grand groupe pour faire de l'électronique, ils m'ont rappelé et me proposent un entretien, je vais voir ça coûte rien!

Sinon concernant Scrum j'ai même l'impression que c'est à l'origine de beaucoup de bugs. En plus d'être stressant pour le développeur à cause de sous-chiffrage, ça incite à bacler le travail pour tenir les délais, même si après on va passer le double du temps à corriger.
Pour avoir parler avec des gens issues du monde du test, le test-driven-development est vraiment ce qui se fait de mieux, à mon avis ce serait une solution à privilégier, mais je vais éviter de braquer mon chef de projet alors que ma situation est encore jeune.

Pour tout le reste on verra, je me donne un délai pour voir comment ça évolue, si la boite marche bien je pourrai peut être avoir des fonctions plus diversifiées à terme, sinon et si je sature, soit je retourne dans l'électronique, soit j'irai bien dans le monde des ERP, mais plus côté fonctionnel. Mon master en management semble approprié pour ça, et le fait d'avoir fait de l'info ne peut que plaire, et il parait, ça peut être intéressant financièrement... Le seul problème c'est de pouvoir démarrer dans ce milieu.

Merci de m'avoir lu et d'avoir pris le temps de me répondre!

[Drizzt [Drone38]]

Sinon concernant Scrum j'ai même l'impression que c'est à l'origine de beaucoup de bugs. En plus d'être stressant pour le développeur à cause de sous-chiffrage, ça incite à bacler le travail pour tenir les délais, même si après on va passer le double du temps à corriger.
Pour avoir parler avec des gens issues du monde du test, le test-driven-development est vraiment ce qui se fait de mieux, à mon avis ce serait une solution à privilégier, mais je vais éviter de braquer mon chef de projet alors que ma situation est encore jeune.

Tout dépend de comment tu mets en place ton Scrum. Que ça puisse être plus stressant oui, par définition en multipliant les cycles de livraison tu multiplies les moment de stress mais que ça fasse plus de bugs non, le problème est ailleurs.
D'ailleurs rien ne t'empeche (et certains vont même dire que ça va de paire) de faire du TDD en Scrum.