L’incrémental est fortement utilisé dans l’industrie aujourd’hui, et dans les SSII. Il consiste simplement à découper en modules le produit et à livrer les modules une fois « terminés ». On ne prévoit a priori pas de modifications sur les modules « terminés ». Cette approche nécessite une étude préalable et reste très classique. Simplement, on voit le client un peu plus souvent, ce qui ne peut pas faire de mal.

L’itératif prévoit dès le départ un retour sur ce qui a déjà été développé. On peut éventuellement attaquer plusieurs modules à la fois, et les premières versions sont des brouillons du produit. C’est cette approche-là qui est efficace si elle est bien menée, mais qui a du mal à entrer dans les mœurs.

En effet, comment expliquer à un client qui a un budget fixe qu’il ne peut pas savoir à l’avance ce qu’il obtiendra pour ce budget? Surtout quand il a besoin de définir ce contenu pour obtenir son budget!
Comment un client un peu méfiant comme le sont souvent les Français peut-il imaginer qu’il ne va pas se faire avoir?
J’ai confiance dans la capacité des CP, développeurs, responsables R&D à changer de mentalité, mais moins dans celle des Administrations.

Enfin, comparer la musique classique au jazz est une abération. En effet, quand vous atteignez un certain niveau en musique classique, vous pouvez interpréter une oeuvre comme bon vous semble, voire même se laisser quelques libertés! Un peu comme en jazz. De plus, la trame est la même (une bonne vieille partition…).

A bon entendeur !

? Il est multi-Compétent

? Bien que multi-Compétent, il n’est pas à le plusieurs petits spécialistes en un ?

? Il est doté d’empathie (ou à défaut il compense par son petit frère moins noble: la flexibilité)

? Il reconnait ? leur juste valeur les savoirs faire des experts qui l’entourent

? Il est réellement compétent et reconnu comme tel par les experts techniques qu’il accompagne

Mais l’essentiel repose sur sa capacité de mise en perspective des choses (cet ajout littéral de dimensions ne sera d’ailleurs pas sans générer de l’angoisse pour son entourage qui jusque la vivait dans un monde de certitudes).

Très bien mais tout cela reste très abstrait me direz-vous et Comment introduire un tel Coach dans une équipe chez un client, comment valoriser sa VA et ne pas le résumer à un cout supplémentaire pour le projet ?

Inutile de se baigner d’illusion, le marché nous impose d’attaquer le sujet par le R.O.I. Il aurait été plus satisfaisant et plus juste de l’attaquer sur les pans de la Qualité et de la Satisfaction Utilisateurs mais malheureusement l’idée de cout supplémentaire est trop présente dans l’esprit de 90% des dirigeants pour ne pas l’attaquer de front.

Mais alors comment une personne supplémentaire (10 à 15 HJ/mois) sans expertise technique pointue pourrait rendre mon projet moins cher ?

Tout simplement parce qu’elle sera le gardien du pragmatisme générale (qui aura vite fait de se perdre que cela soit côté MOE ou côté MOA) et que l’absence de pragmatisme dans un projet a un cout important :

1. Son absence aura un impact sur les délais

Combien de temps faut-il à une équipe DBA de Production faut-il pour s’accorder avec une équipe de développement ?

Il faut longtemps pour la simple est bonne raison que l’essentiel ne pourra être discuté qu’a l’issue d’une première phase qui va consister en une présentation (par confrontation) mutuelle des cultures des deux partis. Bien que le consensus finira irrémédiablement par s’instaurer passée cette première étape de sociabilisation, mais le mal sera déjà fait : on a perdu x HJ

2. Son absence aura un impact sur la qualité

Qui pilote globalement la problématique de la Qualité ?, certes la Sous-qualité est généralement pilotée car sanctionnée par les Tests et encouragée par le mode forfait. En revanche, la sur-qualité (généralement en début de projet) est un vrai problème dans la mesure où cette sur-qualité consommatrice sera compensée par la diminution du niveau sur un autre domaine de l’application. Nous avons tous compris que nous ne sommes pas en retard en présence d’une zone de sur-qualité, mais que la présence d’une zone de sur-qualité fait descendre de facto la qualité globale d’un projet à l’heure. (Chacun définira la non-qualité en fonction des phobies de son environnement Projet)

