Conseils pour éviter les projets pros foireux

Hello à tous,

J’ai été contacté pour un témoignage dans le cadre de ma reconversion professionnelle et, autant pour toute la partie réflexion, recherche de sens, etc. je maîtrise, autant je souhaiterais en profiter pour aborder un autre sujet qui me paraît important mais pour lequel j’aurais besoin de retours de personnes plus expérimentées.

Avant de changer de voie, je travaillais moi-même dans l’informatique et je pense que l’une des raisons (mineure mais existante tout de même) qui m’ont poussé à me poser des questions c’est que je bossais sur un projet que je qualifierais de « foireux ». En quelques mots : un système développé dans un langage (très) inadapté (PL/SQL…), maintenu soit par des gens sans aucune formation soit par des gens (très rapidement) formés mais juniors (genre moi) ce qui conduisait à des façons de faire inadaptées, instables, génératrices de bugs et de temps perdu et donc in fine de frustration. Tout ça sans compter le management qui était relativement désagréable.

Beaucoup de gens qui se reconvertissent se reconvertissent justement dans l’informatique et j’aimerais aborder sur ce sujet pour pour leur donner des clés afin d’éviter ce type de projet, un peu trop générateur de découragement à mes yeux.

Seulement je n’ai que mon expérience très limitée (1 an et demi dans un seul projet) et je trouve que c’est un peu léger pour pouvoir identifier des conseils pertinents. C’est pour ça que je me tourne vers vous et notamment vers des gens qui ont un profil senior (mais je reste preneur de tous les avis) : auriez-vous des conseils pour éviter ce type de projet foireux pour un junior qui débarque dans le domaine ? Des éléments dans la fiche de poste qui doivent interroger ? Des langages ou technologies à éviter ? Des questions à poser dès le processus d’embauche qui pourraient mettre sur la voix ? Des détails auxquels faire attention quand on visite les locaux de l’entreprise ? Ou alors est-ce que ça ne peut se voir que pendant la période d’essai ?

Faut-il éviter absolument les sociétés de service (comme le disent pas mal de gens) ou est-ce qu’on peut aussi trouver des projets intéressants dans ce type d’entreprise ?

Le sujet est essentiellement orienté informatique, mais si d’autres personnes ont des conseils similaires dans des sujets différents, ils sont les bienvenus également.

Merci à tous !

Faut-il éviter absolument les sociétés de service (comme le disent pas mal de gens) ou est-ce qu’on peut aussi trouver des projets intéressants dans ce type d’entreprise ?

Je n’ai jamais travaillé dans une société de service. Mon expérience s’est faite chez des éditeurs de logiciels ou en freelance.

Je peux déjà prétendre ceci : ce que l’on entend sur les sociétés de services, elles qui sont si décriées, je l’ai parfois hélas vécu chez les éditeurs de logiciels. Je ne pense pas, donc, que le travail chez un éditeur de logiciels soit une garantie de ne pas travailler sur des projets foireux.

En quelques mots : un système développé dans un langage (très) inadapté (PL/SQL…), maintenu soit par des gens sans aucune formation soit par des gens (très rapidement) formés mais juniors (genre moi) ce qui conduisait à des façons de faire inadaptées, instables, génératrices de bugs et de temps perdu et donc in fine de frustration. Tout ça sans compter le management qui était relativement désagréable.

Ce qui est décrit me rappelle le cas de ma première boîte, un éditeur de logiciels B2B. Une grande partie de la base de code a été amorcée par des stagiaires incompétents (ce qu’on ne peut leur reprocher, c’est bien normal), on se retrouvait à encore corriger leurs bugs et les conséquences de leurs choix encore des années après, ce qui nous pénalisait doublement :

• faire évoluer le produit pour être en adéquation avec les nouvelles attentes du marché nous était extrêmement compliqué, nous rendant par là même moins compétitifs ;
• les lacunes techniques apparaissaient aux clients, dont certains ont dû résilier à cause des bugs, des problèmes de performances, etc.

Aussi dois-je ajouter que l’entreprise avait une tendance à céder à chaque caprice des clients, ce qui est finalement compréhensible : ils menacent tous les quatre matins de résilier à cause des problèmes susmentionnés qu’on ne peut nier nous-même. La conséquence est commerciale, bien entendu, mais aussi technique : pour se plier aux caprices des clients, il faut faire ce qu’on appelle du développement spécifique. Concrètement ça ressemblait à ça :

if (client == 'Truc') {
    // faire des trucs spéciaux pour le client Truc (et rien que pour lui)
}

À long terme, cela accroît la complexité en fragilisant la base de code, elle qui est déjà endettée techniquement jusqu’au cou… C’est donc le cercle vicieux infernal…

Voilà donc l’exemple d’un projet foireux qui pourtant n’a pas vu le jour au sein d’une société de service.

auriez-vous des conseils pour éviter ce type de projet foireux pour un junior qui débarque dans le domaine ? Des éléments dans la fiche de poste qui doivent interroger ? Des langages ou technologies à éviter ? Des questions à poser dès le processus d’embauche qui pourraient mettre sur la voix ? Des détails auxquels faire attention quand on visite les locaux de l’entreprise ? Ou alors est-ce que ça ne peut se voir que pendant la période d’essai ?

Il y a des questions piège à poser en entretien qui permettent de déceler des signes. Mais certains recruteurs (les directeurs techniques, en fait) savent très bien embrouiller, attention !

Il y a des questions qui permettent de jauger la culture technique de l’entreprise. D’expérience, ce n’est pas le langage et les technos mais plutôt la culture et l’attitude générale qui importe. La vraie question qu’on veut élucider peut se résumer à l’unique suivante, je pense: Est-ce que les gens aiment le travail bien fait dans cette boîte, ou bien est-ce qu’il s’en moquent ?. Pour cela, je peux te conseiller de t’inspirer du Test de Joël pour connaître les questions permettant de le déterminer. Ce test n’est pas parfait, certaines questions ne s’appliquent pas toujours, ou bien la négation de certaines question n’est pas forcément un drapeau rouge selon l’activité et le contexte.

Pendant la période d’essai, tu devrais vite savoir si on t’a embrouillé pendant l’entretien ou pas. Il suffit de te reposer les mêmes questions.

Salut !

