Les bonnes surprises, c’est pas tout le temps

Notre staff temporaire a posé sa démission. Les bonnes surprises, c’est pas tout le temps. Elle n’aura pas tenu 2 mois. (motif: “j’y comprends vraiment trop rien”)

Je m’étais fait une raison sur sa présence, mais j’avoue, l’annonce de son départ m’a grandement soulagé. Il faut au moins 1 an pour pouvoir se rendre utile chez nous (dans mon équipe), et 2 ans pour bien devenir efficace. L’attente ne m’enchantait guère.

Ma N+1 a donc aussi quitté l’équipe, puisque la condition de son départ dans une autre équipe était que l’on trouve un staff temporaire pour la remplacer. C’est très ironique tout ça; la N+1 veut partir, on pose comme condition de trouver un temporaire, on en trouve une, le départ de la N+1 est confirmé, et la temporaire pose sa démission!

Accessoirement, chez nous, quand on a un budget pour un employé (permanent ou temporaire), le budget est lié à la personne en question. Quand la personne arrête, on perd le budget de son rôle. Donc quand quelqu’un arrête, on peut pas le remplacer. Les budgets pour embaucher sont très rares, celui qu’on avait eu pour la temporaire il y a deux mois était un peu exceptionnel, donc a priori, on peut faire une croix pour son remplacement.

On était 12 dans mon équipe il y a 3 ans. On était 6 il y a 5 mois. On sera 3 à partir de fin juillet.

Pour le nombre de projets, on en avait une centaine d’actifs à tous moments il y a 3 ans. Ça oscille entre 100 et 150 aujourd’hui. Il y a 3 ans, je trouvais que j’avais beaucoup de temps libre au travail, ça nous permettait de faire un bon suivi client entre autres choses. Aujourd’hui, ça commence à devenir dur. Le temps que j’accorde à chaque projet a évidemment bien diminué.

Le problème n’est pas vraiment le nombre d’heures supp car on n’en fait pas outre-mesure. Le problème est dans la complexité du travail. Les trois dernières années ont été rudes dans le changement des process, ça devient juste impossible de suivre tous les changements. Si en plus on nous mettait une grosse pression en interne, je n’ose pas imaginer les résultats… tu m’étonnes qu’il y ait eu des vagues de suicides dans quelques grosses boites en France.

Pertes de temps

Nos projets doivent être complétés à une date qu’on appelle DDNC: Date Dūe Négociée avec le Client. Le nom est traître, puisque le client n’a pas son mot à dire et en est même informé après coup. Le DDNC est (par exemple) le 4 Septembre 2014, c’est nous qui décidons, point.

Elle est facile à calculer, elle consiste en la date de livraison standarde donnée par le cablo-opérateur + 2 semaines pour tout le reste. Evidemment, ça ne veut pas dire que tout le travail en dehors de la ligne WAN est fait en 2 semaines, puisque qu’on le fait en parallèle du travail fait pour la ligne WAN. C’est juste qu’on a deux semaines standard pour installer le routeur et faire toute les config/tests.

Ratez le DDNC, et c’est la ca-tas-tro-phe. Ça monte trois crans au-dessus de moi (senior Director), et ça redescend aussi vite sur votre gueule via le téléphone.

Quand on rate le DDNC, il faut “coder” le projet avec un code retard. La liste des codes est longue, mais ce qui est vraiment important au final est de savoir de qui est la faute: notre boite, ou le client.

On a le management qui regarde chaque semaine un rapport qui liste tous les projets de la planète qui ont dépasssé le DDNC, avec leur code. On a une target de 0% pour les DDNC dépassées avec notre boite comme responsable du retard.

Pour résumer:
Règle numéro 1: ne pas rater la DDNC
Règle numéro 2: si on la dépasse, il ne faut pas que ce soit de notre faute

Bien sûr, les disputes de responsabilités sont nombreuses, mais heureusement ma division n’est pas trop impliquée; une fois qu’on a codé le projet, les  commerciaux ne peuvent que faire appel au high management pour contester, pas à nous.