Le Chef de Projet peut-il efficacement faire dialoguer des équipes de Production avec des équipes des études, piloter la qualité ?

Peut-être le pourra t’il, mais j’ai tendance à penser que la conduite de projet est un numéro de duettiste : Le CP doit rassurer les commanditaires et fixer les jalons, il a la responsabilité de créer le cadre à l’intérieur duquel le Coach/Architecte pourra animer les ressources en présence. Les expériences pluriculturelles (Build, Production, MOA, CP, ?) de ce dernier lui permettront d’optimiser un planning en raccourcissant les délais d’intermédiations et de rites de passages.

eric.kdual@eaichannel.com

Je dirais même plus, ils ont aussi une bonne expérience de la gestion d’équipes, de projets et de la relation avec les donneurs d’ordres. Ils ont cessé de se développer en profondeur (ce qui est la caractéristique des experts) pour se développer en largeur afin d’étendre leur spectre d’intervention.

? ?Faire preuve de Courage? ?
Je n’aime pas cette notion, elle mène directement au sacrifice. Je préfère dire qu’il faut faire preuve de détermination, de ténacité pour atteindre les objectifs assignés dans des environnements mouvants.

Notre culture considère Généralisme et Pragmatisme comme l’absence de Méthode et d’Expertise. Cette mauvaise hiérarchie de valeurs constitue certes un bon moteur à promotions sociales pour les Experts IT$ mais contribue à amonceler les Projets en déroutes : il y a très souvent une relation directe entre réussite de l’individu qui a conduit le Projet (Promotion Peter’s) et résultat catastrophique pour l’utilisateur.

DG et DSI doivent avoir pour objectif, certes de limiter l’exotisme méthodologique (objectif atteint) mais aussi et surtout de savoir créer le terrain de l’innovation réelle.

Contrairement a des idées reçues, passé les strates des DG, la culture prédominante est bien celle du Moyen et non celle du Résultat : ‘Quelle méthode allez vous utiliser ? ; ‘Quel référentiel nous amènera à bon port ?’ ; ‘Que dit la Qualité ? ? ;-)

Cette culture du Moyen sclérose donc les grands projets et la valeur Courage a quitté les grandes entreprises et ses managers. Il est d’ailleurs symptomatique de voir a quel point les méthodologies dites éprouvées introduisent un niveau élevé de complexité. Cette complexité permettra a chacun d’oublier les mots PRAGMATISME et EFFICACITE et déouvrir le parapluie ITIL/CMMI/RUP/? quand la pluie (l’utilisateur) viendra.

Que dois-je faire ?

? Faire preuve de Courage : Le courage n’est ni l’ennemi de la raison, ni synonyme de dissidence

? Multiplier les acteurs transverses afin de gommer les dégâts que provoquent les hiérarchies en mode Projet

? Manager les unités de facon à ne pas faire disparaitre la valeur Courage

? Inverser les ratios entre armée de Spécialistes et bons généralistes

L’espoir réside donc sur la capacité des Managers à recruter et positionner de bons généralistes pragmatiques et courageux. Il est à noter que ces profils ne sont pas de futurs spécialistes, mais bel et bien des anciens (et généralement des très bon).

Les amateurs de Jazz feront facilement le parallèle du sujet avec la musique éprouvée (Le classique) et la musique Agile (Le Jazz).

Eric K.
eric.kdual@eaichannel.com

Si la mise en oeuvre d’un projet informatique représente un investissement financier conséquent pour le donneur d’ordre, elle représente, pour le maitre d’oeuvre, un risque sur son déroulement de carrière. Alors comment, en cas d’échec, justifier d’avoir travaillé selon une méthode utilisée par seulement 1% des grandes entreprises. Mieux vaut encore utiliser une méthode qui permettra d’aboutir, même laborieusement, à un produit conforme à une ‘expression de besoins’. Mettre en oeuvre une méthode agile, c’est entrer en dissidence avec l’ordre établi. Ce qui conduit forcement à l’échec dans les structures hyper hiérarchisées de nos grandes entreprises.

Pour le moment, ce type de méthode ne peut séduire que de petites ou moyennes structures dirigées par des individus impliqués dans l’opérationnel, n’ayant pas forcement une forte culture informatique mais dont les objectifs dépassent la simple délivrance d’un outil.