Là où je sévis actuellement, un document interne secret à visée caustique recense ces termes et d’autres ; la liste qui suit s’en inspire librement, avec d’autant moins de scrupules que je suis à l’origine des deux tiers d’entre eux.

- Levier : solution en général fictive mais rhétoriquement commode pour faire croire ou se persuader qu’on a des moyens d’action. Nous avons identifié les leviers à notre disposition pour raccourcir les délais.

- Paralléliser : recours ultime lors d’une négociation de planning, dont le but – fantasque – est de diviser linéairement les temps de production par le nombre de ressources affectées. Voir le post consacré au sujet.

- Pragmatique (ou sa variante réaliste) : attitude consistant à sacrifier la qualité tout en se défendant de le faire.

- Proactivité : technique de management pragmatique consistant à demander au collaborateur de résoudre les problèmes à venir sans les connaître à l’avance.

- Proposition (force de) : Nous attendons que vous soyez force de proposition. Façon aimable qu’a le client de demander au prestataire de faire son travail à sa place.

- Temporiser : pour le client, indique qu’il n’a pas encore pris le temps de trancher les choses dont vous avez absolument besoin pour avancer sur un livrable qu’il exige pour demain. Pour le prestataire, signifie que les développements qui devaient commencer hier avec trois ressources commenceront la semaine prochaine avec une demie. Doit toujours cependant être utilisé dans une phrase qui laisse penser que tout cela est parfaitement volontaire. Nous avons décidé de temporiser.

- Tiroir : dans la vraie vie, élément coulissant d’un meuble ; dans une proposition commerciale, élément coulissant du devis exigé par le client pour se donner les moyen de faire baisser le montant total. Pouvez-vous me faire une proposition à tiroirs ? Attention : dans la pratique, le client choisit toujours de conserver des tiroirs qui ne peuvent être réalisés sans ceux qu’il a retirés.

- Transverse : notion à utiliser en biais ; bien commode pour camoufler son ignorance du contenu exact d’une intervention. Nous avons mobilisé des compétences transverses.

- Valeur ajoutée : concept à utiliser sans parcimonie dans tout discours de vérité (voir ci-dessous). Cette fonctionnalité n’a pas de valeur ajoutée.

- Vérité (discours de) : stratagème circonlocutif, destiné à obscurcir le sens de ce qui est dit sous couvert de transparence (on dit également : « enfumer »). Fonctionne également comme prétérition, pour tenter de rester poli : je vais te tenir un discours de vérité, ton code c’est vraiment de la merde.

Bien entendu, toute ressemblance avec des phrases ayant été prononcées dans la vraie vie serait étonnamment fortuite, etc, pardon aux familles tout ça.

__________________________

Superbes illustrations trouvées fortuitement chez Getty Images.

Quand vous faites partie du second groupe, ou quand vous travaillez dans le développement d’applications, vous apprenez rapidement qu’il existe, au-delà de l’heure, du jour, de la semaine, une unité de mesure capitale : le jour-homme.

Je me dis depuis quelque temps qu’on pourrait même entériner un nouveau mot : le « jourhomme », que la réforme de l’ortografe transformerait en « jourome », et ça serait sympa. Sans parler bien sûr du jourfemme qui devra exister impérativement. Mais je m’égare.

Comme son nom l’indique presque, le jour-homme correspond au travail d’une personne pendant une journée. Ca fait beaucoup rire nos amis anglo-saxons de nous voir utiliser une telle mesure qui passe sous silence toute discussion éventuelle sur la valeur du référent… Il nous faut alors leur expliquer que par chez nous, la durée « officielle » d’une journée de travail est de 8 heures, même s’il s’agit en fait d’une durée admise comme standard – avec toutes les élasticités bien commodes que ça implique, et qui permettent de faire au besoin rentrer deux « jours » en une journée (ben oui, il suffit de travailler de 8h à minuit, fastoche).

Quand on estime une charge de travail, on la chiffre donc en jours-homme.
En général, on colle ça après dans un calendrier (avec ou sans l’aide de certains logiciels pas lourds du tout dont le nom commence par « pro » et se termine par « ject »), et ça nous donne un planning, autrement dit une représentation dans le temps de la vie des vraies gens, week-end et autres jours chômés inutiles pris en compte.
Il est étonnant de remarquer à quelle vitesse on finit à force de faire cet exercice par penser en multiples de 5, et par assimiler 1 mois au chiffre 20 (ce qui est par ailleurs souvent inexact, mais bon, à la louchasse, c’est ça). On met en général plus de temps à intégrer comme un réflexe le calcul inconscient de marges de sécurité conséquentes (de 20 à 50%).