Alors, pour commencer je pense que face à quelqu’un qui veut se reconvertir, il faut d’abord énoncer un fait qui est à la fois contre-intuitif et parfois source de frottements : le développement, c’est un métier essentiellement humain, collaboratif et organisationnel. La qualité de la communication est très importante, parce que c’est d’elle que découle tout le reste.

L’important, quand on est junior, c’est d’être sur un projet sur lequel on peut grandir et apprendre des choses. Partant de là, un truc primordial, c’est de regarder la composition de l’équipe que l’on est susceptible d’intégrer :

• Quelle est la taille de l’équipe ? Une équipe qui marche bien c’est pas plus de 6–7 personnes, empiriquement
• Est-ce que je vais me retrouver au milieu d’une armée de 10 autres juniors ? C’est pas bon signe, le management et le coaching vont être soit éparpillés, soit du pur peer-reviewing par des gens sans expérience.
• Est-ce que je vais avoir un ou plusieurs seniors pour m’apprendre les ficelles et me guider ? Si oui, s’assurer que le courant passe et qu’on n’a pas l’impression qu’ils se la pètent. C’est important pour tous les postes, mais quand on est junior, c’est crucial : on veut évoluer dans une zone "ego-free", où on peut se sentir libre de faire des erreurs et d’être corrigé sans que ça soit une mauvaise expérience.

Pendant l’entretien, il faut voir quelles questions on nous pose. Pour un junior, a fortiori en reconversion, c’est normal de se faire tester sur ses compétences/connaissances techniques, mais ça ne doit surtout pas s’arrêter là. Quand on est recruté par des gens compétents, ceux-ci devraient normalement chercher à savoir :

• Si on communique bien et de façon compréhensible. Ça passe par des questions ouvertes et sympa : "est-ce que tu aurais réalisé un projet dont tu es particulièrement fier/fière et dont tu voudrais nous parler ?" Et la personne va ensuite creuser "qu’est-ce qui t’a plu ? Qu’est-ce que ça t’a appris ? Où est-ce que tu as galéré ? Qu’est-ce que tu en tires ?".
• Quels sont nos réflexes quand on est face à une difficulté ? Est-ce qu’on explique qu’on ne sait pas et qu’on va chercher de l’aide ou bien est-ce qu’on se renferme et que l’on reste bloqué ?
• Est-ce qu’ils posent des questions sur des trucs que tu connais pas encore mais que tu pourrais apprendre sur le tas ou en lisant la doc ? (Utiliser git, ou docker…) : Si oui, ils n’ont peut-être pas pensé correctement leur recrutement en se projetant avec un junior dans l’équipe, ou alors c’est pas ton profil qu’ils cherchent et t’es peut-être en train de perdre ton temps.

Autre détail important pendant l’entretien : si on est face à quelqu’un qui a une position d’encadrant et qui nous teste, est-ce que cette personne va avoir tendance à nous faire du feedback, notamment du feedback positif¹ ("c’est bien", "tu t’en sors bien", "ne t’inquiète pas, c’est un exercice difficile, tu te débrouilles bien", etc.) ? Avoir des retours réguliers sur son travail et pas seulement quand ça va pas, c’est hyper important, surtout au début où on est pétri d’incertitudes. D’une façon générale, c’est important de s’assurer que les gens sont dans un état d’esprit vraiment et naturellement positif, et pas juste qu’ils se forcent à être sympa.

Ensuite, c’est peut-être un peu moins important, mais il faut s’assurer que l’équipe fonctionne correctement. Pendant la période d’essai, ça peut se juger assez facilement sur la qualité des daily standups, notamment.

• Est-ce qu’ils font des standups (points quotidiens sur l’avancement) ?
  • Non: Oulà, est-ce qu’il y a de bonnes raisons ? Est-ce que les gens collaborent quand même ? Comment ils font pour savoir où ils en sont sur l’avancement ? Ou détecter les difficultés ?
  • Oui: C’est pas encore gagné. Il faut encore s’assurer que ce n’est pas une cérémonie creuse, mais une vraie réunion utile
• Est-ce que c’est des standups où tout le monde se contente de déclamer d’un ton monotone ce qu’il/elle a fait la veille, ce qu’il/elle compte faire aujourd’hui et ses obstacles, sans aucune forme d’interaction entre les gens ?
  • Oui: on est dans un cas de "management porn", le standup n’est utile que pour le manager. C’est pas très grave, parce que c’est difficile de sortir de ce pattern, mais c’est vraiment pas terrible.
  • Non, il y a des interactions: c’est bon signe.
• Est-ce que les gens passent autant (ou plus) de temps par semaine à se mettre d’accord sur la façon de s’organiser et sur les deadlines que sur le travail lui-même ?
  • Oui: Ça pue, très fort: cette équipe est en situation d’échec et a probablement jeté de l’Agile sur ses problèmes en espérant que ça les règle par magie. Sauve-toi !

Voilà, c’est à peu près tout ce à quoi je pense sur le moment. Je reviendrai si je pense à d’autres trucs à développer.

PS : Je précise au cas où, mais je pars du principe (dont je suis totalement convaincu), que quand tu bosses avec une bonne équipe, tu ne peux pas tomber sur un projet foireux. On pourrait le démontrer par l’absurde en tenant compte des deux axiomes suivants :

• Les développeurs compétents ne laissent pas un projet partir en sucette ou la dette s’accumuler jusqu’à devenir hors de contrôle, ou encore shifter vers de la prostitution pour garder les clients comme celle que décrit @sgble (j’ai connu une situation similaire).
• Si c’est hors de leur pouvoir, ils se barrent du projet dès qu’ils ont acquis la certitude qu’ils ne peuvent plus rien y changer, et donc tu n’as plus une bonne équipe.

Du coup, oui, la dynamique de groupe et l’attitude des développeurs est pour moi le meilleur indicateur que l’on puisse trouver sur la qualité des projets, avant même d’en regarder le code source.

Salut,

Attention à la techno utilisée tout de même: une fois que tu as acquis de l’expérience avec l’une d’entre elle, il est difficile (mais pas impossible) de te présenter à un job avec une techno complétement différente 5 ans après même si tu as étudié cette techno pendant ta formation.

C’est pas forcément vrai.

J’ai été embauché :

