| Témoignage |
 Écrivez à AILES ! |
 Retour vers l'article (chef de projet) |
Retour vers l'article (projet en manque d'itération - Colin LORRAIN) |
Retour vers le dossier Chef de projet |
|
Christophe Thiry a bien apprécié le témoignage du jeune ingénieur Colin LORRAIN sur la façon dont un projet informatique a été mené. Il trouve en plus qu'il faut beaucoup de courage pour exprimer ce genre d'avis. Toutefois, Christophe, en chef de projet confirmé, tient à réagir sur quelques points de ce texte, face à la découverte (un peu brutale) de la plupart des facettes du métier de chef de projet par Colin! Christophe va donc reformuler ici ce que M. Lorrain a vécu avec sa perception propre. Il expliquera au passage ce que l'on peut faire "pour s'en sortir" : il ne s'agit pour lui de donner des "astuces" mais plutôt d'évoquer la mise en place d'éléments de gestion structurants. Mes "questions" sont en italique rouge. Mes remarques sont en [italique rouge entre crochet]. Les "citations remarquables" de mon interlocuteur sont mises en exergues en gras italique bleu. Certains concepts importants de cet entretien sont gras italique. |
I/
MOA & DSI face à MOE
[Dans la droite ligne de sa précédente
intervention sur MOE
et MOA - Maîtrise d'Œuvre
et Maîtrise d'Ouvrage, Christophe Thiry revient sur le danger à se
tromper de rôle : illustration :]
"le DSI (...) qui retouche le modèle
de base de données"
Alors celle-là, elle est excellente ! 
1/ Ca me rappelle un projet que j’ai pu
observer de l’extérieur, où le schéma de BDD était conçu … par
le client, eh oui ! Et par itérations successives. Alors il
changeait en moyenne 3 fois par semaine. [Tiens,
cela rappelle le
projet cauchemar, où le
cahier des charges changeait toute les semaines. En changeant le
schéma de sa base de données, le client se trompe complètement...]
L’équipe projet était composée
exclusivement de techniciens chevronnés, mais sans réel chef de
projet. Ils arrivaient péniblement à obtenir la description des
fonctions à réaliser, puis ils commençaient à créer des écrans
avec leur L4G, et, quelques jours plus tard, tout était à réadapter.
Alors ils stagnaient. Ça a duré un trimestre. Les gens de la SSII étaient
fous. Mais ils n’étaient pas assez trapus ni expérimentés en gestion
de projet pour refuser l’inacceptable.
Le schéma de base doit faire partie de la
fourniture de la prestation. Il doit venir du fournisseur et non du
client. Tout au plus le client exprime des besoins, qui peuvent être
très détaillés en terme d’exigence de modélisation. Mais le
client ne fait pas le modèle à la place du fournisseur. Au passage,
c’est encore une histoire de confusion des rôles.
[Très juste, et cela est d'autant plus vrai
que la MOe utilise un L4G, dont la couche présentation est par nature
très liée à la couche stockage de donnée...]
Alors que faire ? il faut impérativement
proposer le changement qui s’impose. Avec tact, délicatesse,
souplesse et amabilité, il faut mettre en place une réunion avec le
client pour :
- expliquer exhaustivement les dysfonctionnements,
- proposer un nouveau mode de fonctionnement,
- et ensuite négocier pour obtenir un mode de fonctionnement qui convienne aux deux.
Pour la petite histoire, le projet ci-dessus a pédalé dans le vide pendant un an. Vous rendez-vous compte ? Pendant un an, le client a payé 3 ingénieurs de SSII, pour rien. Un autre responsable côté client a été nommé et tout à été repris de zéro un an plus tard.
2/ Deuxième point qui me choque : « le DSI retouche le modèle »... vous voulez dire son équipe ? Parce que, en général, le travail du DSI consiste à maîtriser la stratégie informatique de son entreprise. Ce n’était peut être pas un DSI, même s’il se faisait appeler comme cela. C’était peut être seulement un Responsable Informatique, ce qui n’excuse rien du reste. En tout cas, un homme qui voit l’informatique par le petit bout de la lorgnette.
Le DSI n’est plus, par nature, impliqué directement sur les projets. Il a des chefs de projets pour cela. Sinon il ne peut plus faire face à son cœur de métier. (maîtrise de l’évolution des processus métier, des budgets, des évolutions techniques).
« [...] tout ceci va conduire à du logiciel inadapté et qu’il était important d’intervenir.
Et bien ce n’est pas votre problème ! Vous vous prenez pour un bon samaritain ou quoi ? »
II/ Rôle contractuel des spécifications
[Dans la partie suivante, Christophe Thiry revient sur le rôle du client, tel qu'il est présenté par Colin Lorrain au travers de phrases telles que :
"la phase de conception est validée par le client au travers de son DSI qui est notre interlocuteur"
"le projet ayant été défini dans un CdC pris en main par la DSI, coupant ainsi tout rapport avec les utilisateurs finaux (là) […] la page intranet de saisie des produits est en fait une application complète de gestion de stock" (et là)
"l'acteur le plus précieux reste le vrai client (...) la définition fonctionnelle du projet commence"
Christophe va rappeler ici l'importance de la relation contractuelle avec le client, relation qui peut donner l'impression d'une certaine distance et qui prend la forme d'un cahier des charges - côté client - et d'une spécification formelle - côté MOe : cf. spécifications (Besoin)]
(je vais être un peu provoquant, ne m’en veuillez pas !
)Le rôle de la DSI et de ses chefs de projets (MOa) est la maîtrise des besoins de l’entreprise. Pour ce faire, ils rédigent un CdC [Cahier des Charges]. C’est bel et bien leur rôle et leur fonction.
L’auteur (MOe) se plaint ici de n’avoir pas eu directement accès au client interne de l’entreprise : c’est normal et même souhaitable qu’il n’y ait pas accès.
De quoi se plaint-il ? Que les besoins réels de l’entreprise n’ont pas été perçu ?
Et bien cela va vous choquer mais : ce n’est pas votre problème !
Lorsque la MOe se met à requalifier les besoins exprimés par la MOa :
1. elle utilise le temps qui lui est imparti à autre chose qu’à la mise en place du projet,
2. elle empêche la MOa d’apprendre son métier,
3. le DSI peut (légitimement) estimer avoir été court-circuité dans l’affaire et commencer à se méfier de votre probité.
Vous me répondrez que tout ceci va conduire à du logiciel inadapté et qu’il était important d’intervenir.
Et bien ce n’est pas votre problème ! Vous vous prenez pour un bon samaritain ou quoi ?
Je maintiens que non : si vous le faites, ça se retournera toujours contre vous.
Tout ce que vous avez à faire est de jouer votre rôle de conseil auprès de votre client et lui exprimant de façon argumentée que, au vu de vos entretiens, il ressort que « la page intranet de saisie des produits est en fait une application complète de gestion de stock » PUIS :
1. à vous d’attendre une décision du DSI de donner suite ou de maintenir en l’état (option qu’il peut légitimement prendre : si on écoute les clients, les besoins n’ont jamais de fin)
2. à vous de gérer le point comme une demande d’évolution, c’est à dire de chiffrer combien d’homme jours sont nécessaires à la réalisation, etc.
Et si le DSI tranche pour maintenir la page de saisie internet telle quelle, il faut dire amen.
Je vous conseille donc une extrême prudence en la matière car rien n’est aussi simple que les slogans comme « le client a toujours raison »
Ceci dit, je n’en veux pas à l’auteur. Je suis moi aussi tombé dans ce genre de piège au début de ma carrière.
III/ Client obtus - Client cadré
[Face au comportement de certains clients, Colin Lorrain conseille :
"évitez le client-roi" (ici) ou
"si vous rencontrez un client obtus, fuyez"(là)...
Certes, mais Christophe Thiry propose - et illustre - une solution complémentaire!]
Évidemment, je ne peut qu’être d’accord, sauf pour la fuite.
On doit CADRER un client. Cela s’apprend … par la pratique.
On ne lui dit jamais « non », mais on lui expose, gentiment, simplement, avec tact et délicatesse, mais clarté et in extenso toutes les conséquences techniques, fonctionnelles, organisationnelles de ces demandes. Alors bien souvent, c’est lui qui dira « non » avant vous.
[Ce conseil avait déjà été donné par ce chef de projet en mai 2000]
L’histoire du DSI barbu qui voulait changer Sybase en dBase IV.
Dans une autre société Y, il y avait un DSI barbu (on l’appelais « joli barbu » : il donnait l’impression d’être dans les nuages) qui avait fait mettre en place un lourd système de gestion de je ne sais plus quoi concernant les clients de sa société, la base de donnée était assez grosse. La chef de projet l’avait fait réaliser sur l’architecture technique standard de l’endroit : Sybase + beaucoup de procédures stockées + client lourd powerbuilder (à l’époque, il n’y avait que du 2 tier)
Un jour, le barbu la convoque et une heure plus tard, elle sort dépitée de son bureau :
« il m’a demandé s’il était possible d’utiliser dBase IV à la place de Sybase ! Je lui ait dit que c’était complètement idiot ! Mais il n’a rien voulu savoir. Il veut que j’étudie la possibilité de le remplacer. »
Évidemment pour un info-technicien, c’est idiot de prendre une rolls sur mesure, d’enlever le moteur pour le remplacer par moteur de 2 CV ! Mais néanmoins, elle peinait à convaincre le barbu. Lui, têtu, mais sans expérience informatique, il considérait le SGBD comme un paramètre comme un autre : un petit carré sur un dessin global, changeable à volonté par un autre.
Et bien elle est restée scotchée comme ça quelque temps, puis elle s’en est sortie patiemment, en expliquant à son chef les conséquences d’un tel changement :
| Argument | Type d'argument | Effet sur le DSI |
| Plus de procédures stockées dans dBase | technique | pas convaincu |
| Donc : refaire toute l’application client | technique | pas convaincu |
| Donc : tant d’homme-jour dépensés en pure perte | business | convaincu |
| Plus de moteur ni de procédures stockées | technique | pas convaincu |
| Donc : serveur de données utilisé seulement comme serveur de partage de fichier dBase | technique | pas convaincu |
| Donc : déplacement du CPU du serveur vers le client | technique | pas convaincu |
| Donc : on doit renouveler tous les PC client pour des machines 2 fois plus chères. | business | convaincu |
| etc... |
Cette jeune chef de projet a appris quelque chose : « les autres » ne sont pas forcément sensibles aux mêmes arguments que soi. Elle avait finalement assez mal jugé son chef.
Et enfin, le DSI a laissé tomber la demande.
Si vous rencontrez un client obtus : surtout ne le méprisez pas et continuez à discuter de façon ouverte, peut être que vous même n’avez pas tout à fait tout compris ! Vous en sortirez toujours quelque chose de positif.
[Autre forme de "client obtus", celui qui veut tout faire tout de suite, ce que Colin Lorrain décrit par la phrase : "le client a voulu tout faire d'un coup en un seul projet" . Là encore, il faut cadrer le client.]
C’est son droit le plus strict.
Si c’est le cas, le projet doit être chiffré et planifié conformément à la quantité de travail requise pour la réalisation attendue, quelle que soit sa taille.
Cela passe par l’acquisition de la maîtrise de la gestion de projet, qui, une fois acquise, peut s’appliquer à des projets de taille absolument quelconque.
IV Évaluation et Chiffrage
[Cet aspect, le chiffrage, se retrouve évoqué par la phrase :
"les délais de réalisation étaient insuffisants"
Les délais de réalisation sont à évaluer par le chef de projet.
Le chiffrage, art d’évaluer des tâches mérite à lui seul une page.
[cf. ce témoignage pour des exemples de techniques de chiffrage...]
Une petite anecdote.
J’avais un ancien collègue (qui est resté ami) qui avait l’habitude d’évaluer ses tâches à … 1 heure ou 2 heures. Entre lui et moi, c’était un dialogue de sourd :
- « Combien de temps il te faut pour développer le module truc ? »
- « Bof … 2 heures ! »
- « C’est matériellement impossible ! »
- « Si, si … 2 heures ! »
- « Bon, ok, vas y. Top chrono. »
En fait, son module était un ‘cross-développement’
Il avait besoin de la disponibilité d’une plate-forme spécifique contenant l’outil de développement pour coder et télécharger le résultat sur la machine cible, et, pas de chance, cette plate-forme était la ressource critique, souvent prise par les autres équipes pour faire un travail équivalent. Pas moyen de démarrer à l’heure !
De plus, avant même de démarrer le développement il fallait repartir d’une plate-forme propre et décharger une bande magnétique contenant un état de plate-forme initiale propre. L’opération à elle seule prenait deux heures.
Etc..., il y avait d’autres contraintes de ce type là, que je passe pour simplifier
Mais en ajoutant toutes les contraintes … on ne pouvait réellement commencer à travailler que au mieux un jour plus tard, et après, seulement après, le développement lui- même prenait deux heures, le test unitaire une heure + une correction des erreurs de son programme + re-test unitaire, à nouveau deux heures, soit un jour.
Coût total : deux jours !
Méfiez vous quand on vous dit que tel tâche dure moins d’un jour : est-ce que vous avez vraiment tout compté dedans ? est-ce que les conditions sont réunies pour que tout se déroule sans problème ? est-ce que vous avez toutes les informations ?
Dans chaque tâche il y a toujours : le temps de préparation, pour réunir les conditions dans lesquelles on peut réaliser le travail, puis le temps de livraison/terminaison.
Ceci dit, la conclusion est la même pour les tâches longues.
Il faut toujours vous méfier de l’origine de l’information. L’information n’est rien sans savoir expliciter la façon dont elle est construite.
[L'aspect chiffrage se retrouve illustré par la phrase :
"la partie internet commence donc avec déjà du retard"
C’est pourquoi, dans les projets, on a l’habitude de séparer la phase d’étude de la phase de réalisation. Ce qui a pour avantage de faire deux planning séparés : un pour l’étude, l’autre pour la suite, à ne jamais fournir au début, pour une raison simple : c’est en fin d’étude que l’on connaît le contenu du système, alors comment peut-on planifier quand on ne sait pas ce que l’on va faire ? [heu... c'est une des questions posée par le projet cauchemar : Waterfall !!!]
Donc le premier planning doit se limiter à la phase d'étude.
Il est très probable que le sujet ne soit pas mûr. La date de fin d’étude se décale donc spontanément ‘vers la droite’.
Ce n’est pas grave. Informer régulièrement des décalages provoqués par ses non-réponses et ses hésitations.
[Cette séparation claire des phases - entre étude et réalisation - doit permettre d'éviter la phrase suivante : "les incohérences fonctionnelles du cahier des charges se révèlent"
Ce point par contre est inacceptable pour un MOe.
Les incohérences doivent être étudiées et identifiées dans la phase d’étude : cela s’appelle valider les documents.
Valider, ce n’est pas corriger les fautes d’orthographes, c’est obtenir la conviction saine que le futur système est correctement défini.
Il faudrait en savoir plus sur ces ‘incohérences’ pour affiner le diagnostic.
V Gestion de projet
[Colin Lorrain utilise d'ailleurs, pour conséquence de cette situation issue d'une évaluation mal contrôlée, la phrase : "le chef de projet ne sachant plus où donner de la tête ..." (ici), ce qui attire le commentaire suivant de Christophe Thiry :]
Cela résulte du manque d’expérience et de pratique. Mais, rassurez vous, cela viendra et bientôt, les ficelles du métier n’auront plus de secret pour vous. Je suis convaincu que six mois est le strict minimum pour acquérir une bonne maîtrise de base.
Pour gérer une situation complexe comme celle-là, il faut … la diviser !
Ce que je conseille pour éviter d’avoir le sentiment de confusion est de noter systématiquement chaque problème et de le classer selon un domaine, qui sont (non exhaustif) :
- gestion des besoins du client
- chiffrage
- planification
- rôles et organisation de l’équipe
- suivi de la réalisation
- gestion des livraisons
- applications
- documentations
- gestion des demandes d’évolutions
- gestion des anomalies
- reporting hebdomadaire
- etc.
Ensuite, pour chaque problème, désigner une personne qui sera chargée de trouver une solution. Quelquefois c’est vous, mais souvent non ! (en particulier, la gestion des anomalies, la mise à jour documentaire, etc.)
On arrive donc à la problématique de la délégation.
VI Gestion de projet et Management
[Sur l'aspect management, qui est évoqué dans ce dossier, Colin Lorrain évoque le fait que "tout chef de projet se laisse bouffer par son management... n'est pas capable de faire valoir ses besoins"(là)]
Le chef de projet se laisse envahir, parce que :
- il ne sait pas (encore) faire son métier et maîtriser la gestion de son projet
- il ne sait pas communiquer et expliquer
- il n’inspire pas (encore) confiance
Il est vrai aussi que, la spirale infernale se déclenche : plus le projet va mal, plus le management intervient, ce qui gêne le chef de projet, ce qui fait aller le projet encore plus mal.
Il faut savoir maintenir son management à la bonne distance. Pour cela il faut :
- lui fournir la quantité d’information qu’il lui faut. Pas plus.
- lui expliquer avec courtoisie que vous avez du travail.
[Colin Lorrain évoque également une autre interférence du management, au travers de la gestion des ressources : "le manager qui reprend les ressources a chef de projet qui ne sont pas rentables"
La phrase « Les ressources qui ne sont pas rentables » est trop équivoque.
Est ce que ce sont des ressources qui ne sont pas occupées à 100% ? Auquel cas, le chef de projet ne délègue pas suffisamment sur eux. Mauvais point.
Est ce que ce sont des ressources qui par leur présence font sauter la marge bénéficiaire du projet ? Dans ce cas, c’est le problème du directeur de projet qui a sous vendu son système.
S’il vous retire une ressource, vous devez immédiatement faire le calcul pour en exprimer les conséquences en terme de charge se reportant sur les autres et de planning, c.à.d., de date de livraison.
Si vous savez faire ce calcul de tête approximativement, vous pouvez même vous payer le luxe d’une réponse immédiate.
De plus cela ne règle pas le problème de la marge bénéficiaire car la charge va se reporter sur les autres membres…
Dans la vie : « décision è conséquences ». Si le manager persiste, alors c’est à lui d’aller devant le client.
Conclusion
Finalement, nous constatons bien que le métier
de chef de projet est un métier de gestionnaire : c'est à dire un métier
radicalement différent du métier de développeur ou d’expert
technique. Contrairement à une idée reçue, je suis persuadé
qu’un bon gestionnaire rigoureux peut faire aussi bien, voire mieux
qu'un ex-développeur.
[Et c'est là une des grandes lois des projets informatiques : plus précisément
la Loi n° 5]
Ce qui est contradictoire et inquiétant, c'est
le nombre important d'annonces d'emploi du type "chef de projet
Java", "chef de projet SAP", "chef de projet
truc", alors que toute la substance du métier se trouve ailleurs
: il y a alors de grandes chances que le poste soit en réalité une
forme déguisée de responsable technique !
Le paroxysme est atteint avec "Directeur de
projet java". Si le poste est vraiment une direction de projet,
alors la connaissance de Java, on s'en balance.
Voilà, j’espère que je ne vous a pas trop
ennuyé.
Le métier de chef de projet est absolument
passionnant. Il ouvre la voie à d’autres métiers encore plus
passionnant de l’entreprise.
Décollage ! | Présentation du site web "AILES" |
Infos générales | articles "Informatique"