Le bon et le mauvais cholestérol

Je vais commencer cet article par une anecdocte 😁 d’un de mes anciens DG.
Lors d’une réunion de tous les services dans notre open space, il avait déclaré : « les prestas, c’est comme le cholestérol, il faut en avoir, mais pas trop ».
C’était maladroit, ça n’a pas plu à l’audience. Pourtant, c’était juste et cet article va tenter d’expliquer pourquoi ¹.

L’informatique, plus qu’un outil au service du business ?

Si ce titre est à la forme interrogative, c’est que cette question n’est pas si évidente que ça et qu’y répondre positivement ou négativement va conditionner la suite de cet article.

Je prends le parti d’écrire avec un prisme sur l’histoire propre des organisations et leur positionnement vis-à-vis des « nouvelles technologies ».

Un premier courant regroupe les entreprises anciennes qui considèrent que l’informatique est au service de leurs modèles économiques historiques. Ici l’innovation est plus rare qu’un trèfle à quatre feuilles, comme si avoir rebaptisé la DSI, DSSInnovation n’avait eu étrangement aucun effet.
Le second courant vit l’informatique comme un élément au cœur de sa chaine de valeur, en général, elle a créé des produits que seules les innovations technologiques, comme le web, ont pu rendre possible.

Dans la première situation, on va généralement considérer le développeur comme un exécutant qui n’a pas de grande connaissance métier. Tout le système sera organiser autour de cette idée : éloignement maximal du développeur et du métier/business, multiples intermédiaires pour traduire les demandes métiers ou dans le meilleur des cas les problèmes rencontrés par les utilisateurs finaux. On est également dans le genre de contexte ou les rôles comme product owner ou product manager n’ont pas de consistance et sont posés sur les anciens rôles de MOE toujours pleinement joués ou pas, comme au temps jadis. Pas ou peu de discussions auront lieu entre les développeurs et leurs plus proches représentants métiers pour diverses raisons comme l’impossibilité d’adapter la solution aux besoins. La distance communicationnelle est trop forte pour prendre rapidement une décision et malheureusement les incompréhensions iront directement dans le code puis dans le produit. La boucle de rétroaction, lol, c’est-à-dire, le feedback est trop long, absent.

Dans la seconde situation, le rôle de product owner est joué, la prise de décision rapide a lieu quand l’incompréhension ou l’imprévu émerge. On évite ainsi les mauvaises surprises au dernier moment, le pire pour s’adapter.

Où réside la connaissance métier ?

Dans notre premier modèle, on a la croyance que la connaissance métier n’existe que dans l’esprit ou les artefacts du métier/business. On a vu dans la partie précédente que le produit devient une somme de fonctionnalités, mais aussi d’incompréhensions, d’inconsistances, souvent réglées à coup d’exceptions dans le code ou de connaissance informelle partagée dans l’équipe de développement : « attention à cette partie du code, ça ne fait pas vraiment ce que c’est censé faire… ».
On pourrait à la limite s’en sortir avec beaucoup de difficulté et une croyance forte dans la transmission intacte de connaissance verbale, mais ajoutons à cela un remplacement fréquent et endémique des effectifs des équipes…

C’est là où je voulais en venir, un prestataire par essence est amené à partir plus tôt qu’un interne (sauf exception 😅). Quand il quitte l’organisation, c’est une partie de la connaissance du fonctionnement de votre produit qui s’en va. Quand sur une équipe de 10 personnes, 6, 7 ou 8 prestataires terminent leur contrat en même temps, c’est quasi toute la connaissance du produit sur lequel ils travaillent qui vous dit au revoir.

Moralité : « les prestas, c’est comme le cholestérol, il faut en avoir, mais pas trop » si vous voulez construire/maintenir un produit ou service de qualité bien entendu. 😛

1. Les bénéfices d’une équipe stable ne sont plus à démonter, que le contexte soit « agile » ou traditionnel, en termes de performance, comme de coût.