• sur mon tout premier poste en C++ alors que je sortais de la fac et que je n’avais fait concrètement que du C et du Java,
• sur mon second poste en Perl alors que je valorisais surtout une expérience en Python et en C++, d’ailleurs pour taquiner mon interviewer, j’avais résolu son exo en Haskell,
• des années plus tard, sur mon poste actuel, alors qu’il n’y avait marqué "Go" nulle part sur mon CV. Par contre, il m’a fallu montrer patte blanche en leur montrant que j’étais capable de faire un microservice web qui fonctionne en Go, en une dizaine de jours sur mon temps libre.

Là où ça bloque, c’est quand les CV sont pré-sélectionnés par des recruteurs qui connaissent rien à la techno et qui font leur matching sur des mots-clés, mais quand un recrutement est correctement préparé en amont, c’est heureusement rare.

Je pense notamment à une fois où je cherchais un profil junior pour venir développer en Python, et où on avait expliqué au recruteur que si le candidat ne connaissait pas Python mais qu’il avait déjà fait du C, du C++, du Perl ou du Ruby sous Linux, il n’aurait aucun problème à apprendre sur le tas du moment qu’il avait par ailleurs de bons réflexes en développement et qu’il avait envie d’apprendre Python. Et le candidat que j’avais finalement recruté était un débutant complet en Python, mais un junior super intéressant.

En théorie, je suis d’accord avec toi @nohar mais en pratique mon expérience n’est pas forcément la même que celle que tu décris malheureusement.

De plus ton profil n’a rien à voir avec celui de @Ekron: tu es quelqu’un d’expérimenté avec énormément de connaissances dans des domaines très technique alors que lui débute et commence sa vie active.
Aurais t’on donné une semaine à @Ekron pour faire un microservice web ? l’aurai t’on même reçu en entretien? (pour un poste junior évidemment)

J’ai édité. Je préciserais même que le seul poste sur lequel j’ai été recruté dans ma carrière avec un match parfait au niveau des technologies, est aussi le poste que j’ai le plus mal vécu humainement, et la seule boîte que j’ai quittée au bout d’à peine un an pour échapper à un burnout.

J’avais totalement négligé l’aspect humain dans ma recherche de poste. J’en ai tiré notamment plusieurs des leçons que j’explique plus haut.

Aurais t’on donné une semaine à @Ekron pour faire un microservice web ? l’aurai t’on même reçu en entretien?

Ben, clairement, quand j’aurai l’occasion de recruter pour monter une équipe à mon boulot actuel (en gros dès que les finances de la boîte le permettront), oui. Je sais que les premiers profils que je chercherai seront des juniors, je sais aussi que Go est un langage méconnu, donc je chercherai un profil junior que je challengerai techniquement en lui demandant d’implémenter un petit truc (en Go ou autre si la personne préfère me montrer ce dont elle est capable avec une autre techno) sur leur temps libre. Parce que c’est la seule façon pertinente de tester ce que je cherche : quelqu’un de souple qui sait apprendre pour servir un but.

Certes, les boîtes qui recrutent de cette façon dans la tech ne courrent pas forcément les rues (quoique c’est peut-être de plus en plus fréquent…). Celles qui prennent vraiment soin de leurs recrutements non plus, d’ailleurs.

Nous sommes d’accord
Personnellement, ma vraie première expérience pro m’a mis quelques battons dans les roues car après on ne me proposait que des missions (oui j’étais en SSII) similaires à celle que je venais de vivre alors que je l’avais quitté (ma décision et non une fin de mission) justement pour aller vers des technos différentes (plus moderne et plus recherché en l’occurrence)

C’est le problème des SSII en fait… et on en arrive un peu à la question d'@Ekron sur les sociétés de service.

Mon point de vue sur la question est très partial, mais dans ma vision des choses, les ESN/SSII sont à éviter quand on est junior complet et qu’on veut aimer son métier. C’est bien pour se faire de l’expérience quand on est déjà autonome et qu’on veut se faire un portefeuille de contacts, pourquoi pas dans l’optique de devenir freelance derrière, mais il faut retenir que la priorité des SSII, malgré tout le bullshit qu’elles peuvent inventer, n’est pas, n’a jamais été, et ne sera jamais de former des développeurs compétents et épanouis dans le métier qu’ils découvrent, là où c’est souvent dans l’intérêt des boites qui recrutent en CDI d’avoir (quitte à les former) des gens solides qui restent pendant des années. Leur priorité, c’est juste de placer des prestas dans des boîtes qui payent, et c’est ce qui ouvre la porte à toutes les dérives que l’on connaît.

Il y a des gens à qui ça convient. Tant mieux pour eux. Mais globalement, le résultat de l’opération est souvent médiocre.

Leur priorité, c’est juste de placer des prestas dans des boîtes qui payent, et c’est ce qui ouvre la porte à toutes les dérives que l’on connaît.

Mouais, ça dépend, je suis dans une SSII et je ne partage pas spécialement ce point de vue. J’ai l’impression que cela correspond aux grandes SSII, dites boucheries type CapGemini, Altran, Alten, etc. Ça correspond à l’immense parti du marché donc, mais il n’y a pas que cela.

Je travaille dans une petite SSII spécialisée, et j’ai des amis qui sont dans d’autres petites structures et l’expérience est tout autre. Car ces SSII pour survivre dans le milieu doivent avoir de vrais compétences, quitte à cadrer des juniors en interne pour monter en compétence. Car on ne va pas se mentir, le taux d’informaticiens incompétents (ou qui se foutent de tout) dans les grandes SSII est très élevé. Je pense même que cela peut être bien quand on aime varier les sujets ou découvrir pas mal de choses en peu de temps pour déterminer ses goûts propres.

Et l’ambiance est aussi souvent meilleure car tu connais mieux tes collègues (alors que dans une grande SSII tu les connais rarement, même ceux de la même agence que toi) et tu es plus parti prenante de l’avenir de la structure que dans les boucheries nationales qui vendent le kilo de temps d’ingénieur au kiloeuros.

C’est du moins l’expérience que j’en tire, je pense que de toute manière les grandes généralités concernant les SSII sont difficiles à faire. Cela dépend beaucoup des managers et des dirigeants la manière dont ça tourne, même dans les grandes structures cela peut être quitte ou double suivant sur qui tu tombes…

Merci @Renault de tempérer mon propos. Évidemment, je parlais surtout de ce que j’avais pu voir dans mes relations avec les grosses SSII, et je me doute bien qu’il y a des exceptions.

