Management,  Projet Décisionnel

Conception : Spécifications des restitutions (ce que j’envisage de vous proposer)

Cette publication est la partie 8 de 8 dans la série MISE EN ŒUVRE D’UN PORTAIL SPECIFIQUE DE RESTITUTION DE DONNEES

« J’ai l’impression d’avoir compris votre besoin, je suis en mesure d’extraire toutes les données dont vous avez besoin et voilà comment j’imagine le rapport final » … Tel pourrait être le titre de ce chapitre. La spécification des restitutions est une phase importante dans le développement logiciel et peut être à plus forte raison encore dans un projet d’informatique décisionnelle ; la restitution en elle-même étant centrale dans ce type de projets. 

Compte tenu de l’aspect quelque peu répétitif des différents rapports qui ont été maquettés nous n’allons pas détailler le contenu des différentes maquettes, contenu qui a déjà été abordé dans les phases précédentes. L’objectif est ici surtout de d’évoquer brièvement la méthodologie utilisée pour la production des maquettes.

L’idée principale de cette phase est de rendre « palpable » le résultat que nous envisageons de produire. Aussi, dans cette phase du projet, étant donné le manque d’une expression des besoins précise et exhaustive, et malgré les différents échanges qui ont suivi la phase de collecte des besoins, il apparait important de se rapprocher le plus possible de cet attendu. Afin de tendre vers cet objectif l’ensemble des maquettes de cette première phase du projet ont été réalisées avec le logiciel NVU qui permet, via une approche WYSIWYG[1], de produire rapidement des pages html (voir la figure ci-dessous pour un exemple de maquette réalisée avec le logiciel NVU).

Exemple de maquette (Rapport 1) réalisée avec le logiciel NVU

Les 5 pages HTML, représentant les 5 rapports initiaux, ainsi produites ont été présentées au groupe projet. Assez logiquement, compte tenu du nombre de « navettes » durant les phases précédentes, la structure des tableaux a été presque immédiatement validée à quelques réglages près notamment en termes de tri des lignes et des colonnes.

En revanche cette phase de présentation a élégamment fait naitre de nouveaux besoins : « plus d’interactivité et plus
d’immersion ! »

De manière plus concrète cela se traduit par les demandes suivantes :

  • Au survol des différents champs de résultats (réservations, contacts), afficher la répartition par Responsable de compte.
  • Ajouter 2 nouvelles icones pour chaque agence qui au survol permettront d’obtenir, pour l’agence en question, la répartition, par vendeur, des réservations et des contacts.
  • Au clic sur l’origine, l’agence, le nombre de contacts et nombre de réservations afficher une nouvelle page de détail dont la structure, le contenu et les résultats seront variables en fonction du point d’entrée.

Un véritable sous-projet vient de naitre au sein même du projet tel qu’initialement défini. Ceci impacte fortement d’une part la complexité du projet et d’autre part les délais nécessaires à sa réalisation. Face à cette situation la maitrise d’œuvre propose ç la maitrise d’ouvrage l’allotissement du projet. Il s’agissait d’une approche pertinente qui permettait de traiter les nouveaux besoins dans une deuxième version. Cette proposition a été rejetée par la direction commerciale qui a souhaité avoir dès le départ une version complète du portail intégrant ces différentes fonctionnalités.

Il serait bien trop long est assez redondant d’exposer ici le travail d’analyse et de maquettage des nouvelles fonctionnalités demandées, dans la mesure où, du moins dans sa philosophie générale, il a été très similaire à ce qui a été exposé dans ces premières pages. Aussi nous aborderons ces points plus en détail dans la partie « Mise en œuvre ».  Nous retiendrons à ce stade qu’un nouveau travail d’échange et de « navettes » entre la MOE, le webmarketing et la communication a permis d’obtenir, au bout de quelques semaines, un « go » définitif sur la phase de conception (toujours aussi informel) et de passer à l’étape plus technique et moins fonctionnelle qui a commencé par la mise en œuvre de l’architecture technique retenue, qui s’est poursuivi par les développements avec une présence forte des langages SQL et PHP et des sprints régulier en guise de validation et de tests.

Une nouvelle étape portée en toute autonomie par la maitrise d’œuvre avec une forte dose de confiance de la part de la MO.

Autonomie et confiance offrent souplesse et liberté mais dans le cas de ce projet, mené en « temps masqué », cela est également synonyme de charge quotidienne considérable pour le service informatique qui doit porter ce projet lourd et structurant en parallèle des différents chantiers déjà en cours. Cette situation entraînera des conséquences immédiates et lourdes sur la façon dont sera conduit ce projet de portail de restitution : seul le résultat comptera ! Elle fera également apparaitre de graves risques que nous verrons au dans le chapitre dédié.

Eclairage organisationnel : La question qu’il est naturel de se poser à ce stade est de savoir comment est-il possible d’arriver à ce type de schéma. Comment un projet de cette importance, de cette envergure peut-il être géré ainsi, en temps masqué avec une expression initiale des besoins aussi superficielle ?
Infonum
MOE

Comme souvent les causes sont multifactorielles :

–    Tout d’abord, de manière certainement un peu inavouée au départ, l’envie personnelle du RSI d’explorer le domaine de l’informatique décisionnelle par une voie différente, par une voie qui « permet aussi de montrer qu’en matière de restitution de données tout est possible, qu’il n’y a aucune limite, qu’en termes de présentation de données comme de leur extraction il est possible de tout faire pour se rapprocher le plus fidèlement possible des processus métier de l’entreprise et produire des outils « idéaux » qui correspondent à 100% au besoin, même si celui-ci s’affine tout au long du projet »: l’envie d’un challenge personnel en somme. »

–    Le deuxième facteur majeur est celui de l’organisation générale de l’entreprise au moment du lancement de ce projet. Le service informatique était alors rattaché à la Direction Générale sans aucun lien hiérarchique avec la Direction Commerciale. Cependant le directeur commercial était, en même temps, l’un des actionnaires principaux de l’entreprise. Ainsi, le service informatique, dépendait dans les faits d’une direction bicéphale. Un premier cerveau animé par la raison un deuxième par l’innovation et l’agilité.

Navigation dans la série<< Conception : L’importance de la qualité des données

Laisser un commentaire

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