Bonjour à tous et à toutes, aujourd'hui j'inaugure une nouvelle catégorie sur le blog : Tips & Tricks. L'objectif est de partager quelques apprentissages que j'ai pu glaner au cours de ma vie pro dans le digital. Il ne s'agit pas de vérités absolues mais d'expériences personnelles qui ont fait évoluer mon point sur telle ou telle chose. Il ne s'agit pas non plus d'une nouvelle méthode révolutionnaire pour gérer des projets en suivant le tout dernier manifeste agile mais de petites choses qui ne se trouvent pas forcément dans les discours policés et ficelés qu'on peut trouver mais j'espère que ça pourra aider quelques personnes, surtout les jeunes qui débarquent en entreprise.

Disclaimer : cette rubrique contiendra sans doute des exemples mais qui resteront volontairement vagues pour ne pas cibler une personne ou une entreprise précisément, pour les gossips désolé mais ce n'est pas le bon endroit.

Et pour bien commencer la série, parlons de l'échec!

Echouer ? Moi ? JAMAIS !

C'est quelque-chose qui va faire mal à certains mais vous allez échouer à un moment ou à un autre, c'est mathématique : vous ne pouvez pas prévoir l'ensemble des choses qui peuvent mal de passer. Quand je parle d'échec, il s'agit bien sûr de toute l'échelle possible : en tant que développeur j'ai bien sûr eu des bugs dans mon code (c'est la base d'ailleurs), en tant qu'architecte j'ai mal compris une demande du client, en tant que chef de projet j'ai une livraison qui a lamentablement échouée (on en reparle dans 2 minutes)
Et vous savez quoi ? Et bien ce n'est pas grave ! (tant qu'on ne cherche pas à échouer volontairement hein ^^). En revanche, ça se prépare.

La vision de l'échec

Quand on parle d'échec professionnel, on pense tout de suite au domaine entrepreneurial mais ça peut toucher tout le monde dans une entreprise. Chacun gère ses objectifs et les attentes de son management et ne pas les atteindre ou faire une erreur est un échec et chacun peut en ressentir du stress. C'est d'autant plus vrai pour ceux qui s'investissent beaucoup dans leur job et qui peuvent très mal vivre le moindre accroc.
La perception d'un échec est aussi liée à l'environnement culturel : en France on parle très peu des échecs, ils sont souvent rapidement mis sous cloche et oubliés pour passer à la suite alors que dans les pays anglo-saxons ils sont portés presque fièrement (certains investisseurs américains ne prêteront jamais à quelqu'un qui ne s'est pas déjà planté). Il y a peut-être un juste milieu à trouver entre ces 2 extrêmes non ?
Il ne faut pas avoir honte d'avoir échoué mais il faut en tirer quelque-chose. Se dire "oups, tant pis" ça ne suffit pas, l'important c'est comment on réagit à ce genre de situation. Par contre, en tout cas en France, ne commencez jamais par raconter votre plus beau fail lors d'un entretien d'embauche, c'est difficile de remonter dans l'estime de votre auditoire derrière (histoire vécue).

Deux exemples

Parce qu'on n'est jamais aussi mieux servi que par soi-même, je vous ai sélectionné deux exemples réels.

"Ah mais j'aurais pu te le dire dès le début que ça allait pas marcher !"

Quand j'ai entendu cette phrase de mon boss j'ai cru que le sol allait s'effondrer. Retour en arrière, quelques semaines avant : je dois mettre en ligne un nouveau site fourni par un éditeur de logiciel. Un membre de leur équipe technique doit venir faire l'installation avec moi, il vient d'Allemagne pour l'installation et la formation des utilisateurs. Je prévois d'installer le site dans le datacenter de la boite et je fais une demande en ce sens pour avoir un espace d'hébergement. Jusque là tout va bien. Le jour J arrive, l'installation s'effectue sans souci mais au moment de tester, impossible d'accéder au site car le serveur est en fait invisible depuis l'extérieur du réseau de l'entreprise. En fait je découvre dans l'après-midi qu'aucun serveur du datacenter n'est accessible depuis l'extérieur grâce à cette magnifique phrase de mon boss. Gros malaise vis à vis du technicien qui avait fait le déplacement et ouverture ratée pour le client.
Ce que j'en ai retenu : une incompréhension entre deux équipes a permis de rater un truc aussi gros et que ce n'est pas de suivre une procédure qui permet de s'assurer que tout se passera bien.

Le trou dans la doc

Autre projet, quelques années plus tard, autre problème. Le système était alimenté par une API externe envoyant des datas à intervalles réguliers. On s'attendait à du volume et on avait fait des tests de charge qui avaient tous été validés. Justement, afin de pouvoir traiter le volume attendu, nous avions fait le choix d'un traitement asynchrone avec mon équipe de dev. Sauf que notre source de données n'a pas d'environnement de test donc le dernier test sera en live. Le système a tenu environ 10 minutes ! Le souci c'est que dans la doc du système source il manquait une information capitale sur le temps de réponse maximum et la stratégie de retry de leur côté. En répondant en plus de 2 secondes à la data entrante (transfert de données compris), la source réessayait le même appel, créant un effet boule de neige. Il a fallu repenser les strates de traitement du système pour gérer ce cas. Ici aussi l'aspect culturel a eu un impact, mon lead dev voulait prendre sur lui l'entière responsabilité du problème et même à faire un message d'excuses, impensable pour moi.
Ce que j'en ai retenu : l'inconnu fait partie du jeu et on ne peut pas pas prévoir ce qu'on ne sait pas.

Il n'y a pas que la tech qui peut se rater

Ces deux exemples sont très orientés tech mais il y a tellement d'autres choses qui peuvent mal aller : un projet mal cadré dès le début qui n'aboutit pas à une application utile ou même pire, une application rejetée par les utilisateurs qui ne se sont pas sentis impliqués ou compris dans leurs besoins; un problème de communication entre 2 personnes qui fait diverger le besoin et le résultat ou encore une personne clé qui quitte le projet en cours de route...

Se préparer à échouer

Ce n'est pas parce que des échecs sont inévitables qu'il ne faut pas avoir des plans pour l'improbable. Il est important d'avoir un plan B, voire un plan C pour pouvoir réagir en cas de problème majeur. Le plus habituel est d'avoir un plan de retour en arrière, ce qui inclut les données et l'application. Toutes les stratégies de déploiement partiel, de tests sur de multiples environnements sont autant d'étapes pour se préparer mais qui ne représentent pas tout ce qui se passera une fois le projet lancé.
L'important, et même si cela peut être un poncif, ce n'est pas l'échec en lui-même mais la façon dont vous l'aborderez ainsi que ce que vous en tirerez.