Mener un projet Proof of Concept (PoC) sur un sujet ou une technologie non maîtrisée : mission impossible pour un business analyst Telys ?

Lors de ma dernière mission chez un éditeur juridique, j’occupais le poste de Product Owner, rôle qui nécessite de s’imprégner des connaissances fonctionnelles et se mettre à la place de l’utilisateur. Mais quand dans le cadre d’un nouveau projet, on vous demande de plonger dans la tête de l’architecte système ou du développeur, ce n’est pas simple et c’est même déroutant ! C’est cette expérience particulière que je veux partager avec vous.

Le contexte :

Figure 1 : schéma de la chaine de production et publication

Les rédacteurs produisent des articles, revues et autres codes juridiques commentés. Ce contenu est transmis à une équipe Back Office qui se charge de mettre le tout en forme et de le publier. Le Front Office développe et maintient des sites (en Angular, ce framework qui permet de créer des applications web dynamiques et immersives) capables d’aller chercher ce contenu et de l’afficher.

L’objectif de cette activité est de fournir aux clients et prospects une information à jour, disponible, structurée avec une expérience utilisateur toujours à la pointe. Il y a donc nécessité d’améliorer en continue les technologies, qu’elles soient physiques (entrepôts de données, serveurs…) ou logicielles (gestion de base de données, langage utilisé). De plus, 21ème siècle oblige, le référencement par les moteurs de recherche est également une priorité.

Parmi les parties prenantes, les métiers (Pôle Numérique Editorial) liés au Back Office et les architectes système se mettent d’accord ! « Il faut faire évoluer la base de données ». C’est ainsi qu’émerge l’idée de regrouper tous les fonds documentaires sur une même base de données, adieu les back office spécifiques ! Ils profitent de la création d’un nouveau site dédié exclusivement à la publication d’actualités pour avoir une idée révolutionnant le système existant : « pourquoi ne pas migrer la publication des contenus de type Actualités sur cette nouvelle architecture ? » Uniformiser les données provenant de part et d’autre et alimentant les différents Fronts, ne plus avoir un Back Office qui colmate des erreurs de conception mais qui retourne à ses véritables fonctions. Tels étaient les rêves qui étaient alors enfin à portée !

Il fallait donc quelqu’un pour mener ce projet à bien, et j’ai eu la chance qu’on me confie cette responsabilité. En tant que PO Front Office avec un vernis technique très léger, j’allais être amené à faire face à plusieurs difficultés :

  • interagir non pas avec des métiers majoritairement, comme à mon habitude, mais uniquement avec des architectes système et des développeurs,
  • suivre un sujet qui ne peut pas se résumer à ce qu’on observe sur un écran, mais nécessite de comprendre ce qu’il se passe au cœur de la base de données.

Les objectifs de ce projet d’étude du point de vue des architectes système étaient les suivants :

  • interfacer une nouvelle base de données supplémentaire contenant les informations constituant les articles de type « actualité », avec les Fronts existants développés en Angular,
  • prendre en compte les problématiques d’indexation du contenu, provenant non plus d’une seule mais d’une seconde base de données,
  • en profiter pour extraire les fonctionnalités associées à la lecture d’articles, comme la gestion du menu et autres paramétrages, du Back End monolithique actuel en un nouveau Back End plus petit et qu’on puisse organiser en réseau d’API.

1re phase : CADRER LE PÉRIMÈTRE

Mes interlocuteurs étant architectes système et développeurs, lors du premier atelier, j’étais submergé de termes techniques et notions obscures. Cependant, tout cela est beaucoup plus facile à comprendre et assimiler lorsque c’est schématisé. Me voilà donc à tracer des diagrammes et schémas, et m’en servir pour guider mon questionnement. Par exemple, pour représenter les flux de données, quoi de mieux qu’un diagramme de … flux ?

Figure 2 : schéma d’un diagramme de flux

 Se posent alors naturellement les questions suivantes :

  • Quelles données transitent ?
  • Sous quelle forme ?
  • Depuis quelle source ?
  • Vers quel destinataire ?
  • Comment ce destinataire reçoit les données ?
  • Comment il les traite ?

Creuser le besoin, lever les flous, impossible de le faire sans avoir une stratégie de questionnement, sans reformuler à bon escient. Cela a permis de comprendre que la demande sous-jacente des métiers ne concernait qu’un certain type de contenu, ce qui a évité des investissements chronophages, coûteux et inutiles.

La modélisation en diagramme de processus de l’architecture existante, puis la cible, a permis de s’assurer auprès des architectes que la demande était bien saisie. Les problématiques étant avant tout techniques (flux de métadonnées, interprétations, référencement) et complexes (plusieurs équipes, un acteur extérieur pour la conception de la base de données, plusieurs maisons d’édition à fédérer), la représentation graphique était un atout crucial pour harmoniser les compréhensions des parties prenantes.

Rédiger les attentes de toutes les parties prenantes sous forme d’exigences autoporteuses, priorisées et testablespermet de bien comprendre et partager les objectifs et le déroulé du POC.

Pour résumer, les modélisations et schémas réalisés en amont, les exigences phrasées et claires m’ont permis à la fois de challenger les parties prenantes et d’expliquer correctement le projet à l’équipe en charge de la réalisation du POC.

2nde phase : REALISER LE POC

Ce qui a été fait en phase d’analyse a beaucoup facilité la réalisation : les hypothèses posées, les exigences structurées, les cas d’usages explicites et les objectifs priorisés ont guidé les développeurs dans les tâches à accomplir.

Les techniques appliquées dans la phase de cadrage sont utilisées de la même façon pour comprendre ce que chaque développeur fait afin de formaliser chaque hypothèse, condition, remarque ou limite.

EN CONCLUSION :

Sans avoir un vernis technique, j’ai été en mesure de piloter et mener à bien un POC sur un sujet complexe (du moins pour mon niveau) et technique, en me reposant sur des compétences en :

  • communication : questionner de manière structurée, de manière à s’approprier le sujet et à comprendre le besoin profond, en utilisant notamment la modélisation,
  • formalisation : rédiger de manière ordonnée, structurée et illustrée par des schémas et diagrammes permet d’avoir une restitution claire et construite.

Somme toute, chaque métier est technique, possède son propre jargon. Ici, le métier était celui des systèmes d’information. La méthode d’approche ne change donc en rien et s’adapte à n’importe quel contexte métier.

Ainsi, si vous êtes face à un sujet de ce genre et que vous avez besoin d’un PO pour le mener à bien, pas besoin de chercher le fameux mouton à cinq pattes ! Une personne motivée et bien formée aux techniques de business Analyse est tout à fait en mesure de répondre à ce genre de situation. Et d’ailleurs…. je serai disponible bientôt 😊

Quentin

Partager l'article :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *