Articles « Info » : Chef de projet

    « Un chef de projet, c'est un peu un pilote de rallye ! »

En fait, c'est quoi "chef de projet" ?
    C'est simple : avant, en tant que développeur, vous serriez les boulons d'une voiture sans trop avoir de vision d'ensemble. En tant que chef de projet, vous êtes au volant de cette voiture, c'est un bolide, vous la conduisez sur plusieurs spéciales dont le trajet change parfois en temps réel, et en plus, vous avez des personnes à l'arrière!
[Cette vision d'ensemble est la caractéristique des postes tels que chef de projet ou architecte]

Aaah heuuu, d'accord, d'accord... Et tout ça vous apporte quoi ?
    Pour vous, essentiellement une meilleure connaissance de vous-même, de vos limites et de la manière de les dépasser.
    Vous gagnez l'habitude d'une vision à long terme, le réflexe de la "vision d'ensemble", du recul qui vous permet de toujours considérer le projet comme un tout et non comme une simple somme de ses particularités. Et cela dans le but vital d'anticiper les problèmes.
    Vous apprenez aussi à gérer le stress qui accompagne toutes les phases d'un projet. Il faut absorber ce stress de façon à protéger votre équipe, mais aussi votre famille, car, lorsque vous rentrez à la maison, vous n'arrêtez pas de pensez à votre projet... Sans cette gestion du stress, vous découvrez qu'il se communique très facilement.
    Enfin, si vous faites bien votre boulot, cela ne doit pas s'arrêter à votre seule personne : toute votre équipe doit avoir progressé aussi.
[cf. aussi Informaticien et Cadre ? - Qu'est-ce qu'un cadre ?]
    « Ils ne savaient pas que c'était impossible, alors ils l'ont fait. »

Le stress ? Mais réussir un projet, c'est possible ou non ?
    Mauvaise question, car elle ne se pose pas vraiment dans ces termes. Gérer un projet, c'est d'abord un état d'esprit. Les gens qui affirment que quelque chose est impossible sont sans cesse interrompus par ceux qui viennent de le faire.
    De plus, un projet, c'est vivant, ça évolue alors que vous le réalisez. Il est rarement "réussi" dans l'absolu, mais il l'est parce que vous, votre société et le client se sont entendus pour le déclarer "réussi" (et payer la facture!).

    « Il faut savoir resserrer les tuyères et savoir dire non. »

Bon, commençons par le tout début : le commercial vient de récolter un contrat et vous rencontrez le client pour la première fois. Comment ça se passe ?
    Ne vous faites pas d'illusions : lorsque vous rencontrez le client, les tuyères sont ouvertes au maxi. En d'autres termes, le commercial a affirmé : « Nous savons tout faire ».
    Du coup, le client va vous poser quelques questions. Face à ces questions, votre survie dans le projet à venir dépend de votre capacité à resserrer les tuyères, c'est-à-dire à diminuer l'éventail des tâches à réaliser.

Hmmm... des exemples ?
    Facile : au cours de la question, le client vous lance négligemment :
- « au fait, il est bien entendu que le logiciel que nous vous commandons est multi-langue ? »
Répondez par un simple « oui, oui » et vous êtes mort. Avant même d'avoir vraiment commencé le projet.

Gloups... mais pourquoi ? C'est bien ce que votre commercial a vendu, non ?
    Je vous ai dit "vision d'ensemble". Vous avez donc fortement intérêt à répondre :
- « oui, mais ce sera à vous, client, de traduire *vos* Giga-octets de données, et en respectant le format convenu. Nous n'assurons pas le développement d'aucune "passerelle" entre vos systèmes et le notre. »
- « Vous n'allez pas nous emmerder, tout de même !? On paie 2MF pour ce projet, vous pourriez assurer ce service en plus, non ??? »
- « Je suis désolé, mais en terme de charge de travail, la migration de vos données représente quasiment à elle toute seule un projet à part entière. »
    Si vous n'êtes pas ferme à ce moment précis, la somme de travail initialement prévue et chiffrée peut 2 ou 3 mois plus tard, quand ce point reviendra sur le tapis, brusquement se retrouver multipliée par 10. Et pour le même prix.
    A vous de savoir dire "non".

"Dire non" ? Ca doit être simple à dire, non ?
    Dans une relation commerciale, dire "non" n'est jamais simple. En fait, on ne dit jamais explicitement "non", mais plutôt des "oui nuancé". Dans l'exemple précédent, la migration des données n'est pas quelque chose d'inacceptable en soi. Elle est tout à fait réalisable. Simplement, cela nécessiterait une renégociation, un avenant au contrat existant ou un nouveau contrat.
    Si cela semble de bon sens, même un "oui nuancé" n'est pas évident à sortir du tac au tac quand vous avez en face de vous un client au caractère bien trempé, rompu aux négociations commerciales et convaincu (comme les clients le sont souvent) "qu'il a déjà payé bien assez cher". Or vous n'êtes qu'un jeune chef de projet qui découvrez cet univers... vos réflexes en matière de négociation sont loin d'être au top. Et "dire non" au bon moment et de la bonne manière est un des réflexes les plus durs à acquérir.
[Christophe Thiry illustre cette difficulté dans son témoignage]
    Plus généralement, "gérer" un client et ses exigences n'est pas évident.

    « Le problème avec les clients actuels, c'est qu'ils sont devenus caractériels. »

Mais les exigences du clients sont formalisées, non ? Un cahier des charges, des specs ?
    Un cahier des charges, oui. Vous réécrivez donc ce cahier des charges pour en tirer des spécifications, tant fonctionnelles que I.H.M. [comme précisé dans l'article sur les spécifications].
Bien.
Et qu'est-ce qui vous dit que le client voudra bien signer ces-dites spécifications ?
Et qu'est-ce qui vous dit que votre direction, alléchée par les millions que le client est prêt à lâcher, ne vous "incitera" pas avec force à passer outre ce "petit" inconvénient d'absence de spécifications contractuelles ?
    A vous de bien lire le contrat de réalisation signé entre votre société et le client. Vous y découvrirez des règles de préséances qui, entre autres, font que le cahier des charges du client "a la préséance" sur tout autre document! C'est très pratique pour le client qui ne veut pas s'engager à signer quoique ce soit de plus que le contrat initial.

Mais pourquoi le client ne voudrait-il pas signer des documents plus formalisés ?
    Le "client", le "client"... vous parlez toujours du "client" ! Mais ce "client" est représenté par une personne qui a un nom, une fonction et aussi (et surtout) une hiérarchie. La-dite hiérarchie s'imagine avoir fait le plus gros en fournissant un cahier des charges et en signant un contrat de x millions de francs. Pourquoi cette personne signerait quoi que ce soit de plus, au risque de se faire reprendre par sa hiérarchie ? Si elle peut l'éviter, elle ne se privera pas.
    Dans ces conditions, vous naviguez à vue, avec un client le plus souvent caractériel.

Heu... caractériel, mais dans quelle mesure est-il caractériel ?
    Aujourd'hui, lorsqu'un client paie un projet, il lui semble naturel et (pire) implicite que l'application qui sera livrée comportera du "multi-fenêtrage", avec des "drag&drop" (ou "glisser-déposer") dans tous les sens et une aide contextuelle disponible d'une simple touche (F1) sur n'importe quelle partie du projet...
    C'est tellement implicite que cela n'est marqué nul part... et que cela vous est rappelé 3 mois plus tard alors que vous avez déjà bien d'autres soucis à gérer...
    Pour lui, il s'agit juste de « respecter les règles de l'art ». Pour vous... il s'agit de revoir une bonne partie de votre chiffrage et de négocier la diminution de marge qui s'en suivra.

    « Un projet, c'est un peu le bon, la brute et le truand : la marge, le budget et le chiffrage. »

Le chiffrage, justement, comment cela se passe ?
    Le chiffrage, c'est le nombre de jour en charge de développement (nombre jour par développeur, le "jour-homme"). Estimer un projet à "6 mois-hommes" revient à dire qu'il est en théorie finit en un mois... avec 6 bonhommes.
    Lorsque vous recevez le cahier des charges, votre boulot est donc de sortir un chiffrage du projet. Cela constituera votre "première estimation". En fonctions des délais imposés par le client, vous en déduirez le nombre de personnes nécessaires, et donc le budget souhaité.
    Évidemment, vous mettrez en opposition le budget souhaité d'une part et la marge imposée par votre direction d'autre part. Si le client paie tant de millions de francs, votre direction veut... par exemple 55% de marge. Pourquoi autant ? Parce qu'ils savent très bien qu'avec les retards, ils peuvent espérer en tirer quand même environs 30%.
Maintenant, vous savez cela et vous vous doutez qu'ils savent que vous savez cela.
Pourtant, si jamais votre budget fait diminuer ne serait-ce que d'un % cette marge de 55%, vous avez intérêt à venir avec beaucoup d'arguments bien présentés sur des slides préparées à l'avance... et à convaincre votre direction du bien fondé de votre chiffrage !
[Christophe Thiry rappelle l'importance du chiffrage dans son témoignage]

Alors, quelle est *la* méthode de chiffrage ?
    *La* seule méthode de chiffrage qui soit valable est celle qui croise le résultat de *plusieurs* méthodes de chiffrage. Parmi celle-ci, on trouvera :
- le chiffrage "macroscopique" qui consiste a examiner le chiffrage d'autres projets déjà réalisés portant sur le même domaine fonctionnel que le projet courant et à procéder par analogie,
- le chiffrage dit en "point fonctionnel" introduit par IBM et qui, pour chaque fonctionnalité et à l'aide d'abaques, vous permet d'y associer un nombre de jour/homme. Vous aurez identifié la complexité des fonctionnalités à la suite d'une (hâtive) première analyse du domaine fonctionnel mis en évidence par le cahier des charges du client,
- le chiffrage par ratio entre phases d'un projet : si votre première étude montre tant de jours d'analyse et de conception, alors il ne faudrait pas que le codage dure 10 fois ce temps ! Il existe des ratios qui lient les différentes phases et qui permet de conserver des proportions raisonnables entre chacune d'entre elles,
- le chiffrage commercial : si votre commercial vous indique que les différentes réponses à appel d'offre des concurrents sont entre "x" et "y" F, il faut que votre réponse soit un chiffrage dont le budget résultant se trouve au milieu de la-dite fourchette,
- enfin, le chiffrage "expert" qui consiste à porter le cahier des charges à un "vieux" chef de projet (plus de 10 ans de pratique), expérimenté dans le domaine fonctionnel qui vous occupe, qui soupèsera d'un air pensif le-dit cahier des charges avant de lâcher négligemment un « mmmf, ça doit pas prendre plus de 4 mois à tout casser, vot' truc. ». Si, si, ça existe.
    Recoupez ces 5 chiffrages et vous tiendrez le votre... Enfin, votre première version.

    « Il faut 9 mois pour faire un bébé. Vous aurez beau mettre 9 femmes "en parallèle", vous n'obtiendrez jamais un bébé en un mois ! »

Ah, parce que vous aurez "d'autres versions" de ce chiffrage ?
    Disons plutôt que d'autres facteurs peuvent moduler ce chiffrage, et parmi ceux-ci, on trouvera :
- le plan de montée en charge, qui vous permet de matérialiser les moments du projets où vous pouvez paralléliser le travail en engageant plusieurs personnes. Ces moments sont en général dur à identifier car on ne peut pas tout paralléliser dans un projet,
- la valeur financière du projet : inutile de prendre des risques si le projet "n'en vaut pas la peine",
- l'avis des développeurs (quand vous en connaissez déjà un ou deux) : si, après avoir jeté un coup d'œil à votre estimation, ils vous regardent d'un air haineux, une réévaluation pourrait s'imposer d'urgence !
- la marge de sécurité que vous voulez vous laisser (en gros, votre chiffrage initial * 2 ! ).

Cette marge de sécurité devrait vous permettre de finir le projet, non ?
    De le finir et d'empocher une belle prime : si vous arrivez à finir en avance, il n'est pas rare que votre direction se partage avec vous les jours (payés par le client) qui restent ! Toutefois... la marge est régulièrement utilisée... ne serait-ce que pour tenter de finir le projet.

Mais si le budget demandé est trop important, il n'existe pas des "trucs" pour le diminuer ?
    Oui : en désespoir de cause, on peut se tourner vers la régie forfaitisée, c'est-à-dire réaliser le projet chez le client, ce qui est un des pires scénarios cauchemar qu'on puisse imaginer...
    Toutefois, dans ce cas, les licences des logiciels sont à la charge du client. De plus, vous n'avez pas à louer à votre propre société des locaux et des machines. Ces deux charges financières en moins "aident" beaucoup à ramener le budget dans des proportions raisonnables...
Et puis, il y a son équipe de programmeurs...

Celle que vous recrutez ?
    Ah, le rêve : recruter ses propres programmeurs. Le problème, c'est que vous avez à vous occuper de bien d'autres détails en attendant le début effectif du projet. Souvent, votre direction s'en occupe pour vous... et vous vous retrouvez avec des débutants. D'où un budget en hausse puisque vous prévoyez en catastrophe des formations.

    « On ne reprochera jamais à un chef de projet que son projet connaisse des problèmes. On lui reprochera de ne pas les avoir anticipés ou remontés. »

Un fois cette phase passée, vous démarrez un cycle en V (analyse, conception, codage, test unitaire, livraison) ?
    Non, impossible, l'effet tunnel est bien trop important. Vous n'avez pas assez de visibilité et, lorsque vous vous rendez compte avec le client que ce que vous développez ne répond pas à ses besoins... il est trop tard. Il faut à tout prix faire le point beaucoup plus régulièrement.
    Vous devez partir en cycle Itératif. Il s'agit alors d'un cycle en "vvvv", chaque v représentant une itération, un "mini-cycle" complet (analyse... jusqu'à livraison), et cela permet de monter régulièrement au client un exécutable remplissant n % des fonctionnalités demandées et lui permettant de faire le point.
    Cela vous permet surtout de constater les déviations en terme de délais et d'engager immédiatement des procédures de corrections.

Vous ne faites pas de prototype ?
    Vous êtes fou ! Pas l'temps ! Votre premier exécutable doit être le plus graphique possible : il faut que le client puisse voir quelque chose, c'est vital : plus tôt il voit, plus tôt il gueule. Et plus tôt il gueule, plus tôt vous pouvez anticiper sur ses folles demandes et les négocier au mieux.

Et... les déviations dont vous parlez, quelles sont-elles ? Vous ne les aviez pas prévues ?
    Si, elles sont prévues, surtout si l'on est en régie forfaitisée. Dans ce cas, il faut avoir prévu que l'on est maître de rien, ni de l'arrivée des machines, ni de leur administration (d'où impossibilité d'installer rapidement des logiciels sans passer par les procédures du client et de son ingénieur-système... ah tiens, qui est en vacances cette semaine-là, par exemple...), ni du matériel (bureau, chaise, etc...) qui peuvent ou non convenir à votre équipe.
Et en plus, vous vous heurtez à la hiérarchie interne propre au client, avec ses sombres luttes intestines dont vous n'avez que faire : vous vous adressez à la mauvaise personne, court-circuitez sans le savoir une autre et c'est parti pour d'interminables réunions afin de tirer tout cela au clair...
    De même, on prévient toujours dans son budget de faire intervenir un expert ou un formateur, car cela peut donner le petit coup de pouce au bon moment pour relancer la machine (plus efficace que de recruter de nouvelles personnes).
    Pour le reste, à vous de piloter par anticipation et de gérer la "qualité" de votre projet.

    « Si votre société ne vous donne pas d'ordinateur portable... c'est louche ! »

Piloter un projet implique quelle activité principale ?
    Des réunions... des réunions à n'en plus finir. Et s'il y a bien un truc à connaître pour tirer le meilleur de ces réunions (avec votre hiérarchie ou avec le client), c'est de les préparer à l'avance. Mieux vaut avoir chez soi un ordinateur portable pour y préparer tranquillement quelques slides bien explicites.

Et que veut dire "gérer la qualité" ?
    Beaucoup de règles définissent la qualité d'un projet. Tout un canevas de documents vous permettent de formaliser le déroulement d'un projet, de tracer les choix qui y sont fait afin de mieux gérer la relation "projet - client - société".
Les problèmes arrivent quand on vous impose de coller à tous les aspects de cette "norme qualité".

Mais, je croyais qu'avec les normes actuelles, on pouvait ne pas tout faire à condition de le justifier ?
    Et c'est la justification qui pose problème, justement, car elle implique des réunions... Et des réunions, vous en avez déjà bien assez comme cela. Dans ce type d'ambiance, où le moindre document manquant déclenche une petite inspection et une réunion, vous en arrivez à pratiquer de la qualité défensive ou encore qualité alibi : vous faites les documents qualités non pour ce que cela pourrait vous apporter (une meilleure vision et traçabilité de votre projet), mais juste pour ce que cela pourrait vous éviter... des réunions.
    Vous avez déjà celles avec le client, et elles sont... "spéciales".

    « Quand ça merde vraiment, ne jamais oublier d'aller voir un expert. »

Le client... ne me dites pas qu'il pose des problèmes une fois le projet lancé ?
    Surtout quand le projet est lancé ! Pour un chef de projet junior, qui a entretenu des relations "rapides" et informelles avec son client, tout occupé qu'il est a essayer de faire avancer le projet, il est extrêmement déroutant de voir un beau jour le client *remettre en cause tout* ce qui a été fait (ou du moins une bonne partie).
Sans expérience préalable, il est facile de paniquer.

Et alors, et alors ? keskonfait ???
    Allez voir un vieux briscard, à qui on ne la fait pas ! Vous le verrez prendre du recul sur votre problème. Ce qui l'intéresse, ce n'est pas que le client refuse telle fonctionnalité ou trouve tel écran pas à son goût, mais bien la manière dont ce client refuse tout en bloc : avec ou sans arguments, avec ou sans documents à l'appui. Le plus souvent, et c'est ce qui panique le plus les jeunes chefs de projets (surtout quand ils ne savent pas dire non ou "resserrer les tuyères"), le client refuse avec des arguments peu développés et surtout, sans documents de son côté.

Et le vieux briscard, que dit-il ?
    Facile :
« Tu notes ce que le client veux, tu le lui fais valider. Puis tu lui remets tes notes accompagnés de schémas montrant l'enchaînement des tâches que cela implique, les dates qui y sont associées et les différentes évolutions prévues.
Tu précises bien que tu es d'accord pour prendre les remarques mais tu ajoutes que les conséquences seront :
- allongement des délais ou alors augmentation de l'équipe,
- formation à prévoir,
- retard sur telle fonctionnalité qui doit être codée après telle autre,
etc... etc...»
Et le chef de projet expérimenté d'ajouter :
« La prochaine fois qu'il y a réunion, tu sors ton ordinateur portable et tu notes tout ce que le client dit, au fur et à mesure. Tu verras, l'effet est instantané : le client ralentira son débit et commencera à réfléchir à ce qu'il dit ! De plus, à chaque réunion, tu lui fais signer le CR (compte-rendu) de la réunion précédente. »

En clair, on ressert le formalisme... mais si cela ne suffit pas ?
    Facile (bis) :
« Si le client continue à te faire des misères, tu demandes à ta société de déclencher un audit externe sur ton projet. L'auditeur va demander tous tes documents, que tu auras préparés depuis quelque temps, dans la mesure où tu as considérablement augmenté le formalisme. Puis l'auditeur demandera la même chose au client... qui n'aura pas grand chose à montrer à part un pôv cahier des charges, dont certaines parties sont remises en causes au moment même de l'audit!
La conclusion de l'auditeur devrait inciter le client à trouver un terrain d'entente. »

... Ca c'est du conseil !
    Hé oui, les jeunes chefs de projets ont rarement de tels réflexes. Alors ils se tournent vers des consultants, c'est-à-dire des gens avec une réelle expérience.
Et en plus du client, il faut gérer son équipe.

    « Le mythe du "on va s'refaire" est FAUX. On ne se refait jamais... »

... Gérer son équipe, c'est-à-dire ?
    C'est-à-dire avant tout com-mu-ni-quer et gérer la communication. Même entre 4 ou 5 personnes, il est facile d'avoir, sans même le réaliser, des idées différentes sur la façon de faire une même tâche. D'où l'utilité d'établir en permanence des fiches de tâches pour chaque développeur, des sortes de "mini-contrats" que vous passez entre vous et eux. Si vous vous limitez aux seules communications orales, sachez qu'ils ont vite fait de n'entendre que ce qu'ils veulent bien entendre...
    Communiquer, cela veut dire réunir régulièrement vos développeurs pour des cessions de "brain-storming", avec n minutes pour jeter toutes les idées, n autres minutes pour les classer, les prioritairiser ou en éliminer certaines, avant de prendre des décisions.
    Communiquer, enfin, cela veut aussi dire "jouer le rôle de tampon" entre vos hiérarchies (celle de votre société et celle du client) et vos développeurs afin de les protéger un minimum du stress (donc bien gérer son stress!) et des problèmes de basses politiques.
    Le tout consiste à faire progresser son équipe et à ne pas la mettre en situation d'échec.

D'échec ?
    Le pire pour un programmeur, c'est de se retrouver seul face à un problème et d'y rester bloqué simplement parce qu'il manque d'une vision d'ensemble. En prenant du recul, il verrait que le point bloquant n'est pas si prioritaire que cela, ou qu'il aurait plus de chance de le débloquer en faisant d'abord d'autres fonctionnalités.
Lui donner plus de temps ne sert à rien car la nature humaine est ainsi faite que plus on lui donne du temps pour réaliser un tâche donnée et plus il en prendra, de temps !
S'il reste bloqué en croyant qu'il se rattrapera sur d'autres points plus faciles à réaliser, il a doublement tort :
- l'ordre des points à réaliser relève de votre ressort (et de vos discussions avec le client qui peuvent, on l'a vu, changer bien des choses),
- on ne rattrape jamais son retard !... A moins d'être vraiment très bon, et même dans ce cas....

Donc, mieux vaut avoir une équipe de génies, non ?
    Détrompez-vous. Les très bons sont rarement très bons en tout. Un dieu dans la technique se révélera parfois peu enclin à communiquer ou à bien faire comprendre ce qu'il a en tête. Et si vous comptez sur son code pour vous rattrapez, sachez que les programmeurs qui vous lancent : « pourquoi commenter mon code ? Il est tellement clair qu'il est auto-documenté ! », ça existe. Et neuf fois sur dix, le code est illisible, les noms de variables non-explicites, la modélisation approximative.
En plus, ils peuvent être caractériels ou "intégristes" quant à la manière de réaliser telle ou telle tâche. Et en tant que chef de projet junior, on n'a pas toujours le culot de leur tenir tête, de bien faire le tri entre leurs "bons" conseils et le reste... Ils peuvent même être tenté de vous piquer votre place (sans assumer toutes les autres tâches d'un chef de projet, évidemment).
Le pire, c'est quand il faut aller vite et qu'ils se mettent à bidouiller. Non seulement leur code est non-maintenable, mais en plus ils ne savent pas s'arrêter : constatant qu'ils arrivent à répondre aux besoins dans les temps, ils peuvent se mettre à rajouter des effets "flashis" (comme une bouche qui parle pour annoncer la fin d'une opération, plutôt que le simple "bip" initialement prévu), sans vous dire d'où ils tirent leurs-dits effets...

Aahhh heu... à bas les génies, alors ?
    Evidemment que non. D'abord, ils ne sont pas tous comme ça. Ensuite, j'estime que dans une équipe, il en faut un. En cas de coup de bourre, sur des portions bien localisées du projet, vous le lâchez et il peut vraiment vous sauver la mise.
    Mais à choisir, entre un génie et deux débutants, je préfère deux débutants. En plus, ces derniers sont plus "malléables", plus ouverts à vos idées. S'ils éprouvent vraiment des difficultés sur un point précis, vous faites intervenir un expert pendant une semaine, ce qui les contente doublement dans la mesure où ça les aide à passer le cap et ça les fait progresser techniquement.

    « Une équipe de développeur... quel cirque ! »

Existe-t-il une "équipe idéale" ?
    Non. Au mieux, il faut viser des personnes complémentaires et de niveaux différents. Mais, en tant que chef de projet, vous verrez défiler toutes sortes de personnalités... un vrai cirque.
    Ca ira de l'ancien pompier qui a eu un grave accident au niveau de la colonne vertébrale et qui se plaint amèrement de son siège (alors que vous êtes, comme par hasard, en régie forfaitisée et que le client ne va certainement pas vous donner ses sièges les plus confortables, qu'il s'est gardé pour lui !). Ca passe par l'autiste qui arrive, Walkman vissé sur sa tête, sans dire un mot le matin avant de se "connecter" à son écran. Ca continue par le dilettante qui se pointe vers le coup des 10h avant de repartir vers 16h.

Et vous savez réagir face à ces "individus" ?
    C'est tout le problème d'un chef de projet, surtout débutant. Il ne sait souvent pas quoi dire... Il faut alors penser aux règles de base : « remonter l'information » et demander conseil à sa hiérarchie. En fait, il ne faut pas hésiter à expliquer clairement les "règles du jeu" à vos développeurs : un projet, des délais et de grosses sommes d'argent sont en jeu, sans parler de la réputation de votre société. Au pire (mais vraiment au pire et en supposant que le projet ne soit pas trop avancé), il ne faut pas hésiter à s'en séparer. Une semaine doit suffire pour juger et, le cas échéant, couper les ponts. 3 semaines d'attente ? C'est trop tard. Sur un projet de 4 mois, 3 semaines, c'est énorme. Il faut anticiper ou détecter les problèmes, techniques comme humains, beaucoup plus rapidement.
    Mais quand ça marche, inévitablement des liens se créent. Il ne faut pas oublier, vers la fin du projet, de gérer une dernière chose : le syndrome de la séparation car il est rare de conserver son équipe !

    « Il faut apprendre à prendre des risques. »

Ok... pour finir, c'est quoi, "chef de projet" ?
    C'est savoir mener un projet à son terme, faire progresser son équipe, lui donner les moyens de réussir, satisfaire le client et surtout, savoir tirer des leçons et enseignements de tous les problèmes qui vous seront tombés dessus.
Un échec n'est jamais total si l'on en tire des leçons.
De plus, en prenant des risques tout au long du projet, vous cernez mieux les limites et les pièges de cette fonction. Il ne faut pas rêver, c'est en trébuchant que l'on apprend à marcher.

Et qu'est-ce que cela vous apporte ?
    Si vous avez le bon état d'esprit, c'est vraiment une étape dans votre carrière, qui vous aide à prendre conscience de problèmes plus généraux et qui vous ouvre des portes vers d'autres responsabilités.
    C'est un processus similaire au passage de développeur à chef de projet : c'est parce que vous avez déjà codé et mis la main à la pâte que vous êtes conscient de certains problèmes et que certains aspects de chef de projet vous sembleront facile.
    Dans le même ordre d'idée, pour devenir consultant ou expert, mieux vaut avoir vu d'autres gammes de problèmes et de clients (c'est parfois la même chose ;-) ) avant d'aborder ces fonctions.

.... okokok... en tout cas, ça décoiffe vot' truc, non ?