| |
 |
Pierre Pezziardi
Directeur Technique
Octo Technology |
|
Pierre Pezziardi
"Il manque aujourd'hui deux profils : l'architecte et le chef de projet"
L'auteur du livre "Une Politique pour le Système d'Information" a répondu aux question de nos lecteurs sur la gestion de projets et des SI, entre autres.
08/06/2006 |
| |
|
 |
Qu'entendez-vous par "communication par pattern" ? A quoi cela sert-il dans un projet informatique ?
Pierre Pezziardi. On constate beaucoup de phénomènes d'ignorance sur les projets. Il y a un réel besoin de partager PLUS d'informations ... Dans la communication par pattern, l'idée est de rechercher en permanence un axe pédagogique qui permette de partager de l'information entre différentes "castes" : dirigeants, métiers, analystes, programmeurs, exploitants...
Que pensez-vous d'ITIL ? Cette méthode constitue-t-elle une aide réelle ?
ITIL, comme CMM, est un référentiel pour manager. Il dit ce "qu'il faut faire", pas "comment le faire". Exemple : il faut gérer la mise en production, la configuration des logiciels, ... oui mais comment? Quand l'organisation qui les produits est distribuée, utilise des outils divers et variés, etc. ITIL c'est un aide mémoire ...
Les castes dont vous parlez sont-elles habituées à travailler ensemble ?
Justement, la posture empathique, pédagogique, aide à faire en sorte que l'autre s'intéresse à vous ... mais vous avez raison, là où on le met en place, nous "coachons" les différents acteurs pour qu'ils retrouvent des réflexes oubliés : l'écoute, le droit de dire une bêtise, la participation des plus timorés, etc.
Quelle doit être la répartition idéale des tempéraments dans une équipe projet ?
Page 132 du livre ! Plus sérieusement, on pense qu'il manque surtout deux profils aujourd'hui : l'architecte qui fait le pont entre les communautés (vous savez, celui qui parle à tout le monde, qui mange avec untel, qui téléphone à chmol sans demander l'aval de son chef, ..). Le deuxième est le chef de projet, plus dans un rôle de coach, c'est-à-dire d'animation des rituels de l'équipe, dont ceux destinés à maintenir la qualité, malgré la pression des utilisateurs ou des MOA.
Quelles sont les qualités qui peuvent permettre à un chef de projet de passer directeur de projet ?
| |
|
 |
|
|
 Le directeur de projet doit être quelqu'un qui sait - aussi - regarder vers le bas" |
|
Vous êtes chef de projet ? Le directeur de projet, comme le chef de projet, doit être quelqu'un qui sait - aussi - regarder vers le bas (ses équipes, la qualité du logiciel...), pas uniquement vers le haut...
Comment impliquer les utilisateurs dans un projet ? Est-ce la seule façon de gérer le changement ?
Vaste débat. Je pense qu'il faut commencer par distinguer diverses catégories d'utilisateurs, comme le fait Moore : des enthousiastes pleins d'idées au plus sceptiques. Nous suggérons donc d'utiliser les premiers comme utilisateurs pilotes / maîtrise d'ouvrage, tandis qu'il faut veiller à vendre son produit pour les autres...
Je suis chef de projet intranet. Nous avons un portail interne employés. Par où commencer ?
Commencez par chercher ce fameux "utilisateur pilote", c'est simple : soit c'est un gars qui râle parce qu'il aimerait avoir ci ou ça, soit c'est quelqu'un qui vous a déjà parlé d'une de ses "envies". Envies ou douleurs des utilisateurs : partez à la chasse, et traitez-les une par une en mettant en production régulièrement.
Comment identifier un projet porteur d'innovation ? Quel traitement lui réserver ?
Un projet porteur d'innovation, c'est d'abord un Innovateur, une personne physique, qui prend un risque dans la structure ... Nous suggérons de lui réserver un traitement spécial, par exemple sur la base d'un "second guichet de la DSI", qui travaillerait hors contraintes transversales.
Dans ces conditions, de telles équipes sont capables de s'aligner sur du délai très court et un cahier des charges très flou ... Essayer de faire de l'innovation au coeur du SI est impossible (on a déjà essayé).
Quelle solution dans le cas d'un projet impliquant plusieurs services, chacun voulant conserver son pré carré et bloquant le chantier ?
On a proposé des schémas organisationnels de la DSI recentrés sur les applications, et combinant donc MOA et MOE sur des mêmes objectifs, incluant la qualité du logiciel, et pas les coûts partiels du cahier des charges.
Une telle organisation pourra éviter les phénomènes de tribalisme courants dans et autour de la DSI ... l'organisation changeant les objectifs et les contraintes des acteurs, on peut espérer qu'elle les change un peu au passage ...
Dans votre livre, vous parlez de la "bureaucratie" autour d'un projet. Qu'entendez-vous par là ?
On constate qu'on "parle" plus des logiciels que l'on en "produit". Nous suggérons que plus de gens "produisent" du logiciel, c'est-à-dire des applications et des tests automatisés autour.
Un directeur de projet est-il forcément charismatique ?
| |
|
 |