Pour ma part, j’avais eu un jour un contact avec une petite SSII spécialisée dans la vision par ordinateur/le traitement d’images et qui m’avait justement laissé l’impression d’être différente des autres, mais ça n’avait jamais abouti, donc je ne peux pas parler que de ce que je ne connais pas.

Je voudrais présenter une autre vision, plus rare, mais qui existe : je suis dans un projet que l’on peut qualifier de foireux, mais je le vis bien. Pour détailler, je fais du portage de logiciels opensource sous un OS propriétaire. C’est-à-dire que je récupère du code qui compile sous Linux, et je dois le faire marcher sous mon OS.

Techniquement, le projet a tous pour être à la ramasse : existe depuis plus de 15 ans, a servi à une époque à mettre au placard car il n’y a pas de deadline (donc ce n’est pas grave si les gens sont lents ou incompétents), approche qualité très récente (disons, 3 ans ; je suis là-bas depuis 1,5 an), on touche à tout donc on n’a jamais les compétences pour, travail partiellement dédoublé entre deux équipes, beaucoup de vieux logiciels à porter (on croise plus souvent du C89 ou du C++98 que du Go ou du Python — même s’il y en a), etc.¹

Objectivement, techniquement, on coche beaucoup trop de case du projet pro legacy, foireux, avec un historique encombrant. Sauf que…

• J’ai une autonomie proprement hallucinante (similaire à celle que j’avais en tant que doctorant !).
• On a 0 contrainte de temps…
• Donc on peut prendre le temps de faire les choses bien, et proprement (si on le souhaite).
• On touche à tout, donc on peut faire du ruby un jour et du C le lendemain. Et du SQL ensuite.
• Les problèmes qu’on rencontre vont du bug dans la libc ou le compilateur au fichier de configuration au mauvais endroit sur le système (peu de routine).
• Parfois, on a un vieux script bash pour Linux, un million de lignes de code, et un message d’erreur « Ça marche pas », et c’est à nous de jouer².

Au-delà du projet foireux, il y a l’équipe (dont @nohar a déjà parlé), et il y a ce qui nous intéresse. Ce dernier point dépend des gens, mais un projet peut être techniquement honteux, mais avoir plein de points qui nous conviennent.

C’est pour ça que je me fie surtout à l’environnement humain pour juger. Dans les faits t’es sur un projet qui a l’air vachement formateur, dans un environnement qui n’a pas l’air de te coller la pression et où on ne t’impose pas de faire des trucs qui te font te sentir sale.

Wow, un très grand merci pour vos retours ! Je ne réponds pas à tout, mais je note toutes vos remarques !

Voilà donc l’exemple d’un projet foireux qui pourtant n’a pas vu le jour au sein d’une société de service.

Oui, bien sûr, je ne voulais pas sous-entendre que tous les projets foireux devaient nécessairement voir le jour dans des sociétés de service, mais d’après les retours que j’ai eus, ils semblaient majoritaires dans ce genre d’entreprise. Manifestement, la suite des réponses me donne tort, et tant mieux.

Pour cela, je peux te conseiller de t’inspirer du Test de Joël pour connaître les questions permettant de le déterminer. Ce test n’est pas parfait, certaines questions ne s’appliquent pas toujours, ou bien la négation de certaines question n’est pas forcément un drapeau rouge selon l’activité et le contexte.

Merci, je ne connaissais pas ce test ! C’est un élément intéressant je trouve. Après, le projet sur lequel je travaillais devait être à 10 ou 11 sur 12 ce qui ne paraît pas si mal et pourtant…

Pendant la période d’essai, tu devrais vite savoir si on t’a embrouillé pendant l’entretien ou pas. Il suffit de te reposer les mêmes questions.

En effet, après toute la question est de savoir si on peut s’en rendre compte avant… C’est quand même déjà s’investir un peu que d’accepter un contrat de travail et ça rend le départ plus difficile.

C’est d’ailleurs une des questions que je me pose n’ayant pas eu l’occasion de le vivre moi-même : partir quand on n’est pas bien dans un projet informatique, bonne idée ou pas ? C’est pas trop difficile de retrouver du travail derrière avec une démission sur son CV ? J’ai l’impression que le domaine est assez dynamique et rend largement possible ce genre de choses, mais je me base sur à peu près rien…

Alors, pour commencer je pense que face à quelqu’un qui veut se reconvertir, il faut d’abord énoncer un fait qui est à la fois contre-intuitif et parfois source de frottements : le développement, c’est un métier essentiellement humain, collaboratif et organisationnel. La qualité de la communication est très importante, parce que c’est d’elle que découle tout le reste.

Effectivement, c’est un élément qui me semble primordial. J’avais lu quelque chose de cet ordre sur quelqu’un qui faisait le différence entre un codeur (qui écrit du code) et un développeur (qui fait la même chose, mais qui en prime s’assure qu’il soit maintenable, que son équipe a compris et est capable de prendre le relai s’il est absent, etc.).

Quelle est la taille de l’équipe ? Une équipe qui marche bien c’est pas plus de 6–7 personnes, empiriquement

Comment est-ce que tu définis la taille de l’équipe ? Par exemple, dans le projet où je travaillais moi, nous étions une dizaine de développeurs, deux ou trois chargés du déploiement (release manager de mémoire) et de divers scripts et 6 ou 7 business analysts. Et nous avions également des développeurs en Inde. Est-ce que tu compterais tout le monde ou seulement les développeurs ?

Autre détail important pendant l’entretien : si on est face à quelqu’un qui a une position d’encadrant et qui nous teste, est-ce que cette personne va avoir tendance à nous faire du feedback, notamment du feedback positif1 ("c’est bien", "tu t’en sors bien", "ne t’inquiète pas, c’est un exercice difficile, tu te débrouilles bien", etc.) ?

Comment tu arrives à déterminer ça pendant l’entretien ?

Est-ce que c’est des standups où tout le monde se contente de déclamer d’un ton monotone ce qu’il/elle a fait la veille, ce qu’il/elle compte faire aujourd’hui et ses obstacles, sans aucune forme d’interaction entre les gens ?

C’est marrant, parce qu’en vrai ça va précisément à l’encontre de tout ce que j’ai appris pendant mon projet. Nos standups étaient effectivement dédiés à ce que chacun dise ce qu’il avait prévu pour la journée, on pouvait réagir mais rapidement et dès que ça partait en débat, c’était classé en car park et ré-abordé plus tard (en théorie en tout cas). À quoi ressemble un bon standup pour toi ?