Toujours est-il qu’à l’arrivée, on présente au client un planning, dans lequel il ne regarde en général qu’une seule date, celle de la livraison. C’est le moment où il fait des grands yeux, voire devient livide, voire s’énerve, voire tout ça en même temps ou dans un ordre aléatoire.

Mais, tenez-vous bien, ça n’est pas grave. Pourquoi ? Tout simplement parce qu’on va pouvoir optimiser le planning. Et c’est quoi la solution magique pour optimiser le planning ?

Oui, vous avez trouvé : la parallélisation.

La parallélisation, c’est cette bonne idée qui consiste à dire qu’on va mettre plusieurs gars sur le coup (ou filles, hein, enfin si seulement on en avait dans l’équipe de développement), et que paf par magie ça va linéairement diviser le temps de production par le nombre de ressources affectées. En gros (si vous êtes un peu malcomprenant), s’il y a 60 jours-homme, en mettant deux développeurs, ça va être fait en 30 jours.

Jusque là, je n’aurais presque rien à dire. C’est presque vrai, c’est même presque malin, voire presque réaliste. Sauf que vous connaissez les gens : il leur en faut toujours plus (les coquins). Donc vas-y que jte mets 4 développeurs et c’est torché fait en 15 jours ! Vous voyez venir l’écueil (enfin, j’espère, c’est pas faute d’être lourdement didactique) : tant qu’on y est, mettons 60 développeurs, et ce soir c’est plié.

Sans parler de l’incongruité en termes d’écosystème (essayez de regrouper 60 développeurs et vous comprendrez), on a évidemment oublié un détail dans cette équation, trois fois rien, un mot innocent : la ré-a-li-té.

Eh oui. Dans la réalité, répartir la charge induit très vite des « coûts » collatéraux, notamment en coordination du travail. S’il est souvent envisageable de séparer les tâches en plusieurs lots, il n’est pas dit qu’ils puissent être, d’un point de vue logique, tous réalisés en parallèle.

C’est chiant, la réalité, ça marche pas toujours comme les maths ; par exemple, un lapin plus un lapin, pour peu qu’ils soient de sexe différent, ça a vite des chances de faire plus de deux lapins. Vous me direz : ah mais il s’est passé quelque chose.  Mais justement, ce qui est caractéristique de la réalité, c’est qu’il s’y passe des choses, et qu’il y a des contraintes qu’on ne peut pas réduire, même si on est très bon en maths.

J’aime bien recourir à une image qui fait en général son petit effet. Elle n’est pas de moi, je crois l’avoir trouvée quelque part dans un machin imprimé, un livre, là, mais je ne retrouve pas la référence, et Google est curieusement un peu muet sur le sujet. En la sortant au bon moment, le résultat est garanti :

Si on met 9 femmes enceintes en parallèle, on n’aura pas un enfant en 1 mois.

Si vous faites bien vos devoirs, vous ne devez toutefois pas prendre cette superbe saillie pour argent comptant, et questionner l’analogie (n’est-ce pas). En d’autres termes, demander si développer une application, c’est comme faire un bébé (je vous passerai toutes les bonnes blagues auxquelles ça peut me faire penser, sinon on va y passer l’hiver).

Soyons prudent sans faire de la langue de bois : oui, il y a dans les processus de développement des étapes, qui ne peuvent que s’enchaîner et donc pas avoir lieu en même temps. Il faut pour cette raison ne pas hésiter à affirmer que :

• le temps nécessaire n’est pas linéairement divisible par le nombre de ressources affectées ;
• l’augmentation du nombre de ressources accroit de manière exponentielle les tâches de coordination, et tend pour cette raison très  rapidement à annuler le gain de temps nominal (voire à l’inverser, c’est-à-dire à faire perdre plus de temps qu’on en gagne).

Selon les métiers et les projets, le point de la courbe où la tendance s’inverse est plus ou moins vite atteint, mais d’expérience on constate qu’il l’est toujours plus vite que ce qui serait nécessaire pour satisfaire des plannings irréalistes. Et le plus difficile, c’est de le faire comprendre aux « décideurs » (car les coupables ne sont pas toujours les clients, si si…)

D’où les 9 femmes. Ça n’est pas magique, mais ça peut avoir son poids dans une argumentation.