Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Comment j'ai réussi mon projet MOE ?
Retour d'expérience d'un projet étudiant

Le , par MarieKisSlaJoue

0PARTAGES

Aujourd’hui je vais faire quelque chose que je n’ai encore jamais fait. M’exprimer au travers d’un billet pour raconter une de mes expériences vécues. Ce billet est notamment adressé aux étudiants. Car ici, on va parler d’un projet d’étudiant

Pour remettre les choses dans l’ordre je vais vous présenter le contexte. Etudiant en 4ème année dans une école d’informatique. Notre spécialité et l’étude de l’architecture logicielle. Chaque année, un gros projet, dit « Projet Annuel » ou « PA » pour les intimes doit être réalisé. Cette année l’objectif était de présenter en tant que client un projet qu’une autre équipe aller réaliser. Et de réaliser le projet d’une autre équipe.

Pour ce billet je vais me concentrer sur le projet qu’on a dû réaliser avec notre rôle de MOE.

Avant tout pourquoi je pense que j’ai réussi mon projet MOE. Mis à part une bonne note à notre groupe d’autres raisons me laissent penser que j’ai réussis mon projet MOE.

Cela commence par la satisfaction du client. Ce même client avait confié à mon groupe la réalisation d’un client mail pouvant se synchroniser les préférences utilisateurs lors de l’installation sur un autre poste. Oui aujourd’hui en 2015 on appelle cela tous simplement un client léger. Mais le but était de réussir un projet, pas d’en avoir un innovant. A notre soutenance le groupe client venu avec une liste d’exigence a pu tester le logiciel avant de conclure qu’il était bien conforme. Leur acceptation du produit et donc un des critères pour me dire que mon projet a réussis.

Mais il en a d'autres. Ils auraient pu accepter un produit presque à contre cœur si par exemple nos échanges tout le long du projet c'était mal passé. Il est tout à fait réaliste d'imaginer que l'on remplisse parfaitement le cahier des charges mais que nos échanges durant tout le projet soit désagréable au point de n'avoir qu'une envie, vite finir le projet pour ne plus jamais travailler ensemble. Hors ça n'a pas été le cas. Au de-là du produit le client a donc été aussi satisfait de la prestation global. Qualité des échanges, qualité des différends documents produit, du reporting sur le projet et du produit final me permette de dire si un projet a été un succès ou non.

Maintenant comment l’équipe MOE a pu atteindre la satisfaction du client ?

Pour atteindre nos objectifs il fallut réussir à identifier différent axe sur lesquels nous pouvions évaluer notre maturité. Nous avons utilisé un document appelé SEMAT afin de nous évaluer sur sept axes. On ne fera pas de sujet détailler sur ce qu'est un SEMAT et comment il fonctionne ici. Je le cite seulement pour expliquer que nous ne sommes pas parties de rien pour gérer notre projet.

Nous avons donc du déjà définir précisément le besoin exprimé par notre client. D'un cahier des charges nous avons réalisé quatre documents qui ont permis d'entamer une réflexion sur le projet et imaginé avant même sa conception à quoi il allait ressembler. Ces documents sont l'étude d'opportunité, la charte de projet, les spécifications et le planning. Ce travail préalable souvent négligé c'est en fait révélé très précieux. Ils nous ont permis de nous approprier les attentes du client et de les exprimer à travers des fonctionnalités. Ecrire des spécifications et un travail difficile. Mais elles vaillent le coup. C'est un vrai bonheur de pouvoir répondre à des questions seulement en se rendant dans un seul document bien formalisé. La qualité de ses documents va de pair avec la communication envers l'équipe MOA bien sûr, mais aussi en confiant ce genre de tâche à des personnes intéressées par l'exercice de faire un document plutôt fonctionnelle que technique.

Ici le planning ne sert pas vraiment à être respecté. Il donne les grandes dates, les étapes importantes, mais au final sera de moins en moins suivis. On reviendra sur son importance un peu plus loin.

Deuxièmes étape et l'identification de toutes les parties prenantes. MOE et MOA sont deux groupes bien distincts. Composé chacun de cinq personnes, ça fait 10 personnes qui peuvent communiquer chacune entre elles. Il est donc important de bien définir les rôles de chacun. Qui est responsable de quoi, qui sera responsable de communiquer avec l'autre groupe. Qui communiquera avec nous en face. Peu-importe le fonctionnement interne des deux groupes. Savoir si c'est une dictature ou une démocratie n'est pas importante. Ici on ne cherche pas à savoir qui va prendre les décisions. Mais qui va les communiquer. Car ce sont les paroles de cette personne qui ferons foi en cas de litige.