Ça pue, très fort: cette équipe est en situation d’échec et a probablement jeté de l’Agile sur ses problèmes en espérant que ça les règle par magie. Sauve-toi !

Alors ça pour le coup, ça résume complètement mon expérience avec Agile. Chacun essaye de mettre cette façon de faire plus ou moins en pratique soit parce que c’est à la mode soit parce que la hiérarchie l’impose, mais au final chacun le fait à sa sauce et ça donne rien. On se tapait une formation par mois avec un coach agile qui en savait pas bien plus que nous mais que était très fier de nous juger avec son langage incompréhensible et ses cartes star wars sur notre méthologie agile. Il y a vraiment des projets qui arrivent à la mettre entièrement en pratique et chez qui ça apporte une véritable plus-value ?

Si c’est hors de leur pouvoir, ils se barrent du projet dès qu’ils ont acquis la certitude qu’ils ne peuvent plus rien y changer, et donc tu n’as plus une bonne équipe.

Je ne sais pas honnêtement… J’ai vraiment l’impression d’avoir été dans un projet foireux (et je suis convaincu que si je vous en parlais en détails vous en seriez convaincus également) mais j’ai pas l’impression d’avoir des collègues incompétents. Bien au contraire, certains me paraissaient être de bons développeurs (après, je suis probablement pas le meilleur juge, je te l’accorde volontiers). Je crois qu’ils restaient parce qu’ils n’avaient pas envie de devoir de nouveau chercher du travail, certains parce qu’ils étaient internes dans la banque avec de l’ancienneté et avaient des avantages qu’ils ne voulaient pas perdre.

Attention à la techno utilisée tout de même: une fois que tu as acquis de l’expérience avec l’une d’entre elle, il est difficile (mais pas impossible) de te présenter à un job avec une techno complétement différente 5 ans après même si tu as étudié cette techno pendant ta formation.

C’est une question que je me suis posée en vrai… Et je me la suis posée bien après avoir été embauché ce qui tend à prouver que j’y suis sûrement allé un peu trop tête baissée. Je suis assez d’accord avec la réponse de nohar, mais j’ai l’impression qu’il y a quand même certains domaines où, une fois enfermé, il est plus difficile de sortir.

Je prends mon exemple une nouvel fois, ne croyez pas que je sois là uniquement pour cracher sur mon ancien projet (pas du tout), mais j’ai l’impression d’être précisément le genre de juniors à avoir fait le mauvais choix et c’est l’exemple que je connais le mieux.

Je travaillais sur un système bancaire et le but c’était de développer des modules (et de maintenir l’existant) de ce système dans un langage qui avait été créé pour. Le langage était franchement mal conçu, le modèle objet sur lequel il reposait était relativement inconsistant (désolé pour l’anglicisme, je ne trouve pas l’équivalent en français) et même le processus de release était particulier. Quand j’en ai pris conscience, j’ai vraiment eu l’impression d’être enfermé dans cette technologie et je ne pense pas que j’aurais pu valoriser quoi que ce soit de technique (je ne compte pas les autres acquis) dans un entretien qui n’aurait pas eu pour objet ce système.

Et d’ailleurs, ça se confirme plutôt : cela fait plusieurs années que j’ai quitté ce travail et repris mes études, mais je suis toujours contacté par des recruteurs pour des postes de consultant sur ce système, et jamais été contacté pour autre chose.

Leur priorité, c’est juste de placer des prestas dans des boîtes qui payent, et c’est ce qui ouvre la porte à toutes les dérives que l’on connaît.

J’avoue que je rejoins un peu la réponse de Renault en-dessous. Ma boîte de presta était clairement dans l’optique de vouloir placer au maximum ses consultants pour maximiser ses revenus, mais pourtant ils étaient assez attentifs au bien être des gens et faisaient en sorte qu’ils soient bien formés.

Au-delà du projet foireux, il y a l’équipe (dont @nohar a déjà parlé), et il y a ce qui nous intéresse. Ce dernier point dépend des gens, mais un projet peut être techniquement honteux, mais avoir plein de points qui nous conviennent.

Effectivement, c’est super intéressant (et ça change) comme point de vue ! Ça fait relativiser. Je vais garder les éléments qu’on m’a donnés pour repérer les projets foireux, mais je vais tempérer avec cet avis.

Merci beaucoup à tous, cette discussion est vraiment intéressante !

Quelle est la taille de l’équipe ? Une équipe qui marche bien c’est pas plus de 6–7 personnes, empiriquement

Comment est-ce que tu définis la taille de l’équipe ? Par exemple, dans le projet où je travaillais moi, nous étions une dizaine de développeurs, deux ou trois chargés du déploiement (release manager de mémoire) et de divers scripts et 6 ou 7 business analysts. Et nous avions également des développeurs en Inde. Est-ce que tu compterais tout le monde ou seulement les développeurs ?

Pour faire simple : le nombre de gens qui participent au même standup. La cellule de gens qui partagent la même responsabilité et collaborent entre eux pour ce faire.

Concrètement ça peut prendre plein de formes très différentes, ça peut être une équipe homogène, ou un squad qui regroupe plusieurs métiers (par exemple un front, un back, un ops, et un QA) et qui bossent sur un même service/une même fonctionnalité.

Autre détail important pendant l’entretien : si on est face à quelqu’un qui a une position d’encadrant et qui nous teste, est-ce que cette personne va avoir tendance à nous faire du feedback, notamment du feedback positif1 ("c’est bien", "tu t’en sors bien", "ne t’inquiète pas, c’est un exercice difficile, tu te débrouilles bien", etc.) ?

Comment tu arrives à déterminer ça pendant l’entretien ?

En général, quelqu’un de sensibilisé au feedback positif va forcément trouver une occasion pour te montrer pendant l’entretien qu’il en fait. S’il te donne un exercice, il va essayer de se montrer encourageant, etc. En fait il suffit de faire attention au feedback de la personne pendant l’entretien, qui souvent est révélateur de comment cette personne manage les gens.

Est-ce que c’est des standups où tout le monde se contente de déclamer d’un ton monotone ce qu’il/elle a fait la veille, ce qu’il/elle compte faire aujourd’hui et ses obstacles, sans aucune forme d’interaction entre les gens ?