Tout va globalement bien jusqu’à ce qu’un jour un directeur décide que les DDNC sont trop longues. “Quoi? 89 jours pour un site en Ethernet au Japon? Non, c’est abusé, on va la mettre à 74 jours.”. Sur quoi s’est-il basé pour prendre cette décision, mystère. Il devait sans doute regarder un rapport sur le temps de complétion des projets, et il voulait l’améliorer. (accesssoirement, la division qui est en charge de surveiller les stats de temps de livraison des circuits par les cablo-opérateurs et de négocier avec eux a hurlé quand elle a été mise au courant après coup.)

La règle “DDNC = temps de livraison du circuit par le cablo-opérateur + 2 semaines”: passée aux oubliettes. Mais du coup, on n’a plus aucune chance de livrer dans les temps. Et ça, c’est inacceptacle pour le management.

Il y avait un process qui existait et qu’on utilisait rarement: le DCE (Date de Complétion Etendue). Le DCE était utilisé quand un opérateur livrait son circuit en retard. On utilisait le process du DCE dans 5% des projets. Il s’agissait concretement de lancer une requête d’extension du DDNC au management (avec détails), qui transférait à un manager régional en charge du DCE, qui allait dans les systêmes changer une date DDNC-bis. Un projet qui dépasse le DDNC mais ne dépasse pas le DDNC-bis n’est pas compté comme un échec dans nos stats.

Temps total perdu par requête DCE: 20 minutes. Pas énorme, mais multipliez par quelques milliers de projets annuellement, et on arrive à des mois/années de temps de travail perdu (étalé sur plusieurs chefs de projet). Parce que maintenant, un bon pourcentage des projets suivent le process DCE.

Et tout ça pour quoi? Pour qu’un directeur A soit content de voir que tous nos projets sont “livrés en heure”. Pour qu’un directeur B soit satisfait d’avoir “écourté” nos temps de complétion des projets.

Nous, le temps que ça nous prend pour finir un projet n’a pas changé. Rien n’a changé pour le client. Rien n’a changé pour le cablo-opérateur. On perd 10 minutes par projet, le management aussi. On perd un temps de travail affolant sur l’année.

Faites ce genre de changement de process 3 ou 4 fois par an. Insérer de nouveaux directeurs dans le management qui auront chacun leur vision de quel rapport est important et quel rapport ne l’est pas, et qui ajouteront des nouvelles règles selon le temps qu’il fait. A la fin, on prend 10 fois plus de temps qu’il n’en faut pour boucler un projet, avec aucune valeur ajoutée pour qui que ce soit. Ça devient terriblement difficile de se motiver parfois.

Nouvelle collègue

On a un nouveau membre dans mon équipe. La cinquantaine, intérimaire, n’a jamais fait d’informatique (elle ne sait pas ce que c’est qu’une adresse IP)… pas facile de la former pour devenir chef de projet dans les réseaux WAN. Perso, je prie pour qu’elle quitte ce job le plus vite possible, mais on va pas lui mettre de bâtons dans les roues. Les bonnes surprises, ça existe. Des gens qui d’un coup se mettent à travailler beaucoup pour x raison, et qui arrivent à passer outre le gap de leur ignorance pour réussir à faire un bon boulot. Ça arrive souvent au Japon. Je dois bien dire que beaucoup de Japonais sont très flexibles, genre ils commencent un boulot pour lequel ils n’ont aucune formation ou connaissance, et au bout de quelques années, ils font un bon boulot.

Ça commence dès la sortie de l’université. Seule une infime partie de mes collègues sort d’une université scientifique, et encore moins d’informatique; 10% peut-être? J’ai vu des experts Cisco qui quelques années auparavant sortaient d’une fac de littérature anglaise…

