Comment être sûr de rater ton projet informatique

Comment être sûr de rater ton projet informatique

J’ai vu énormément de projets informatiques prendre feu et sombrer dans le chaos devant mes yeux. Aujourd’hui, je vais te donner la recette parfaite pour réduire en cendre tous tes efforts et ceux de ton équipe. Et oui tout brûle.



Un scope schizophrène

Au début d’un projet informatique, tu as une réflexion. Toi et tes collègues vous avez pris des gros cafés et vous êtes allés dans une salle pour faire des dessins et mettre tout ça sur papier. Bon et bien il faut que cette réflexion, ça soit bien de la merde. C’est super important, car c’est la base. Pour être sûr que ton projet informatique échoue, il faut que ton scope de départ soit flou et incomplet. Sors de cette réunion avec un post-it à la con et jette-le à la gueule du premier développeur qui passe en hurlant que c’est pour demain. C’est de loin le meilleur départ. Là déjà, t’es bien. T’as pas commencé t’es déjà en train de boxer ton projet dans les côtes. Mais ça suffit pas.

Ton scope et les features doivent bouger en permanence. Ça va être facile à faire si les bases de ton projet ne sont pas claires. Et là, il n’y a pas de règle. Lâche-toi ! Change tout. Ajoute des features, change-les au dernier moment, reviens en arrière et contredis-toi dans la même phrase. Pour être sûr que ton projet informatique échoue, il faut que ton scope évolue un maximum. Il faut que le scope soit complètement schizophrène du début à la fin. Gros apéro avant de toucher au cahier des charges, open-bar, danse du ventre, fait une chenille avec la direction : c’est important que tes changements ne fassent aucun sens.



scope


Je réinsiste sur le fait que les fondations de tout le projet doivent être bancales. Tu t’assures un résultat bien pourri juste avec cette méthode. Ça permettra également de maintenir un stress maximum tout au long du projet.



L’angoisse comme moteur

Là aussi, c’est vraiment une metric que tu dois surveiller et bien maintenir tout au long du projet. Pour être sûr que ton projet informatique échoue, il faut que tu génères et maintiennes un maximum de pression. Le faite de changer le scope en permanence est un bon début. Quand ton équipe de développement fini fièrement une feature tu vas les voir et SURPRISE on refait tout bande de cons. Si tu es manager transmets un maximum de ton stress à toute ton équipe. Si tu es développeur fais pareil avec les autres développeurs. Le but c’est que tout le monde prenne très cher.

Toujours dans cette optique de maintenir un niveau d’anxiété malsain, il y a un truc à faire tout de suite. Pour être sûr que ton projet informatique échoue, il faut que tu imposes une deadline de maboule. Ça, c’est de la kryptonite pour tout le monde. Tiens d’ailleurs, petite astuce. Il ne faut pas que ça soit pas l’équipe de développement qui fasse l’estimation de temps pour le côté technique. Ça aussi c’est central. Fais-la faire par quelqu’un qui ne connait rien aux technologies utilisées. Voir rien à la technique en général. L’estimation de temps doit être une énorme blague. Tout le monde doit être d’accord que la situation est intenable. Tout le monde, sauf la personne qui décide.



projet informatique


En tant que développeur, face à une situation pareille, tu vas immédiatement sortir ton cul pour coder. Normal, classique, on aime et surtout c’est primordial pour tout projet qui sombre dans le chaos. Comme la base du projet est bancale et que le scope est instable, très vite, les premiers problèmes techniques vont survenir. Et là, il y a une règle d’or.



Toujours blâmer les autres

Ce n’est pas ta faute ! Jamais. C’est la faute des autres. Pour être sûr que ton projet informatique échoue, il faut que personne ne prenne ces responsabilités. Il faut que tu sois toujours sur la défensive et hostile à la moindre remarque. Car le problème c’est que si tu acceptes la critique, à tort ou à raison on s’en fout, tu vas te concentrer sur comment régler le problème. Et du coup avec tes collègues vous pourriez faire des progrès ! Pour être sûr que ton projet informatique échoue, il faut que tout le monde se pointe du doigt. Plus personne ne travaille sur le problème vu que tout le monde est trop occupé à blâmer les autres. Le chaos est total et ton projet prend très cher.