C’est marrant, parce qu’en vrai ça va précisément à l’encontre de tout ce que j’ai appris pendant mon projet. Nos standups étaient effectivement dédiés à ce que chacun dise ce qu’il avait prévu pour la journée, on pouvait réagir mais rapidement et dès que ça partait en débat, c’était classé en car park et ré-abordé plus tard (en théorie en tout cas). À quoi ressemble un bon standup pour toi ?

Il faut un juste milieu entre les deux : si l’interaction peut résoudre la question en 30 secondes ou une minute, alors c’est inutile de faire une réunion derrière. Si on sent que le sujet est compliqué, alors en effet on évite de mobiliser les gens présents au standup pour rien et on ré-aborde le point plus tard. Mais c’est important que les gens puissent intervenir et se sentent libre de le faire, même si c’est pour conclure au bout de 2 échanges "ok je vois, ça va être un peu long, on en reparle juste après ?". La réunion doit servir à potentiellement tous les participants.

Un critère pertinent : si le manager est en congés, ça ne doit pas impacter le déroulement du standup, ni faire en sorte qu’il ait l’air bizarre ou inutile.

À propos de Agile :

Il y a vraiment des projets qui arrivent à la mettre entièrement en pratique et chez qui ça apporte une véritable plus-value ?

L’équipe la plus Agile avec laquelle j’ai bossé, c’est ma boîte actuelle où personne ne prononce jamais le mot "SCRUM", ni "Kanban", ni "Standup", ni "User Story", ni aucun mot du jargon Agile… en somme c’est une équipe dont le fonctionnement ressemble énormément à du SCRUM (des itérations d’une semaine, avec un point sur le planning en début d’itération et une démo/rétrospective à la fin et des standups tous les matins), sauf qu’il s’est mis en place de façon organique et naturelle.

Du coup, concrètement, je n’ai jamais vu des gens changer d’organisation pour adopter sciemment une méthodologie Agile et que ce soit un franc succès sur la durée, mais j’ai vu des gens faire de l’Agile de façon tout à fait spontanée et naturelle, et tout se déroule sans le moindre frottement, et c’est beau à voir.

inconsistant (désolé pour l’anglicisme, je ne trouve pas l’équivalent en français)

Incohérent.

Consistant, en français, ça peut vouloir dire solide, important, dans le sens « un repas consistant ». Et donc inconsistant, ça veut dire mou, fragile, qui manque de cohésion. Pour reprendre l’exemple du dico, un personnage inconsistant n’est pas incohérent, mais faible, sans personnalité.

Si le modèle objet était de bric et de broc, alors il était incohérent. S’il te faisait penser à de la gelée ou à un flan, il était inconsistant.

Je pourrais ajouter des tas de trucs à cette discussion, mais ça serait beaucoup de redites. Alors je vais appuyer des points qui me semblent importants.

Mon boulot actuel ressemble assez à la situation que décrit @Gabbro, dans le sens où c’est un projet antique¹ et a plein de contraintes issues de ça. Ça reste pourtant un projet avec des vrais challenges techniques (de performances, notamment) intéressants, et surtout la majeure partie de l’équipe de dev a une bonne attitude, a envie de faire du code propre et de faire avancer la base de code là-dessus, avec la direction qui réussit à débloquer du temps pour faire du nettoyage. Donc ça va dans le bon sens (pas 100 % de l’équipe, mais c’est jamais le cas sur les équipes un peu conséquentes, c’est à prendre en compte aussi).

Pour les SSII, j’ai longtemps fait partie d’une petite SSII qui était généralement en mode « on vends un service de qualité, pas juste de la viande » (bon les années de vache maigres, tu prends un peu les projets que tu trouves). J’ai des bons contacts avec une autre SSII de ce genre ici – utile si je veux me mettre en freelance un de ces 4.

Inversement, ma boite actuelle est une grosse entité qui fait SSII et éditeur (je suis dans la section éditeur). La section projet se gère comme une petite entreprise, ça se passe bien. Les services qui dépendent des entités supérieures, c’est moins terrible (la DSI par exemple est typique de l’inertie et des procédures d’une grosse boite), et la communication « groupe » semble complètement oublier qu’ils ont une section éditeur (et accessoirement que leurs employés ne sont pas tous des commerciaux obnubilés par les chiffres).  Mais ce qui est important au final, c’est surtout l’ambiance de l’équipe, des personnes avec qui tu vas travailler au quotidien.

Enfin, un point auquel on ne pense pas forcément, c’est l’âge de l’équipe. Ça peut être difficile de trouver des points communs et des sujets de conversation quand on a une forte différence d’âge avec le reste de l’équipe. Par exemple, je suis passé pour mon dernier boulot d’entreprises très jeunes où j’étais plutôt le senior, à une équipe où certains ont 20 ans de métier sur le produit et le connaissent sur le bout des ongles. Eh bien, ça fait très bizarre.

À ce sujet et pour finir, un point intéressant, c’est d’essayer de savoir si les anciens-qui-gèrent-le-projet font encore du développement de temps en temps (sur des points précis, quand c’est nécessaire, etc). Si le pilotage du projet a encore les mains dans le code, c’est souvent bon signe, parce que ça veut dire qu’ils vont peu avoir de demandes techniquement démentes.

Je ne sais pas honnêtement… J’ai vraiment l’impression d’avoir été dans un projet foireux (et je suis convaincu que si je vous en parlais en détails vous en seriez convaincus également) mais j’ai pas l’impression d’avoir des collègues incompétents. Bien au contraire, certains me paraissaient être de bons développeurs (après, je suis probablement pas le meilleur juge, je te l’accorde volontiers). Je crois qu’ils restaient parce qu’ils n’avaient pas envie de devoir de nouveau chercher du travail, certains parce qu’ils étaient internes dans la banque avec de l’ancienneté et avaient des avantages qu’ils ne voulaient pas perdre.

Ça, ça fait écho à un compromis que l’on fait tous, individuellement, dans tous les boulots : qu’est-ce que mon travail m’apporte vs. qu’est ce qu’il me coûte.

Il y a autant de réponses à cette question que de gens qui travaillent dans le monde, et la conclusion si le travail est acceptable ou non est également le résultat d’une démarche purement individuelle.

Pour citer ma propre expérience, je me suis retrouvé à un moment donné dans un projet qui est devenu foireux, parce que la moindre micro-tâche (changer une valeur en conf, ajouter un nouveau traitement) avait fini, par sédimentation, par mobiliser une demi-journée d’efforts là où elle prenait entre 5 minutes et une demi-heure au début.