Après, il faut bien dire que les nouveaux diplômés Français ne savent rien faire de plus que les nouveaux diplômés Japonais. Ce n’est que mon expérience personnelle et c’est très empirique/subjectif, mais grosso-modo, par exemple dans une boite d’info, un diplômé d’informatique Français ne sera pas meilleur qu’un Japonais diplômé de civilisation espagnole. Oh, il donnera plus le change au début, ce sera plus facile de parler de trucs techniques avec le Français et il comprendra mieux nos blagues, mais après un ou deux ans, il n’y aura plus de différence (sauf au niveau des blagues, mais bon, les Japonais et l’humour Français, c’est comme le sucré-salé en cuisine). Le Japonais va s’adapter et bucher comme un fou pour rattraper son retard et aller plus loin la plupart du temps.

A 50 ans, beaucoup de Japonais sont toujours prêts à se réorienter et apprendre de nouveaux trucs. Le truc bien pour eux, c’est que beaucoup d’entreprises sont prêtes à leur donner leur chance. Et ça marche souvent bien…

(Ai-je besoin d’écrire que les contre-exemples de tout ce que je viens de raconter sont nombreux?)

N’empêche que ma collègue de 50 berges là, qui doit se coltiner sa formation? Moi et mes collègues. Et c’est du lourd. Encore, les trucs bien spécifiques à notre secteur, genre expliquer ce que font les cablo-opérateurs, le cablage des immeubles, les astuces et nuances des différents types de ligne et options de service, etc., ça va, c’est amusant et motivant même pour moi de l’expliquer.

De devoir expliquer que non, tout ne tourne pas tout seul et que chaque merde qui arrive dans le projet peut nous être reprochée à nous (et non pas au connard à l’autre bout de la planète qui a fait la boulette). Que oui, des merdes arrivent tous les jours, c’est un peu ça notre boulot: fossoyeur de merde, on gère les emmerdes quoi! Et il en arrivent de toutes sortes, des gens pas motivés en face, des trucs qu’on sait pas encore qui a merdé ni comment réparer, des systèmes qui délirent, des gens en vacances, des clients irrascibles qui n’ont pour but dans le vie que de rendre la nôtre misérable, etc. Un classsique dans ce secteur d’activités, c’est les telecoms quoi! Mais pour quelqu’un qui n’y a jamais travaillé, c’est comme si elle avait imaginé le pays des bisounours et qu’elle se retrouve avec une bande de hobbits au pays de Sauron.

Son premier projet, une implémentation d’un site à Singapour, deux routeurs, deux lignes. Le gars en charge de la commande des lignes au cablo-opérateur qui la contacte pour lui demander si les lignes sont en path-diversity, c’est à dire si le cablo opérateur doit utiliser deux lignes physiquement distinctes à partir du rack du client jusqu’au centre telecom (le but étant d’avoir le service continuer si il arrivait un accident à l’une des lignes). Après vérification sur le devis, oui, il faut du path-diversity. Alors elle lui a répondu que oui, le devis avait d’ailleurs été pris en ce sens.

Réponse du gars des commandes: ouais mais non, l’opérateur dit que c’est pas possible qu’il ait fait un devis pour ça à ce prix. Il demande aussi de vérifier que le commercial a bien pris un devis pour du path-diversity.

Alors là, perdue notre petite nouvelle:
Mais, je lui ai dit hier que j’avais regardé le devis…
Mais, pourquoi l’opérateur dirait qu’il n’a pas donné ce prix…
Mais, comment on va faire…

Réponse: j’en sais rien du tout, mais comme on peut pas parler avec l’opérateur en direct, contentes-toi de répondre à la question. “Oui, le devis est pour du path-diversity, en voici la preuve”. Et on va attendre la réponse. Si le gars des commandes et l’opérateur ne donnent aucune piste quant à ce qui a bien pu se passer, on contactera le gars qui a fait le devis pour le confirmer.

Alors c’est normal que notre petite nouvelle ne sache pas tout ça et on ne lui en veut pas, mais ça n’enlève rien au fait que ça soit ultra-gonflant pour nous. En fait, on perdrait moins de temps à faire tout le travail nous-mêmes, mais dans deux ans, si elle devient opérationelle, alors à ce moment on y gagnera beaucoup plus de temps que si on avait continué à faire le job nous-même. Une sorte de placement sur l’avenir en fait.