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.

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.

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.

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.

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.

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.

É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.