Quels métiers exercent les employés d’Eonix ? Pour une entreprise en informatique, la première profession qui vient à l’esprit est celle de développeur. Derrière leur ordinateur, les développeurs se chargent de réaliser le projet commandé par un client. Un travail qui ne peut avoir lieu qu’en étroite collaboration avec une personne bien particulière : l’analyste fonctionnel. Sa fonction n’est pas toujours connue en dehors du milieu informatique. Alors, pour y remédier, nous avons demandé à l’un de nos analystes fonctionnels, Farid, d’expliquer en quoi consiste son métier !
L’analyse de Farid
L’analyste fonctionnel a, comme son nom l’indique, un rôle d’analyse. Que ce soit dans la phase de collecte de données, ou dans celle de conception de la solution demandée par les clients.
Lorsque je suis assigné à un nouveau projet, je commence par identifier les parties prenantes qui ont un impact sur celui-ci. Je les écoute afin de comprendre et de déterminer les besoins attendus. Une fois ces deux paramètres pris en compte, je peux organiser les ateliers. Ce sont des rencontres qui sont menées dans le but d’identifier les processus métier sous forme de questionnaire ou d’entretien individuel.
Ces nombreuses rencontres sont essentielles pour l’avancement du projet. La communication est un élément clé de mon travail. En tant qu’analyste fonctionnel, je suis l’intermédiaire entre les clients et les développeurs tout au long de l’évolution du projet. Un rôle que j’affectionne particulièrement. Il me place au cœur des échanges et me permet d’en apprendre toujours plus.
Comme je suis le pont entre les parties prenantes et nos équipes de développeurs, il faut que je comprenne bien le milieu auquel appartient le premier groupe. Lorsque c’est fait, je dois traduire ce que les clients m’ont expliqué en langage technique pour les développeurs. Analyse et communication se complètent dans ma fonction, parce que si je ne discute pas en long et en large avec les parties prenantes d’un projet, alors je n’ai rien à analyser.
Avec les informations supplémentaires récoltées lors des ateliers mentionnés plus haut, je suis en mesure de dresser un cahier des spécifications fonctionnelles. Sur base de ce cahier, je peux établir la liste des exigences fonctionnelles et non fonctionnelles. Le fonctionnel correspond à ce que doit faire la solution. Du côté du non-fonctionnel, cela concerne les règles ou configurations auxquelles la solution doit répondre. Tels que la durée d’accessibilité, le nombre de personnes qui peuvent se connecter en même temps, et la protection des données personnelles.
Dès que la phase de documentation est clôturée, je me lance dans celle de modélisation. Je transforme le travail écrit effectué plus tôt en différents visuels pour faciliter le développement. Au travers de schémas, de diagrammes de flux de données et parfois de maquettes, nous présentons notre vision de la solution aux clients. Si le travail d’analyse est validé, celui des développeurs peut commencer.
Pour ce faire, je découpe et traduis la documentation en fonctionnalité technique pour qu’elle entre dans notre système de gestion de projets afin de les organiser dans un backlog[1]. Chaque tâche de ce backlog sera planifiée sur base des différents sprints[2] prévus dans le projet afin d’assurer une réalisation itérative avec le client. Le travail de développement se fait sur des sprints qui durent généralement 2 à 4 semaines. Cela permet de coder l’application en partant de l’essentiel. Les développeurs débutent par le noyau (la fonctionnalité majeure), afin de construire tout autour.
Parfois, la partie de la validation bloque. Lors de la présentation de la solution, il est possible que le client ne retrouve pas ses exigences. Pourquoi ? Parce qu’au moment des ateliers, il a en tête une solution A mais il parle d’une solution B. C’est sur cette dernière que nous allons travailler. Quand je lui fais part de ma vision de la solution, elle est forcément mauvaise à ses yeux. Nous devons tout reprendre, cela ralentit le projet.
C’est dans ces cas-là que j’aimerais bien être capable de lire dans les pensées. Je comprends directement le besoin du client, même s’il n’arrive pas à l’exprimer !
[1] Une liste hiérarchisée de tâches destinées à l’équipe de développement.
[2] Une brève période limitée dans le temps dont une équipe a besoin pour effectuer une quantité de travail donnée