projet informatique


Il y a bien longtemps dans une galaxie lointaine, très lointaine, j’ai bossé sur un microservice que je devais shipper dans un cloud managé en interne. Je te passe les détails de pourquoi, mais mon truc marchait pas. Plus exactement, il marchait pas dans ce système interne. Et c’était bizarre. De façon innocente, j’ai juste demandé à un seul dude par mail en privé s’il y avait d’autres cas avec les mêmes problèmes ou si j’étais un cas isolé.

Une semaine plus tard, pas de réponse. Moi pendant ce temps-là j’avais réglé mon problème de mon côté. C’était en effet bien moi qui faisais de la merde. Classique.

Mais ce que je savais pas c’est que j’avais déclenché une guerre entre trois équipes différentes. Le comportement de mon service ressemblait à du déjà-vu. Elles ont commencé à toutes se pointer du doigt par mail. Les mecs sont allés jusqu’à faire un ticket à Amazon directement ! Amazon, ils ont dû être morts de rire en voyant arriver le ticket. Une semaine de travail perdu. Aucune avancée et une mauvaise ambiance. Et cette situation a été possible car tout le monde travaillait de son côté.



Travailler en silo

C’est super fréquent dans les grosses boites. Y’a plein d’équipes qui s’occupent de plein de choses un peu partout. Toi, tu fais partie de l’une de ces équipes. C’est super important que tu refuses tout partage de travail et toute communication sur ce que tu fais. Pour être sûr que ton projet informatique échoue, il faut que tout le monde travaille dans son coin. Le mieux c’est quand tout le monde travaille un peu sur la même chose sans le savoir. C’est sublime quand on s’en rend compte des mois plus tard. On s’en rend compte des mois plus tard parce qu’on ne communique pas.

Pour être sûr que ton projet informatique échoue, il faut que la communication soit inexistante. Si tu dois retenir un seul conseil, c’est celui-là ! Aucune communication, zéro. Allez, à la rigueur, tu réponds à un email une ou deux fois par semaine. Envoie que tu es « trop débordé pour discuter » ça marche très bien ça. Et si tu croises des gens en vrai : regarde par terre ou genre fait demi-tour. Esquive un maximum les interactions.



silo


Il est également important de ne rien dire sur les problèmes potentiels que tu repères. Zero transparence. Quand tu vois un énorme problème, surtout garde-le pour toi. Zen, laisse faire. Pour être sûr que ton projet informatique échoue, oublie toute gestion des risques. Il faut faire croire jusqu’au bout que tout va bien même quand ça sent le brûlé depuis des semaines. Souviens-toi que c’est pas de ta faute. Ne commence pas à faire un état des lieux avec les zones obscures et à risques. Tu pourrais changer le cap et résoudre des problèmes rien qu’avec cette méthode. C’est facile à éviter quand tu n’as aucun process.



Aucun process, aucune norme

Les process de travail, les méthodologies et les bonnes pratiques tout ça c’est caca. C’est pour les faibles qui ne savent pas travailler en autonomie. Pour être sûr que ton projet informatique échoue, il ne faut appliquer aucun process et aucune norme. Oublie. Le problème c’est que ça permet à tout le monde de travailler de la même façon. Ça fait gagner du temps et tu injectes forcément de la stabilité dans ton projet. C’est pas bon ça ! Également, force tous tes développeurs à ne surtout pas documenter ce qu’ils font. Chaque bout de code doit rester un mystère pour ceux qui passeront dessus après. Et cette absence de process doit se ressentir également dans la façon de communiquer.

Pour être sûr que ton projet informatique échoue, il faut que les changements importants passent par mail ou à l’oral. Si t’arrives à noyer un changement de specs au milieu d’une chaîne de mail sans fin t’as des points bonus. Tu ne veux pas de source de vérité structurée genre Jira, Trello et autres. Surtout pas ! Parce que sinon tu peux plus sortir la carte : « non, mais si rappelle-toi on l’avait dit à telle réunion ». Et cette carte est importante, car elle va t’aider à expliquer que c’est jamais de ta faute.

