Voir le flux RSS

MarieKisSlaJoue

[Actualité] Pourquoi et comment j’ai réussi mon projet MOE ?

Noter ce billet
par , 16/09/2015 à 17h45 (1383 Affichages)
Comment j'ai réussi mon projet MOE ?
Retour d'expérience d'un projet étudiant

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.

Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Viadeo Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Twitter Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Google Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Facebook Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Digg Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Delicious Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog MySpace Envoyer le billet « Pourquoi et comment j’ai réussi mon projet MOE ? » dans le blog Yahoo

Mis à jour 20/07/2016 à 17h20 par MarieKisSlaJoue

Tags: etude, projet
Catégories
Retour d'expérience

Commentaires

  1. Avatar de Derf59
    • |
    • permalink
    Heureusement que le projet n'était pas un correcteur orthographique sinon il aurait échoué
  2. Avatar de deltree
    • |
    • permalink
    Citation Envoyé par Derf59
    Heureusement que le projet n'était pas un correcteur orthographique sinon il aurait échoué
    lol

    dsl Stéphane, j'essaie d'être constructif:, j'ai pas compris cette phrase, si tu pouvais la réécrire stp.
    Il a certainement manière plus efficace que d'autre de gérer une équipe.
  3. Avatar de deltree
    • |
    • permalink
    Sur le fond, tu as raison si tu as choisi un Cycle en V. Mais pour moi, c'est la vieille école.
    C'est vrai qu'il ne faut pas négliger le cout de gestion et management, mais c'est justement l'inconvénient principal du Cycle en V, et des équipes hyper hiérarchique à la française.
    En agilité (la vrai, pas larache) on est orienté sur le produit, et on le voit justement en premier lieu, et c'est ce qui me choque dans ta conclusion, tu fait justement le constat qu'avec cette méthode, on ne voit le produit qu'à la fin.
  4. Avatar de AoCannaille
    • |
    • permalink
    Citation Envoyé par deltree
    Sur le fond, tu as raison si tu as choisi un Cycle en V. Mais pour moi, c'est la vieille école.
    C'est vrai qu'il ne faut pas négliger le cout de gestion et management, mais c'est justement l'inconvénient principal du Cycle en V, et des équipes hyper hiérarchique à la française.
    En agilité (la vrai, pas larache) on est orienté sur le produit, et on le voit justement en premier lieu, et c'est ce qui me choque dans ta conclusion, tu fait justement le constat qu'avec cette méthode, on ne voit le produit qu'à la fin.

    Au fond l'agile, c'est implémenter le cycle en V sur un périmètre très restreint et des délais très courts. On ne demande pas depuis une expression de besoin de 100 pages un produit dans 1 an, mais depuis une expression de besoin d'une ou deux fonctionnalité un produit dans 2 semaines. Le gros avantage de cette technique est, à mon sens, psychologique, que ce soit du coté des dev ou du client : on voit le produit avancer peu à peu et on cache beaucoup moins les problèmes au client qui se sentira plus impliqué et compréhensif.

    Mais pour moi ça reste du cycle en V. Itératif certes, mais un cycle en V.
  5. Avatar de deltree
    • |
    • permalink
    Citation Envoyé par AoCannaille
    Au fond l'agile, c'est implémenter le cycle en V sur un périmètre très restreint et des délais très courts. On ne demande pas depuis une expression de besoin de 100 pages un produit dans 1 an, mais depuis une expression de besoin d'une ou deux fonctionnalité un produit dans 2 semaines. Le gros avantage de cette technique est, à mon sens, psychologique, que ce soit du coté des dev ou du client : on voit le produit avancer peu à peu et on cache beaucoup moins les problèmes au client qui se sentira plus impliqué et compréhensif.

    Mais pour moi ça reste du cycle en V. Itératif certes, mais un cycle en V.
    L'agilité c'est un peu plus que ça.
    Le processus itératif évite effectivement l'effet tunnel (désolé pour la barbarisme) Et on le pratiquait avant l'agilité.

    Mais l'agilité comme le scrum apporte bien d'autres éléments comme l'amélioration continue, la responsabilité de l'équipe, je ne peux pas tout décrire. Mais pour les rôles par exemple tout est changé, on n'a pas une équipe AMOA et une équipe MOE. L'équipe est responsable du projet, et elle a la connaissance du planning par exemple, mais aussi de la totalité de taches, elle est plus proche du fonctionnel. Bref toute l'équipe connait le produit, ce n'est plus le même esprit, ça évite les phrases du genre "ce n'est pas moi qui m'occupe de ça".
    Il y aurais beaucoup de chose à en dire, je pratique l'agilité et j'essaie de le défendre, je ne démolis pas l'itératif pour autant, je l'ai également pratiqué et il vaut mieux une méthode bien maitrisée qu'une méthode choisie juste parce qu'elle est à la mode.
  6. Avatar de martycanfly
    • |
    • permalink
    Étudiante à l'ESGI ?
  7. Avatar de MarieKisSlaJoue
    • |
    • permalink
    Citation Envoyé par deltree
    lol

    dsl Stéphane, j'essaie d'être constructif:, j'ai pas compris cette phrase, si tu pouvais la réécrire stp.
    La phrase aurai du être plutôt être. "Il à certainement des manières plus efficaces que d'autre pour gérer une équipe"
    A vrai dire j'ai tendance à écrire mes idées dans les transports, je voulais pouvoir garder une trace de mes expériences pour me permettre de revenir dessus et le blog offrait le support idéal. Je n'avais pas prévu que le billet soit relayé dans la section AML et encore moins en actualité... J’aurai su j'y aurai porté un peu plus d'attention.

    Citation Envoyé par deltree
    Sur le fond, tu as raison si tu as choisi un Cycle en V. Mais pour moi, c'est la vieille école.
    C'est vrai qu'il ne faut pas négliger le cout de gestion et management, mais c'est justement l'inconvénient principal du Cycle en V, et des équipes hyper hiérarchique à la française.
    En fait, même si c'est de la vielle école, c'est pas pour autant à jeté. Déjà parce que une équipe hyper hiérarchique c'est ce qu'est une école. (Environnement du projet). Du coup un cycle en V ça s'inscrit assez bien avec le fonctionnement de la plus part des écoles. Un syllabus au début, des points tous les 2 mois pour vérifier le travail des élèves et à la fin ta soutenance. Ensuite le cycle en V ça reste quand même une méthode plutôt facile à apprendre et appliqué. Pour un étudiant qui doit gérer des projets (quelque chose de totalement nouveau pour lui normalement) c'est je pense mieux que rien.

    Citation Envoyé par deltree
    En agilité (la vrai, pas larache) on est orienté sur le produit, et on le voit justement en premier lieu, et c'est ce qui me choque dans ta conclusion, tu fait justement le constat qu'avec cette méthode, on ne voit le produit qu'à la fin.
    On le vois à la fin certes, mais le but est quand même d'éviter toute surprise à la fin. Je n'ai peut être pas suffisamment insisté sur le SEMAT et son aspect solution qui parle en effet sur le côté démontrable qui doit arriver très vite. Mais c'est aussi parce que c'est pas le produit final qu'un étudiant néglige en général. Au contraire il est à fond sur le code. Il est en revanche bcp moins sur tous ce qui tourne autour du projet, ses spécifications, son équipe, sa gestion et le relationnel. Et ayant fait du coup un projet coté fournisseur, j'en ai aussi fait un coté client mais qui lui à littéralement explosé en vole, à mon sens à cause d'une mauvais gestion de projet.

    Je suis d'accord avec toi quand tu dis que l'agilité c'est un peu plus que du cycle en V itératif par contre. Mais je ne sais pas quelles pratiques sont applicables en projet scolaire. Et je n'ai pas de retour d'expérience sur ça.
  8. Avatar de rhludovic
    • |
    • permalink
    Intéressant mais vraiment dommage qu'un étudiant en 4ème année d'informatique ait eu autant de mal a s’exprimer dans sa langue maternelle. J'ai pas pu aller très loin.
    Mis à jour 22/09/2015 à 20h08 par rhludovic
  9. Avatar de chaparo
    • |
    • permalink
    Citation Envoyé par rhludovic
    Intéressant mais vraiment dommage qu'un étudiant en 4ème année d'informatique ait eu autant de mal a s’exprimer dans sa langue maternelle. J'ai pas pu aller très loin.
    ** de mal à s’exprimer dans sa langue maternelle**


    22/09/2015, 19h22
    rhludovic a commenté le billet Du baratin des recruteurs et de ce qu'en pensent les recrutés dans le blog L'ingé n'y rit
    Un récit passionnant et amusant. Respect . J'en ai pas rater une miette.

    **J'en ai pas raté une miette.**

    !!Attention!! Je ne suis pas un exemple hein, mais lire des trucs pareils quand on en fait aussi, ça se passe de commentaire.