L’environnement de développement était devenu un amas de modifications manuelles, à tel point qu’il n’avait plus rien à voir avec l’environnement de prod.

La configuration avait grossi sans que personne ne se pose la question de savoir si c’était encore pertinent de devoir gérer toutes ces valeurs à chaque nouveau projet, et si on n’aurait pas mieux fait de créer des outils pour générer ces confs. Dans les faits, les gens qui configuraient des nouveaux systèmes procédaient par copier-coller sans plus trop chercher à comprendre, à tel point qu’un beau jour, en me promenant dans le repo, je suis tombé sur des fichiers de configuration pour le dernier projet en date (< 2 mois), qui configuraient un morceau de code mort qui n’avait plus tourné nulle part depuis 5 ans.

On en arrivait à un tel niveau de prostitution pour gérer les particularités par client que l’on finissait par avoir deux ou trois programmes qui implémentaient la même fonctionnalité mais d’une façon différente, sans que jamais on n’eut pu dégager du temps pour repenser tout ça.

J’avais râlé pendant des mois et des mois pour réclamer du temps pour nettoyer tout ce merdier, refactoriser, automatiser la génération de conf, sans même parler d'anticiper l’avenir. La réponse classique que l’on m’opposait était que ça n’apportait pas une valeur immédiate parce que ça ne répondait à aucun besoin des clients (et en plus on arrivait à argumenter ça en dévoyant des concepts Agile, pour se donner plus de légitimité). Mes collègues ne semblaient pas s’en offusquer. Ils perdaient un paquet de temps mais "c’était pas nouveau" : la dette technique s’est amassée tellement lentement, tellement sournoisement, tellement progressivement, qu’ils se sont retrouvés presque immobilisés sans s’en rendre compte. Ça m’a demandé de leur énoncer factuellement la liste des micro-trucs qu’ils faisaient entre le moment où ils décidaient de changer une valeur de conf et celui où le changement finissait mergé dans master pour qu’ils réagissent en prenant conscience du fait qu’ils gaspillaient une quantité d’énergie ahurissante.

Un beau jour, la situation s’est débloquée et le management a commencé à planifier des tâches de remboursement de la dette technique. Je venais tout juste de poser ma démission, et ils essayaient de me donner une raison de rester.

C’était trop tard. J’étais épuisé et je n’avais plus qu’une envie, qui était de me tirer de là et d’aller bosser sur un projet où j’aurais pas à me battre pour avoir le droit de rendre l’air respirable.

PS : Le bon côté des choses, c’est que ça m’a permis d’affiner pas mal d’outils indispensables à la survie en milieu informatique hostile :

• Mon détecteur de bullshit a connu 3 ou 4 nouvelles versions majeures en 2 ans, il est même capable de détecter maintenant le bullshit auquel les gens qui le déclament ont fini par croire !
• J’ai appris à reconnaître des tonnes de fausses bonnes idées et les classifier par type et par degré de sournoiserie,
• J’ai développé un véritable amour pour le code ennuyeux, par opposition au code expressif,
• …

Plus sérieusement, c’est surtout ce genre d’expérience, de gros échecs et de trucs foireux qui nous font grandir en tant que développeurs : les échecs ont cet avantage sur les success stories qu’ils nous font bien plus réfléchir et progresser pour en tirer des leçons sur ce qu’il faut ou ne faut pas refaire.

Il faut un juste milieu entre les deux : si l’interaction peut résoudre la question en 30 secondes ou une minute, alors c’est inutile de faire une réunion derrière. Si on sent que le sujet est compliqué, alors en effet on évite de mobiliser les gens présents au standup pour rien et on ré-aborde le point plus tard. Mais c’est important que les gens puissent intervenir et se sentent libre de le faire, même si c’est pour conclure au bout de 2 échanges "ok je vois, ça va être un peu long, on en reparle juste après ?". La réunion doit servir à potentiellement tous les participants.

Un critère pertinent : si le manager est en congés, ça ne doit pas impacter le déroulement du standup, ni faire en sorte qu’il ait l’air bizarre ou inutile.

Oui d’accord, les standups que j’ai vécu n’était probablement pas si mauvais dans ce cas.

Mon boulot actuel ressemble assez à la situation que décrit @Gabbro, dans le sens où c’est un projet antique et a plein de contraintes issues de ça. Ça reste pourtant un projet avec des vrais challenges techniques (de performances, notamment) intéressants, et surtout la majeure partie de l’équipe de dev a une bonne attitude, a envie de faire du code propre et de faire avancer la base de code là-dessus, avec la direction qui réussit à débloquer du temps pour faire du nettoyage. Donc ça va dans le bon sens (pas 100 % de l’équipe, mais c’est jamais le cas sur les équipes un peu conséquentes, c’est à prendre en compte aussi).

Là aussi, comme ce que disait @Gabbro plus haut, c’est vachement intéressant. Finalement, la direction que veut prendre l’équipe semble au moins autant si ce n’est plus importante que l’aspect du projet.

Mais ce qui est important au final, c’est surtout l’ambiance de l’équipe, des personnes avec qui tu vas travailler au quotidien.

Enfin, un point auquel on ne pense pas forcément, c’est l’âge de l’équipe. Ça peut être difficile de trouver des points communs et des sujets de conversation quand on a une forte différence d’âge avec le reste de l’équipe. Par exemple, je suis passé pour mon dernier boulot d’entreprises très jeunes où j’étais plutôt le senior, à une équipe où certains ont 20 ans de métier sur le produit et le connaissent sur le bout des ongles. Eh bien, ça fait très bizarre.

Ça rejoint ce que disait @nohar sur l’importance de l’équipe et l’aspect finalement très humain et communication du métier. C’est effectivement un point qui me semble parfois sous-estimés par de jeunes diplômés parfois un peu trop enthousiasmés par une technologie à la mode ou un salaire attirant.

À ce sujet et pour finir, un point intéressant, c’est d’essayer de savoir si les anciens-qui-gèrent-le-projet font encore du développement de temps en temps (sur des points précis, quand c’est nécessaire, etc). Si le pilotage du projet a encore les mains dans le code, c’est souvent bon signe, parce que ça veut dire qu’ils vont peu avoir de demandes techniquement démentes.