Également, la qualité ne doit pas être un de tes objectifs. Je m’inquiète pas, ça va bien aller si tu n’as pas de normes. Ton seul objectif doit être de livrer quelque chose à temps. Peu importe l’état de ton projet. Peu importe l’état des équipes.



Mépriser l’humain

Pour être sûr que ton projet informatique échoue, tu dois recruter les mauvaises personnes. Il faut bien prendre des gens qui s’entendent pas ensemble ou avec l’entreprise de façon générale. Un seul mauvais recrutement peut mettre en péril tout ton projet. C’est beaucoup plus efficace que tu le penses. Insiste auprès de ton recruteur pour qu’il t’envoie des gens toxiques, ça va vraiment jouer dans la suite du projet.



toxique


Une fois que tu fais bosser des gens qui se détestent ensemble, tu n’as plus qu’à les exploiter un maximum. Pour être sûr que ton projet informatique échoue, il faut que tu méprises tout le monde. Y’a deux trois techniques pour être efficace là-dedans.

Dans le désordre tu peux obliger tout le monde à travailler minimum 60 H par semaine. Quand les gens n’auront plus de vie personnelle, c’est avec plaisir non dissimulé qu’ils vont chier à l’intérieur de ton projet.

Un petit « tu prends ton aprem? » quand quelqu’un part à 17 h c’est exactement ça qu’on veut. Toi, ça te coute rien de le dire, mais pour la personne qui reçoit la remarque c’est incroyablement désagréable. Tu peux aussi demander à un junior de faire un taf de senior en le payant comme une merde. Bref, méprise fréquemment un peu tout le monde et les gens vont péter des plombs.

Le Graal pour ton projet c’est quelqu’un qui fait un burnout. Ça n’a pas de prix. Si en plus c’est un mec qui s’est rendu indispensable JACKPOT ! Tu auras plein de gens indispensables car tu n’as aucune norme et aucune documentation. Ton projet finira alors sa course en enfer pendant que cette personne part avec un savoir critique pour le terminer.



projet informatique


Épilogue

Voilà, si tu appliques à la lettre tout ce que je viens de dire tu peux être sûr que ça va être une catastrophe ton projet. Beaucoup de projets font ça en partie et c’est pour ça que ça fail autant dans la tech. C’est sûr, y’a plein d’autres trucs à faire pour tout foirer. Tu as toujours les commentaires si t’en as un qui te vient.

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment, je suis développeur backend senior / DevOps à Montréal pour un géant du jeux vidéo. Le dev est l'une de mes passions et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cet e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

Pour me soutenir, la boutique officielle est disponible ! Sinon désactiver le bloqueur de pub et/ou utiliser les liens affiliés dans les articles, ça m'aide aussi.

