DSI : les méthodes que vous imposez se doivent d’être efficientes

Article

D’une manière générale, lorsque vous souhaitez imposer une méthode plutôt qu’une autre, vous vous devez de garantir son efficacité mais également et surtout son efficience. La mise en œuvre de cette méthode doit ainsi s’accompagner d’un dispositif de mesure de l’atteinte des objectifs ET d’un dispositif d’évaluation des moyens mis en œuvre pour l’atteindre (évaluation […]
Publié le 16 mai 2011 | ⏱ Temps de lecture : 1 minute

D’une manière générale, lorsque vous souhaitez imposer une méthode plutôt qu’une autre, vous vous devez de garantir son efficacité mais également et surtout son efficience. La mise en œuvre de cette méthode doit ainsi s’accompagner d’un dispositif de mesure de l’atteinte des objectifs ET d’un dispositif d’évaluation des moyens mis en œuvre pour l’atteindre (évaluation de l’efficacité ET de l’efficience). En effet, à quoi bon atteindre l’objectif au prix d’une consommation excessive de ressources ? Les moyens mis en œuvre doivent être appropriés et adaptés au contexte du moment.

Lorsque l’on parle de méthodes de conduite de projet SI, sur le papier tout est toujours parfaitement calé et optimisé. Hors, le principe de réalité fait que leur application n’est que très rarement alignée sur les principes posés et que les dérives coutent cher, tant financièrement que du point de vue calendaire. Par ailleurs, en règle générale aucune organisation n’est prévue pour s’assurer de l’efficience de la méthode « in vivo ». En conséquence, même si la méthode est parfaitement adaptée et performante, il n’est pas possible d’en tirer la quintessence et les difficultés qui apparaissent ne disparaissent jamais quand elles ne deviennent pas un sous ensemble de la méthode !

Un des préceptes du lean est la démarche d’amélioration continue, dite Kaizen, qui vise à continuellement identifier les points d’améliorations et à les corriger de manière à tendre vers une augmentation de l’efficience. Cette démarche est portée par une équipe dédiée, seule façon d’être certain que cette tache ne passera pas à la trappe en regard des autres taches prioritaires.

Si vous imposez une méthode, c’est précisément cette démarche Kaizen que vous devez mettre en place sans quoi, aussi parfaite que soit votre méthode elle ne sera jamais efficiente, au mieux efficace si vous êtes chanceux !

Je vous propose de découvrir l’analyse critique du billet qui m’a inspiré ce résumé sur l’importance de mesurer l’efficience des méthodes que l’on impose.

Sur son blog De geek à directeur technique, Amaury partage avec nous son quotidien de Directeur Technique et les grands questionnements auxquels il doit faire face, tant sur l’organisation que les méthodes ou encore les outils. Son dernier billet Application concrète des méthodes agiles, que je vous invite à lire, est à cet égard très intéressant. Il illustre plusieurs principes que nous devrions toujours avoir à l’esprit lors de la mise en place des méthodes de conduite de projet pour l’entreprise.

Je partage la démarche et les choix décrits par Amaury et vous propose quelques extraits enrichis de mes commentaires et remarques.

La refonte organisationnelle

J’ai commencé par faire un constat sur les enjeux :

  • Choisir la bonne direction => Mieux spécifier

  • Maîtriser les coûts => Mieux planifier

  • Construire du solide => Vérifier la qualité

  • Pérenniser l’équipe => Penser à long terme

D’accord, mais concrètement, ça veut dire quoi ? Plus spécialement, la planification est un miroir aux alouettes : Il ne sert pas à grand-chose de passer 2 heures à établir un planning précis, puisque dès le lendemain il risque d’être chamboulé ; et comme on n’aura pas envie d’y passer 2 heures tous les jours, on finira par laisser le planning à l’abandon. Le problème, c’est que souvent le planning sert de fondement à toute l’organisation ; un planning qui n’est pas à jour et c’est toute la gestion de projet qui s’écroule.

Je rejoins complètement cette vision. Une tache fortement consommatrice de charge et dont la valeur ajoutée est minime finira par être abandonnée ou réalisée à la marge ce qui n’est guère mieux.

Le planning est pourtant un élément indispensable au pilotage d’un projet, tant d’un point de vue opérationnel que stratégique. Le problème est que ces deux visions sont totalement antagonistes en terme de besoin. L’opérationnel a besoin d’un planning précis et détaillé qui lui indique des jalons réalistes et atteignables, l’ensemble étant revu régulièrement pour s’adapter à la vie du projet (i.e. les dates peuvent bouger). Le stratégique a besoin d’un planning qui lui indique une date d’arrivée et un cout associé (je schématise), les deux ne devant surtout pas bouger. Bref, autant dire qu’optimiser le temps passé au maintien à jour des plannings par rapport à leur durée de vie est un exercices de plus difficiles.

Dans le cadre de mes missions, je m’efforce maintenant de ne maintenir qu’un planning « macro » différenciant les étapes aux dates « actées » par l’ensemble des acteurs des étapes aux dates « souhaitées » par le métier. Ainsi, il est plus simple de faire changer un jalon, le métier étant un peu plus compréhensif car responsabilisé (la pratique est bien sur beaucoup plus piquée des hannetons). Le découpage des étapes est par ailleurs standardisé pour rester simple et compréhensible par tous (Expression du besoin macro, Conception fonctionnelle / technique, Réalisation, Recette technique / fonctionnelle, MEP). Vous l’aurez deviné, la méthode à laquelle je dois me plier est le cycle en V et je ne peux malheureusement pas y déroger, mon seul degré de liberté est l'adaptation à la marge au prix d'une dépense d’énergie très importante. Cette méthode entraine de nombreuses itérations intermédiaires de type ajout de fonctionnalités / contrainte technique avec impact fonctionnel, par principe je ne les fais pas figurer sur le planning pour ne pas y passer 2h inutiles par jour. La DSI de son coté tient un planning détaillé projet/taches/ressources lui permettant de s’organiser et de conserver sous contrôle la réalisation, mais ne le partage pas avec le métier pour éviter de les perdre dans des détails inutiles.

J’ai donc imposé une organisation. […] je pense que les méthodes ne doivent pas être appliquées à la lettre. Il faut plutôt s’inspirer des différents enseignements, utiliser le «jus de cerveau» de ceux qui sont passés par là avant nous, et composer la meilleure recette en fonction des personnes, des habitudes, des projets, … […]

J’ai fait le choix de la simplicité, avec des cycles qui durent un mois, découpé ainsi :

  • Définition des objectifs. La première journée de chaque cycle est dédiée à l’analyse technique des projets […]. On prend la liste des projets en attente, et on tente de définir ceux qui vont être développés pendant ce cycle.

  • Sprints de développement. Les deux premières semaines […] sont consacrées aux développements. […]

  • Sprint de stabilisation. Une semaine entière est utilisée à stabiliser les développements. […]

  • Sprint de déploiement. […] installation des projets […] déroulement des tests […] mise en production et la recette[…].

  • Évaluation. La dernière journée du cycle sert à reprendre la liste des tâches qui ont été laissées de côté pendant le mois, pour les intégrer correctement à la liste de priorités du cycle suivant.

Le fait de caler les itérations sur les mois calendaires offre certains avantages. Très simplement, personne ne se demande quand sera la prochaine mise en production […]. De la même manière […] Si un projet n’est pas spécifié […] avant la fin du mois, le projet en question ne sera pas développé le mois suivant.

Comme nous le verrons plus loin, la méthode est certes imposée, mais elle est clairement issue du principe Kaizen, la mesure de l’efficience est ainsi au cœur de la démarche. Le choix fait par Amaury est dicté par le contexte de l’entreprise, sa taille, son fonctionnement, … Pour autant, les principes fondateurs décris ici sont tout à fait adaptables à d’autres contextes, moyennant ajustements bien sur.

A mon sens, cette démarche est un premier pas et je suis convaincu qu’Amaury a en réserve une évolution de cette organisation permettant de faire rentrer les fonctionnels au cœur des cycles qu’il décrit. En effet, ces derniers sont encore en dehors de la méthode et simples fournisseurs de spécifications (c’est en tout cas le ressenti que j’en ai).

Le Bilan et la démarche Kaizen

[…] Pour le moment, le bilan est très positif.

La qualité des projets a été largement améliorée […]

Les projets sortent avec moins de retard. […] Cela s’explique par deux choses :

  • Le temps nécessaire à une mise en production est plus ou moins incompressible. […] Quand on s’autorisait plusieurs MEP par mois, ce temps était multiplié (même si peu de gens s’en rendaient compte). En ne faisant plus qu’une seule MEP par mois, on perd moins de temps à ce niveau-là.

  • Quand il n’y avait pas de deadline fixe sur les projets, il y avait des ajouts incessants qui étaient demandés en cours de développement […]. Les projets prenaient donc naturellement du retard […] au final, il restait une perception négative du genre «On n’avait pas dit que ce projet devait sortir il y a 2 semaines ? Si, mais tu as ajouté 3 semaines de boulot entre-temps. Ah oui, c’est vrai, mais c’est quand même chiant d’être en retard…». Désormais […] tout le monde sait à quoi s’attendre, personne n’est pris au dépourvu.

Tout n’est pas encore parfait. Les spécifications fonctionnelles ont encore du mal à être prêtes à 100% au bon moment. Encore trop souvent, je ne reçois en début de mois qu’un simple brief sur lequel il faut passer encore du temps et de l’énergie pour aboutir à une spécification complète. Mais les choses s’améliorent ; nous n’avons plus le cas extrême des spécifications qui nous sont fournies après le développement, ce qui était arrivé quelques fois auparavant.

La pression sur l’équipe technique est différente. Si nous n’avons plus le problème du best-[…] les mois passent à toute vitesse. Chaque sprint est quand même bien […} et on aurait bien besoin d’une journée supplémentaire dans la semaine.

Il y a dans ce bilan énormément de bon sens dans l’analyse de l’origine des dysfonctionnements et de l’impact des changements apportés. Je parle de démarche Kaizen car dans les écrits d’Amaury transpire un recul permanent sur l’organisation et le quotidien qui amène à mettre en œuvre des changements d’importance variable mais avec toujours en bout de ligne l’objectif de faire mieux avec à minima autant (un des crédos de la démarche lean étant de faire mieux avec moins).

Compte tenu de la conclusion, notamment sur l’amélioration moins importante de l’étape spécifications fonctionnelles, je pense que l’étape suivante sera de passer les cycles sur deux mois par l’ajout de plusieurs « sprints » fonctionnels permettant de rendre l’ensemble plus équilibré :

  • Premier mois

    • Définition des objectifs métiers : Etude d’opportunité sur le besoin fonctionnel macro (1 journée)

    •  Sprints de conception fonctionnelle : Ateliers ayant pour objectif la description fonctionnelle détaillée des besoins attendus, sous forme de documents ou de maquettes (3 semaines)

    • Sprint de passage de témoin : Une semaine pendant laquelle l’ensemble des productions issues de l’étape de conception sont revues, clarifiées, mises en cohérences et documentées en vue de les passer aux équipes de dev.

    •  Évaluation.

  • Second mois

    • Définition des objectifs. Utilisera la matière produite lors du sprint de passage de témoin et gagnera en efficience.

    • Sprints de développement

    • Sprint de stabilisation

    • Sprint de déploiement

    • Évaluation.

Comme vous l'aurez compris, ce billet d'Amaury m’a beaucoup parlé car dans le cadre de mes mission j’applique une philosophie assez simple par rapport aux méthodes de conduite de projet : privilégier le bon sens et toujours prendre en compte le ratio énergie nécessaire / résultat à atteindre.

Privilégier le bon sens car toute méthode, aussi bien pensée soit elle, devra se soumettre au facteur humain. De nombreuses dérives sont en effet possibles, la plus courante étant de se réfugier dans la méthode sans prendre en compte le contexte (la posture de l’autruche). Privilégier le bon sens conduit à se libérer du cadre imposé par la méthode pour permettre le recul nécessaire à la prise de décision englobant l’ensemble des problématiques et pas seulement celles vues au travers de l’œillère.

Toujours prendre en compte le ratio énergie nécessaire / résultat à atteindre pour privilégier l’efficience par rapport à l’efficacité. En effet, à quoi bon perdre des heures sur un sujet de très faible intérêt alors que d’autres bien plus importants attendent ? Ce ratio permet de garder en tête les vrai priorités qui ne sont pas toujours celles qui nous sont imposées, et ainsi d’optimiser au mieux le temps passé sur ces dernières.

Je retrouve dans les écrits d’Amaury ces mêmes préoccupations, ce qui en fait un retour d’expérience très intéressant pour moi. Ce retour d’expérience me fait d’ailleurs penser à la remarque de Frédéric « une révolution se conduit d’abord de l’intérieur » dans les commentaires sur mon dernier billet.

Pour finir sur une note rassurante, la conduite de projet SI n’est pas seule dans la tourmente. Les flottements que nous constatons et les  pistes d’amélioration sont largement partagées dans d’autres domaines ou le mode projet est de mise, comme par exemple le monde du serious game. Finalement, et c’est bien ça l’important, l’avenir est riche de changements et d’opportunités d’améliorer les choses. Saisissons les !



Fabien GrenetCofondateur de There is no spoon, Fabien est tout autant passionné par l'innovation et le numérique que par le jardinage. Il partage sa vision et son expérience sur ces pages, ainsi que ses expérimentations agricoles sur Le Potager Perché.

Travaillons ensemble !

Envie de prendre un café pour faire connaissance et découvrir notre activité ? Besoin d’un point de vue expert sur vos problématiques et vos besoin ?

Laissez nous un message via ce formulaire...

...ou contactez nous directement

Téléphone

06 62 35 33 41

Réseaux sociaux

Une dose d'inspiration ?

#UX / Content first, sidebar second.

#UX / Content first, sidebar second.

Cela fait presque un an que je ne me satisfait plus de la mise en page des articles sur Startupeers, en particulier parce que je trouve les contenus publiés pas assez agréables à lire. Je suis plutôt frustré du rendu à l'écran de ces contenus pourtant qualitatifs, que...