Thread by @SciamVox

Votre « modèle d’objets métier » et pourquoi c’est important.

Un #Thread par @ordrespontane

@ordrespontane Sur 100 projets de développement de logiciel (typiquement des applications internes développées pour les besoins spécifiques d’une organisation) et selon le Standish Group (les rapports CHAOS de 1994 à 2020), on observe ce qui suit :

20 sont des échecs. C’est-à-dire que le projet est annulé en cours de développement ou que le logiciel n’est finalement pas utilisé parce qu’il ne correspond pas aux besoins de son commanditaire.

50 sont en difficulté : dates de livraison repoussées, budgets qui explosent, logiciels livrés incomplets (il manque des modules / fonctionnalités) ou une combinaison de plusieurs de ces symptômes.

Le solde, 30, ce sont donc les succès : le logiciel est livré à temps, le budget est respecté et le produit final contient tous les modules et fonctionnalités qui avaient été prévues à la commande.

Par ailleurs et pour compléter ce tableau déjà peu engageant, ces taux n’ont pratiquement pas évolué depuis une bonne vingtaine d’années et le taux de succès diminue considérablement avec la complexité des projets entrepris.

Il y a bien sûr de nombreux facteurs qui peuvent expliquer l’échec ou la mise en difficulté d’un projet : manque d’engagement de la direction, incompétence technique des développeurs, changements d’avis intempestifs…

Mais le cas le plus fréquent se résume à un problème de communication entre deux groupes d’individus.

À ma gauche, le métier. Ce sont généralement des représentants des futurs utilisateurs du produit qui sont chargés de définir les spécifications, c’est-à-dire ce que le logiciel est supposé faire, le « Quoi ».

Le métier, en principe, ce sont des professionnels qui connaissent parfaitement leur activité et les besoins qu’elle génère mais qui, en revanche, n’ont généralement que très peu de compétences en matière de développement informatique.

À ma droite, les développeurs. Ce sont souvent des prestataires externes qui, sur la base du « Quoi » évoqué ci-dessus, ont pour mission de définir et d’implémenter des choix techniques, le « Comment ».

Les développeurs, notamment lorsqu’ils sont des prestataires externes, sont des experts de la programmation qui, au début de la mission, ne connaissent rien au métier et n’auront le temps d’en comprendre que quelques bases superficielles.

Or, le succès de votre projet tient en très grande partie à la capacité qu’ont ces deux groupes aux compétences et aux langages très différents à communiquer entre eux de façon fluide, efficace et non-ambiguë.

Une façon de traiter le problème, c’est l’intermédiation : on désigne une ou plusieures personnes chargées de traduire les besoins du métier de telle sorte que les développeurs aient l’information dont ils ont besoin pour travailler.

Les difficultés liées à cette approche, évidemment, sont celles qu’on rencontre dans toutes les formes de communication intermédiée : erreurs d’interprétation, pertes d’information et beaucoup de temps perdu en va-et-vient entre les deux groupes.

Raison pour laquelle il me semble que la meilleure façon de faire consiste à établir un cadre qui permette au métier et aux développeurs de communiquer directement et ce, sans avoir à absorber toute la technicité de leurs spécialités respectives.

C’est à ça que doit servir un « modèle d’objets métier » : du point de vue du métier, c’est une façon simple de formaliser un sujet qu’ils connaissent parfaitement et qui, par ailleurs, les contraint à être aussi précis et exhaustifs que possible.

Du point de vue des développeurs, c’est exactement le niveau d’information dont ils ont besoin : le modèle leur dit ce qu’ils doivent faire (le Quoi) sans à aucun moment préjuger de la façon dont ils doivent le faire (le Comment).

Un « objet métier », par exemple, c’est la notion de « Product ».

Question : quelles sont les différentes propriétés qui permettent de caractériser vos différents produits : nom, code externe, classification etc.

Pour un même « Product », il est vraisemblable que vous ayez plusieurs prix (par devise, par date de validité etc.) — ce qui nous amène donc à créer un objet « Prices » qui représente la liste des objets « Price » attachée à cet objet « Product ».

Et ainsi de suite. Votre modèle d’objets métier, c’est l’ensemble de tous ces objets conceptuels et des relations qui les lient les uns aux autres.

C’est une façon de travailler qui peut sembler un peu verbeuse, surtout au début et ce d’autant plus qu’il est très peu probable que votre premier jet soit parfait : il faudra y revenir régulièrement pour améliorer et corriger le modèle.

La contrepartie, c’est que vous maximisez vos chances de voir votre projet aboutir en temps et en heure et de respecter le budget initial. Ce à quoi s’ajoutent deux autres avantages auxquels on pense trop peu.

Le premier, c’est qu’en incitant le métier à repenser dans le détail toute son activité, cet exercice est une formidable façon d’améliorer vos process et même très souvent d’en créer de nouveaux — c’est-à-dire d’innover.

Le second, c’est qu’à la livraison de votre logiciel vous disposerez d’une équipe qui connait parfaitement son outil et se l’est entièrement approprié ; ce qui, en matière de conduite du changement, est tout simplement la situation idéale. #Fin