36 commentaires sur “Comment être sûr de rater ton projet informatique”

  1. On peut aussi privilégier la novlang commercio-designeriste comme jargon pour les échanges techniques. Ca facilite grandement la communication et les réalisations des devs.
    Quand un dev reçoit une demande pour créer une interface « qui va transcender l’expérience utilisateur par une ergonomie innovante et transgressive », il comprends tout de suite ce qu’on attend de lui.

    1. Déjà qu’un dev reçoive une commande pour créer une interface c’est amplement suffisant, là ton exemple c’est vraiment du zèle 🙂

  2. Il faut pas oublier de toujours force merge ta feature, c’est les autres qui ne sont pas à jour vu que de toute façon t’es le seul à travailler sur ce projet ( de con ), d’ailleurs hier à 20h15 y’avait plus personne dans l’open space.

  3. @GIL Morgan : Au vu de la description de ton IHM, j’ai immédiatement imaginé un joystick en forme de ……
    Ce sera :
    – Transcendant, enfin cela reste à voir
    – Totalement innovant (Je n’en ai jamais vu sur le marché)
    – Transgressif à souhait
    – Et je rajouterai même fidèle à l’état du rédacteur des spécifications au moment où il a écrit celles-ci.

  4. « Tu peux aussi demander à un junior de faire un taf de senior en le payant comme une merde. » C’est tristement vrai, j’en ai fait les frais. C’est pas amusant comme situation. Bon article, on a tous à un moment ou à un autre vu ou vécu un de ces choses.

  5. + : Foutre un pecno toxique à la direction qui exige de l’équipe de ne pas faire de recette interne et livrer le client en l’état
    + : Apres la déflagration de la livraison : le même pecno se range coté client et insulte les techs en leur disant qu’ils devraient changer de métier, que l’info c’est pas pour eux
    + : recommencer et le laisser couler la boite…
    (vécu…)

  6. Marrant, mais un peu trop caricatural. Pour moi un projet de développement informatique voué à l’échec peut être simplement lié au fait qu’une fois en préprod, le client ne teste pas. Du coup tu as beau faire des documents de recette et autres, si c’est pas un client one shot, tu peux être sûr qu’à un moment où un autre tout ce qui n’a pas été testé par le client (toi tu as testé un minimum, c’est pas tant la question de la fiabilité du dév que de ses fonctionnalités) te revient dans la face genre « ah bon, quand on valide ce formulaire ça fait pas ça ? » et donc tout un tas de fonctionnalités qui n’ont pas été pensé au départ déboulent par « question de bon sens » 2 ans après la mise en prod…

  7. C’est le quotidien d’un ouvrier cérébral sans envier l’ouvrier à la chaîne de Renault dans les années 80 … le point commun : une prolétariat qui oeuvrent au service de la finance.
    Mais j’avoue avoir rit à quelques situations bien décrites. Du vécu. Je transfère à mes collègues, mais j’hésite à en sélectionner quelques un , de peur de froisser quelques sensibilité. Bravo pour l’article

  8. Je suis une ex-programmeure… J’ai été quelques années dans cette ambiance, à voir tout ça… sans avoir aucun mot pour l’expliquer! Merci du partage ! Ce fut très authentique 😉

  9. C’est du génie … Tout bonnement bravo 😍.
    « Tu peux m’insulter à cette e-mail ou le faire directement dans les commentaires juste en dessous. » : D’ac sac à merde j’ai pas hâte de retomber sur un article sorti de ton cul

  10. Excellent article, j’ai failli recracher mon café plusieurs fois.

    Je rajouterai le turnover monstrueux. Idéal pour se retrouver avec des développeurs qui ne savent même pas quoi faire.

  11. « Il ne faut pas que ça soit pas l’équipe de développement qui fasse l’estimation de temps pour le côté technique. »
    Il n’y a pas un pas en trop ?

  12. Je dois dire que le gif des deux personnes qui se courent après m’a bien fait rire, très juste.
    J’ai aussi vécu une mission courte, faut pas abuser des bonnes choses, où on livrait du moment que ça compilait parce qu’on ne savait pas du tout comment fonctionnait le framework utilisé. Bon faut dire que dans l’équipe le versioning de source se faisait avec winmerge. On a tenu 2 mois, ensuite 80 % de l’équipe est partie et je me suis bien marré sur la fin !

  13. Yo,
    T’as pas embauché un Business Analystics swinging like spiderman???

    Le meilleur cahier des charges de toute ma vie tenait en une phrase: « Imagine comment ce sera. »
    Non?

  14. Pas mal pas mal mais tu oublie deux éléments fondamental : utiliser un mix de technos différentes toutes a la pointe en mode snappshot. Double effet kisskool : seul les juniors connaissent (un peu) mais ils sont juniors et les anciens ça les gonflent de tout remettre en cause.
    Tu récupère une archi bancale et inadaptée et des dev seniors grognons !

    Pro-tip : pour capitaliser sur le point précédent embauche un jeune ingé hyper brillant et un peu méprisant et entoure le de juniors.
    Très vite il va partir dans ses délires, multiplier les techno et patterns ‘révolutionaires’ et larguer le reste de l’équipe. En plus ça fout vite une ambiance de merde. Puis bon quand on est brillant on ne documente pas et c’est toujours la faute des autres boulets. Bonus : comme il est brillant il va vite être recruté ailleurs, tu pourra tout reprendre de zéro, c’est 6 mois de gagné !

    1. Tout à fait d’accord sur le mix de techno. Les équipes commencent à peine à rentabiliser l’investissement en formation sur le tas (forcément) de l’ancienne « technologie d’avenir qui va tout renverser », il faut donc vite switcher sur le concurrent qui finalement est très bien aussi. D’ailleurs tiens, regarde les tendances 2022 des stacks les plus populaires, et y’a l’alternant payé au lance-pierre qui m’en a parlé lors du dernier copil-apéro.

  15. Autre point, constituer des équipes internationales qui ne maitrisent pas l’anglais et les forcer à s’exprimer en anglais, même lors des réunions locales. Une interprétation commune des décisions est un frein à l’échec, et une rédaction approximatives des docs est une parfaite entrave, tant pour les devs qui rejoignent le projet sur le tard que pour le client.
    Ne jamais archiver les dernières sources valides; y préférer une version de dev’ non testée, au cas où le projet serait ressorti du placard comme base de dev’ pour un projet ultérieur.
    Lors des points hebdomadaires, et pourquoi pas plus fréquents, PO-SI-TI-VER, toujours et exclusivement positiver en passant sous silence le moindre problème. Quelqu’un pourrait se piquer de corriger quelque chose à la volée.
    Et on en a vécu tant d’autres…

  16. J’ai les larmes aux yeux, cet article est magnifique. Il y’a encore beaucoup de conseils qui me viennent, mais je pense que le meilleur est déjà dit.

  17. Fait un cycle en V puis intègre l’agilité dedans. Tu fais des sprints de 6 mois avec des daily metings tous les mois pour chaque phase de ton cycle en V. Un sprint de specification, un sprint de dev, un sprint de test, un sprint de recette, etc…
    Met un process en place avec des documents à remplir, beaucoup de documents, sur papier. Il faut se focaliser sur la doc, il faut bien tester la doc. Il faut qu’elle soit parfaite, fait attention à ce que les marges soient bien à la norme que tu as passé 6 mois à écrire. Détaille bien la taille des polices dans le document et mets en place une équipe de QA pour la doc. Qu’elle vérifie bien si les marges sont correctes et que les méta données du document soient conformes. Dans ton process tu dois écrire au moins 500 pages de doc pour 2 lignes de code. Fait bien valider la doc par le client en plusieurs étapes avec beaucoup d’aller-retour. Si tu as bien cadré ton process normalement après 2 ans d’écriture et de validation de doc il doit rester environ 2 semaines pour le dev. Après 2 semaines de dev il est temps de remplis les documents de recette, de matrice de compliance et tout le tintoin. Assure toi que le client fasse bien son boulot pour valider les documents, mais qu’il teste pas le produit surtout. C’est les documents qu’il doit tester. Le client ne doit pas être utilisateur du produit, il doit juste valider le process et des normes. Si tu applique tout à la lettre tu peux envoyer le produit en prod pour les utilisateurs et si tout le monde a bien fait son travail le fail est assuré. Félicitation, tu as livré un produit bien bancal qui emmerde tout le monde et qui n’a aucun sens pour les utilisateurs 🙂

  18. Merci, c’est exactement ce que je vis maintenant depuis 2ans et demi … à une exception près :

    « Tu ne veux pas de source de vérité structurée genre Jira, Trello et autres. Surtout pas ! Parce que sinon tu peux plus sortir la carte : “non, mais si rappelle-toi on l’avait dit à telle réunion”. Et cette carte est importante, car elle va t’aider à expliquer que c’est jamais de ta faute. »

    Nous passons pourtant bien par un outil (Monday) mais voila, le client change d’avis sur ce qu’il veut, et même avec la preuve actée de ce qui avait été dit il faut tout refaire parce qu’il avait mal pensé le truc …

T'en penses quoi ?

Your email address will not be published. Required fields are marked *