Maintenant que les interactions avec le restent du monde sont explicites il est temps de s'occuper de notre propre équipe. Il a certainement manière plus efficace que d'autre de gérer une équipe. Ce que mon projet m'a appris c'est qu'il est nécessaire d'avoir quand même une personne qui finira par trancher entre plusieurs options. Cette personne n'aura pas la science infuse et devra bien sûr travailler avec les membres de son groupe pour satisfaire tout le monde. Son rôle n'est pas de jouer les petits chefs, mais plutôt un leader pour guider l'équipe pour la faire avancer dans le bon sens ou de coordinateur.

Car oui notre équipe il faut la coordonner, la faire fonctionner. Pour cela le plus simple est de définir clairement quelles méthodes et outils vous allez utiliser. Que ça soit Trello, SharePoint, Google Drive ou GIT. L'important n'est pas l'outil, mais que tout le monde puisse collaborer facilement sur des documents, du code ou des tâches en cours. En clair il faut que les informations dont l'équipe puisse avoir soit facilement accessible et compréhensible. Si je prends l'exemple des tâches à faire. On pourrait très bien se dire « Bah c'est très simple, tu vas voir les spécifications et tu pioches une fonctionnalité dedans ». En tant que développeur qui se met au travail j'aimerais transformer le temps que je mets à savoir quelle tâche est à réaliser en ligne de code. Regrouper les fonctionnalités par lot et rapide à faire et permet de les afficher dans une ToDo de façon claire. (En plus d'un nombre important de bénéfice comme de pouvoir les paralléliser, les prioriser, etc)

Vous avez vos tâches à faire et savais comment travailler. Il nous reste encore à définir qui fait quoi. La répartition des tâches sontun facteur clé dans la réussite du projet. Notre planning qui ne servait pas à grand-chose tout à l'heure va d'un coup devenir notre meilleur ami. C'est dans notre planning que nous avons toutes les tâches à faire et qui va donc permettre de les répartir. Le plus simple pour répartir correctement les tâches et de faire une matrice de compétence. Vous avez vos tâches d'un côté et vous savez pour une tâche quelles compétences sont nécessaires. De l'autre vous avez votre équipe et leurs compétences. Mixer les deux et vous pourrez savoir qui doit faire quoi. Comment faire une matrice de compétences ou une matrice tâches ressources n'est pas au programme, mais je vous invite à le faire pour gérer au mieux votre projet. C'est votre équipe qui réussira ou non le projet. Alors, prenez en soins. Ecouter leur aspiration, ménager leur charge de travail, jouer sur leur atout et vous aurez une équipe efficace.

C'est dingue nous parlons de comment réussir un projet informatique et nous n'avons toujours pas parlé du produit. C'est pourtant sur quoi tout le monde se concentre en général. Alors, oui le livrable à produire et important et il ne faut pas le négliger. Vous avez réussi à définir une liste d'exigence il est temps maintenant de les combler. Normalement si vos exigences sont bien définies et que tout le monde est en accord dessus concevoir votre solution n'est pas très difficile. Il vous suffit de commencer à choisir une architecture qui répond aux exigences techniques demandées (performance, sécurité, qualité, etc) puis à construire quelque chose de démontrable rapidement au client dessus. La partie démontrable est importante, si votre client voit un logiciel avancé, des fonctionnalités ajoutées au fur et à mesure du temps il sera beaucoup moins inquiet que si vous le laissez trois mois sans nouvelle (« Oui, oui ça avance ne t'en fais pas, mais la pour l'instant on n'a pas d'IHM à te montrer »)

Dans ce billet il a eu des évidences et des impressions, il ne répond pas à comment on réussit un projet informatique. Mais donnera j'espère des pistes pour les étudiants qui auront réalisé qu'ils ont besoin d'exigences clairement définies et comprise. Des responsabilités clairement établies et une équipe qui sait fonctionner ensemble.

Et vous ?

Qu'en pensez-vous ? Y reconnaissez-vous des bribes de votre expérience ? Sinon, comment vous y vous pris ? Partagez votre expérience.

Une erreur dans cette actualité ? Signalez-le nous !