Effectivement. J’ai vécu ça moi-même avec un N+2 sans connaissance technique mais qui passait outre ma N+1 pour nous soumettre directement des demandes fantaisistes…

@nohar je crois que je vois ce que tu veux dire et je comprends mieux le PS de ton premier message du coup.

Finalement, la question qu’on pourrait se poser, c’est de savoir quoi faire quand on se rend finalement compte qu’on bosse dans un projet foireux ? Essayer d’arranger les choses, ça paraît relativement évident, mais si on fait face à une inertie trop importante, est-ce une bonne idée de démissionner ?

On m’a souvent répété que c’était facile de retrouver du travail en informatique, mais est-ce vraiment le cas ? Est-ce qu’on est obligés de faire des concessions, notamment au niveau du salaire ? Est-ce que ce n’est pas mal vu par un éventuel autre employeur ?

Plus sérieusement, c’est surtout ce genre d’expérience, de gros échecs et de trucs foireux qui nous font grandir en tant que développeurs : les échecs ont cet avantage sur les success stories qu’ils nous font bien plus réfléchir et progresser pour en tirer des leçons sur ce qu’il faut ou ne faut pas refaire.

Ça par contre, ça m’embête un petit peu plus. ^^'

Tout l’intérêt de ma démarche c’était de trouver des clés pour essayer de mettre en garde les jeunes développeurs contre les projets qui ont l’air attrayants mais qui finalement ne le sont pas. Est-ce que tu penses que c’est une erreur ? Il vaudrait mieux les laisser se faire leur propre expérience quitte à se tromper ?

Finalement, la question qu’on pourrait se poser, c’est de savoir quoi faire quand on se rend finalement compte qu’on bosse dans un projet foireux ? Essayer d’arranger les choses, ça paraît relativement évident, mais si on fait face à une inertie trop importante, est-ce une bonne idée de démissionner ?

Oui. S’il n’y a plus rien à faire pour améliorer son quotidien, et que ça commence à détruire notre motivation, c’est la seule chose à faire : chercher un autre poste et s’en aller. On passe 5 jours par semaine au travail, ce n’est pas pour y laisser la santé ou le moral. D’autant qu’en info, y a du boulot, le marché est plus favorable aux candidats qu’aux entreprises qui recrutent, et ce n’est pas vraiment mal vu de rester peu de temps dans une boîte : des gens qui cherchent des développeurs, y en a partout.

On m’a souvent répété que c’était facile de retrouver du travail en informatique, mais est-ce vraiment le cas ?

J’ai fait l’expérience la première fois que j’ai changé de boulot. J’avais peur de ne rien trouver, alors j’ai posté mon CV (de dev junior) sur une plateforme généraliste de recherche d’emploi (monster.fr). Il s’en est suivi deux semaines de harcèlement téléphonique : on m’appelait 5 à 10 fois par jour pour me présenter des postes. Souvent pourris, souvent inadaptés, souvent des SSII, mais toujours est-il que pour quelqu’un qui veut bosser, il y a de quoi faire, et si on n’est pas démesurément exigeant qu’on se laisse pas mal de portes ouvertes, il y a en fait l’embarras du choix.

Pour ça, en info, il faut savoir se vendre : on peut parfaitement se vendre en faisant figurer des projets amateurs sur le CV qu’on envoie à une boîte, avec un lien vers un dépôt GitHub d’un de nos projets Open Source, pour montrer qu’on connaît le métier/la techno et qu’on ne part pas de rien, même si ça ne rentre pas dans la case "officielle" des expériences pro. Ça montre qu’on en veut, ça suffit à faire figurer les mots-clés qui vont bien pour passer le barrage des RH qui n’y pigent rien, et quand ce genre de CV tombe sur le bureau d’un tech lead, celui-ci ira normalement jeter un oeil à ces projets, ne serait-ce que par curiosité.

En tout cas, c’est ce que j’ai toujours fait pour évaluer les CV : j’aime bien lire du code pour comprendre comment pensent les gens.

Un autre élément sympa en info, surtout quand on se reconvertit, c’est aussi de présenter son expérience sur un petit portfolio sur le web, dans lequel on peut mettre en valeur ce que l’on a à apporter aux entreprises.

Est-ce qu’on est obligés de faire des concessions, notamment au niveau du salaire ?

Ça dépend des situations. Je pense que le seul cas dans lequel on peut voir son salaire baisser, c’est quand on change de région et qu’on vient de Paris (où les salaires sont globalement plus hauts), ou bien quand on change complètement de domaine de compétences… Mais en dehors de ça, en règle générale, il faut toujours demander au moins ce que l’on touche actuellement.

Est-ce que ce n’est pas mal vu par un éventuel autre employeur ?

Ça aussi, c’est un truc qu’on s’imagine couramment en début de carrière : si on demande trop, est-ce que ce sera mal vu ? La vérité, c’est que si un employeur trouve un profil intéressant mais trop cher, il lui fera quand même une contre-proposition. Il ne faut pas hésiter à demander un peu plus que ce que l’on pense valoir. Je n’ai jamais entendu parler d’un candidat qui aurait raté une belle opportunité parce que l’employeur aurait pris peur en entendant ses prétentions salariales.

Tout l’intérêt de ma démarche c’était de trouver des clés pour essayer de mettre en garde les jeunes développeurs contre les projets qui ont l’air attrayants mais qui finalement ne le sont pas. Est-ce que tu penses que c’est une erreur ? Il vaudrait mieux les laisser se faire leur propre expérience quitte à se tromper ?

Attention, il faut relativiser. Quand on cherche un premier boulot, il vaut vraiment mieux chercher un bon projet avec des seniors sympa pour nous former et nous servir de mentors.

Il faut aussi savoir capitaliser sur les mauvaises expériences (qui sont généralement très riches en enseignements, plus que les succès), mais ça ne signifie absolument pas qu’il est obligatoire de galérer ! À choisir, il vaut quand même mieux être peinard dans un bon poste.

Je rajoute, personnellement j’y connais rien au secteur de l’info, ma remarque est donc générale, que c’est très important d’apprendre à reconnaître un mauvais environnement. Ça permet de se rendre compte qu’il faut partir avant que ça nous mette trop mal, parce que j’en ai déjà vu plusieurs à qui c’est arrivé. Et réussir à rationnellement le comprendre, ça aide à s’en relever aussi, je pense.