|
|
Les êtres charismatiques sont aussi, souvent, des personnes égocentriques" |
|
Souvent, cela aide, car les projets impliquent souvent beaucoup de monde, nécessitent des changements dans la structure, et ont des moments d'intenses douleurs (deadlines serrées, bugs, collisions de structures, ..).
Le charisme aide dans ces situations. Maintenant, les êtres charismatiques sont aussi souvent des personnes égocentriques, qui ont parfois du mal à s'occuper de leurs équipes dans la durée (cf. le rôle de coach évoqué plus haut)...
Que faire quand un système développé n'est pas conforme au cahier des charges mais convient aux utilisateurs finaux ?
Jetez le cahier des charges. En France on a tendance à croire plus aux modèles qu'à la réalité observable. Or "tous les modèles sont faux, certains sont utiles" ...
En quoi votre approche incrémentale permet-elle de gagner en rapidité ou en efficacité ?
Comparé à une approche classique dite "en cascade" où l'on va s'attacher à décrire la TOTALITE du système avant de le construire (notez l'emploi du "on"... qui est "on", qui est dépositaire du besoin ?), l'approche incrémentale permet d'affiner un logiciel avec ses futurs utilisateurs.
Par ailleurs, l'approche incrémentale est la manière la plus évidente de gérer les risques d'un projet. Je ne vous redonne pas les statistiques de taux de succès des projets informatiques ...
Comment évaluer là où l'on en est du cycle de vie d'une application ? Et comment décider de tuer une application ?
Nous avons proposé une taxonomie issue de notre expérience : prototype (j'essaie de vendre un truc, à des utilisateurs internes ou des clients), pilote (j'en ai vendu un au moins, c'est en production), pré industrialisation (j'ai plusieurs clients, l'enjeu commence à devenir les coûts, la sécurité, l'intégration au SI.
On tue des applications innovantes parce qu'elles ne servent à rien : tel bidule censé attirer telle clientèle a en fait échoué deux ans après. On tue très rarement des applications dans le SI, on les fusionne dans des applications plus larges qui peuvent reprendre marginalement (avec un surcoût faible) leurs fonctionnalités.
Quels sont les éléments tangibles de l'analyse de rentabilité d'un projet ?
J'ai un aphorisme qui dit : "les informaticiens parlent souvent de ROI, mais ne s'intéressent en fait qu'au dénominateur" . Décryptage : la "valeur" produite par un logiciel est quelque chose de délicat à estimer, encore plus à suivre dans la durée : nombre de personnes mises à la porte grâce au traitement automatisé, diminution des délais de traitement de truc, "si on le fait pas, on sort du marché", etc.
C'est d'abord au métier de s'exprimer là-dessus. Nous avons une méthode qui marche pas mal pour évaluer de la "valeur". On procède - comme les banquiers - par "coût de remplacement" : et si je vous l'enlève l'application, combien coûte de gérer tout cela avec Excel et des gens ...? Faites-le test !
Quelles questions un directeur de projet doit-il se poser sur les limites de ses projets ? Des limites de volumétrie, de pérennité... ?
On s'aperçoit, souvent après coup dans une analyse par pattern d'un existant, que des choix structurants (patterns métiers ou techniques : par exemple, interpréteur comptable, 3-tiers), créent des limites.
Ce que je vous conseille, c'est d'analyser votre projet sous l'angle de ces caractéristiques structurantes, et surtout de le partager avec les techniques et les gens du métier. Faites-vous challenger vos limites en séances collectives !
Quels sont les avantages et inconvénients de CMMi ?
| |
|
 |
|
|
Il est impossible d'innover dans une structure contrainte" |
|
ITIL. Comme CMMi est sur le "quoi" et pas le "comment". "Il faut gérer la qualité", oui mais comment ? Dans les faits, sa mise en place ne fait que renforcer les pratiques existantes : la structure est adepte de la cascade, CMMi augmentera le nombre de documents, la structure est adepte du développement Agile, CMMi amplifiera les pratiques orientées qualité : programmation par paire, tests automatisés...
Que pensez-vous des sociétés d'offhsore programming ? Les recommandez-vous au DSI français ?
Il y a un paragraphe là-dessus dans UPSI (Une Politique pour le Système d'Information) : en gros, ces fournisseurs sont excellents, mais nous ne les utilisons qu'à un centième de leurs capacités car nous leur imposons le plus souvent ... la cascade.
Or, ce processus marche mal, accumule les risques, que ce soit avec un partenaire local ou distant.
Vous parlez dans votre ouvrage du pilotage en zone chaos, pouvez-vous nous en dire un peu plus ?
L'idée de base est qu'il est impossible d'innover dans une structure contrainte (l'éléphant dans le magasin de porcelaine). Nous proposons donc d'attirer les innovateurs métier (les gens qui ont des idées pour vendre plus ou travailler mieux) vers une structure à moyens légers et sans contraintes.
Nous considérons qu'écrire le logiciel plusieurs fois en lui faisant passer des transitions du chaos vers la zone rationalisée est le processus de construction le plus optimisé ...
Quelle est selon vous la meilleure façon de piloter les tests ? A quels moments, à quelle fréquence ?
L'idée est de renverser la logique actuelle. Plutôt que de les mettre à la fin, mettez les au début, et profitez de l'activité d'automatisation de ces tests (injection dans les applications avec des outils type Fit/Fitness) pour faire travailler les analystes avec les développeurs directement, plutôt que via des spécifications écrites.
Comment vous est venu l'idée de créer Kianometro ?
Un fidèle ! Pour info, Kianometro est une petite application Java qui tourne sur mobile et qui vous indique un trajet de métro optimisé.
Comme toute innovation, elle part d'une douleur ou d'une envie, là c'était plutôt l'envie : rejouer avec du code après quelques mois de consulting DSI/DG, tater cette plate-forme J2ME pour sentir d'éventuels débouchés pour OCTO ...
Que conseilleriez-vous à un développeur pour parfaire son "relationnel" et plus globalement sa capacité à interagir efficacement avec les autres dans la société ?
Notre théorie là-dessus est simple : vaincre sa peur, peur de ne pas être à la hauteur face à ce monsieur en costume qui s'exprime par jargon (mais comprend-il vraiment ?), peur de poser une question "bête" (mais dont 10% de l'assistance de la réunion avait la réponse), etc.
Dans un échange, celui qui gagne, c'est celui qui a tort, il repart avec un nouveau savoir. L'autre repart comme il est venu.
Quelle est selon vous la condition sine qua none pour réussir son projet informatique ?
| |
|
 |
|
|
Il faut veiller à ce que les mises en production incrémentales aient un coût marginal" |
|
Cela me donne l'occasion de revenir sur les 5 piliers de l'ouvrage :
1/ raisonner équipe et talents, pas tâches
2/ Imposer l'incrémental : on est toujours capable de livrer dans un environnement accessible aux utilisateurs les cas d'usage qu'on a implémenté. Il faut veiller à ce que ces mises en production incrémentales aient un coût marginal, par exemple avec des usines de développement
3/ Communiquer autour de vous, de préférence par pattern, c'est-à-dire avec des transparents sur des concepts clés, vous savez ceux qui traînent parfois en poster des années après parce qu'ils restent une référence aux yeux de tous.
4/ Pilotez votre projet par les tests, c'est à la fois une assurance qualité et un indicateur réel de l'avancement (pour en finir avec le 98% complète).
5/ N'essayez pas de réaliser un projet innovant au milieu de la structure et de ces contraintes. En innovation, small is beautiful.
Comment en vient-on à travailler dans un cabinet d'Architecture en Systèmes d'Information ?
On envoie son CV au Cabinet D'architecture en SI. Sérieusement, si je regarde ce que les gens partagent le plus à Octo, c'est la passion pour les ordinateurs. Partant de là, on a des talents d'expertise et des talents - souvent orthogonaux - de communicants, qui composent nos différents métiers.
Pierre Pezziardi : Merci à tous. C'était très agréable ! A bientôt. Et achetez le bouquin !!
Le livre "Une Politique pour le Système d'Information" est disponible à la vente sur le site www.octo.com et à la Librairie "Le Monde en Tique".
|
| |
Propos recueillis par Rédaction JDN & JDN Solutions |
|
|
PARCOURS
|
|
|
| |
Pierre Pezziardi
est directeur technique d'Octo Technology. Il est diplômé de l'Ecole Centrale de Lyon (1994).
1995-1998 Consultant chez Sycomore.
Et aussi Egalement auteur de "Serveur d'Application, Intégration d'Application, le projet eCRM" (ed. Eyrolles) et de livres blancs.
|
|
|
|
