Discussion :

[luckyvae]

Dans un projet, il y a différents postes.
Le programmeur qui passe la plupart de son temps à écrire du code
Le graphiste qui s'occupe de tout ce qui est création graphique
Le scénariste qui s'occupe du scénario et de la cohérence de l'univers
...
et le chef de projet qui ... ?

Tout le monde connait le poste de chef de projet, beaucoup de monde se propose pour l'être, mais que fait-il vraiment? Rester dans son bureau en train de regarder les autres travailler, avec une bonne tasse de café en main? Je pense pas...

Je ne sais pas de sources sure ce qu'il doit faire, mais, en tout cas voici ce que je pense:

Il doit gérer l'équipe: faire en sorte qu'il y ait une bonne ambiance, détecter les éventuels conflits et aider à les résoudre ou, au minimum, les apaiser. Donc, des compétences en communications sont nécessaires.

Il doit pouvoir dialoguer avec chaque partie de son équipe, et comprendre le jargon de base. Par exemple, pour parler avec le compositeur, savoir de quoi il parle lorsqu'il parle de "mineure" et de "majeure".

Savoir évaluer le travail à fournir pour réaliser telle ou telle tâche, afin de pouvoir répartir le travail de manière équitable ( attention: équitable ne veut pas forcément dire 50-50 ) et pour savoir donner des échéances probables. Donc pour cela, il doit avoir un minimum de compétence dans chaque domaine.

Avoir une vision globale du projet: dans le temps et inter-disciplinaire: savoir ce qui est en train de se faire par les différents membres du projet, et savoir vers où on se dirige.
En parlant de vision dans le temps, le chef de projet doit savoir ce qu'il veut atteindre, avoir une vision assez précise. Mais il doit aussi laisser de la place aux membres de l'équipe pour qu'ils puissent s'épanouir, et que ce projet devienne leur projet. En effet, qui n'a jamais entendu quelqu'un râler pour un travail de groupe "Pffff, c'est moi qui ait du tout faire, les autres n'ont rien fait, ils me regardaient faire". Et lorsque l'on voit le groupe en question, on voit que la personne qui a râlé ne laissait pas la possibilité aux autre de travailler....

Et donc, pour que les membres du groupe puissent s'exprimer, il faut faire des réunions. Et donc, si le chef de projet décide de mener la réunion, il faut qu'il ait les compétences pour mener une réunion, car c'est pas si simple. Et si en plus, le projet se fait à distance, chacun chez soi, cela devient encore plus difficile.

Voilà ce qui me vient en tête pour un chef de projet. Êtes-vous d'accord avec moi? Ai-je oublié des points qui vous semblent nécessaires? Ou alors, y-a-t'il des points qui ne vous semblent pas nécessaires?

Je suis curieux de vos avis / retours d'expériences / pré-jugés.

[Ubiquité]

Chef de projet "amateur" ?
Tu veux dire chef d'équipe quoi.
A mon avis le plus important c'est bien l'expérience.

[luckyvae]

Je ne pense pas que ce soit d'application uniquement dans le cadre de projets amateurs. Mais je dirais plus dans le cadre d'une équipe de moins de 50 personnes.

Et justement, quelles seraient les différences pour le chef de projet entre une petite équipe et une grande équipe / projet amateur et projet professionnel?

[Acropole]

j'ai eu deux jours de cours sur la gestion de projet il y'a deux ans.
Ce qu'il en est ressorti c'est qu'un chef de projet doit faire correspondre les données budget, temps, personnel.
Il y'a des méthodes pour ça qui permettent de faire des diagrames de production.
Si le chef de projet a des données valables (budget, temps / tache, personne / tache, date butoir) il peut proposer une planification des taches pour chaque personne et chaque date, définir combien de personnes il faudra, quels types d'outils, combien ça coutera en électricité/ essence / téléphone etc.. et ceci pour des projet qui peuvent nécessiter plusieurs dizaines, voire centaines de personnes sur des années (barrage des 3 gorges en chine par exemple).

Dans le cadre du jeu vidéo c'est pareil. En fait peu importe le produit, la seule chose qui change c'est la connaissance du domaine (un chef de projet dans le génie civil ne sera pas performant dans le monde du jeu vidéo, et inversement).

Il est en suite chargé de gérrer l'avancée du projet au jour le jour, s'arranger pour éviter les reatards (surtout sur les chemins critiques), s'assurer de la qualité (du travail des salariés, mais aussi du materiel dont ils disposent, de ce que font les fournisseurs etc.. sur tout la chaine de production)

en tous cas c'est ce que j'en ai compris.
Il y'a des formations spécifiques pour ce genre de poste depuis longtemps.

voir la méthode Pert

[luckyvae]

Intéressant cette méthode, je connaissais pas du tout.
Tu en connais d'autres ?

[millie]

Intéressant cette méthode, je connaissais pas du tout.
Tu en connais d'autres ?

Méthode de gantt est également très connu (il y a même des outils pour gérer les diagrammes automatiquement, par exemple ganttproject)

Méthode de pert, ça sert surtout pour calculer le chemin critique

[N_I_C_S]

Si le chef de projet a des données valables (budget, temps / tache, personne / tache, date butoir) il peut proposer une planification des taches pour chaque personne et chaque date, définir combien de personnes il faudra, quels types d'outils, combien ça coutera en électricité/ essence / téléphone etc.. et ceci pour des projet qui peuvent nécessiter plusieurs dizaines, voire centaines de personnes sur des années (barrage des 3 gorges en chine par exemple).

Je voudrais pas faire le rebat-joie, mais un projet informatique est d'une nature très différente des projets BTP ou autres. On bosse sur des productions intellectuelles abstraites qui ne peuvent pas être facilement quantifiées. Qui n'a pas imaginé développer un truc en 1 heure et ça lui a pris 3 jours, ou au contraire s'être fait une montagne d'un algo finalement bouclé en 5 minutes ? Pour les diagrammes de GANTT ou PERT, ce sont des outils très spécifiques de gestion des tâches dans le temps, ils n'ont par exemple aucune capacité à définir les caractéristiques de ces tâches.

Pour être clair : il n'existe aujourd'hui aucune méthode globale de conduite de projet informatique viable (et celui qui en trouve une, c'est le roi du monde). Il y a eu quelques essais : la méthodes des points de fonctions, trop affiliée a merise, ou, plus exotique, la méthode CoCoMo, issue d'observations statistiques des années 70...

Mais encore maintenant, les paramètres de réussite d'un projet informatique sont un mystère, ils sont liés au talent des gens, à l'équipe, etc... et c'est plutôt rassurant en fait.

[LeGreg]

Mais encore maintenant, les paramètres de réussite d'un projet informatique sont un mystère, ils sont liés au talent des gens, à l'équipe, etc... et c'est plutôt rassurant en fait.

Et pourtant pendant ce temps un peu partout dans le monde, régulièrement des gens livrent des logiciels selon un planning prévu à l'avance.

LeGreg

[bafman]

en fait, le terme de chef de projet est typiquement francais... en anglais, on parle de project manager, et non pas project chief. Et si on doit retenir une definition d'un bon manager, c'est celui qui fait tout pour que les autres traivaillent au mieux de leurs capacitées (et non pas celui qui les fait travailler plus comme certains le pensent )

sinon, si tu veut approfondire le sujet, tu peut allez faire un tour chez joel dans la section archive, y'a pas mal de reflexion interessantes à lire sur la gestion de projet informatique et autre (attention, ca reste de reflexion, à ne pas forcement prendre au pied de la lettre )

[N_I_C_S]

Et pourtant pendant ce temps un peu partout dans le monde, régulièrement des gens livrent des logiciels selon un planning prévu à l'avance.

Donc régulièrement d'autres non. C'est pour ça que je dis que c'est pas une science exacte.

[luckyvae]

Merci pour le lien bafman, je vais aller lire dès que j'en aurais le temps

c'est celui qui fait tout pour que les autres traivaillent au mieux de leurs capacitées

et justement, qu'est-ce que tu entends par "fait tout" ?
Parce que je suppose qu'il va quand même pas aller faire le ménage chez les membres de son équipe pour que ceux-ci ne doivent pas y penser quand ils travaillent....

[sinok]

Et pourtant pendant ce temps un peu partout dans le monde, régulièrement des gens livrent des logiciels selon un planning prévu à l'avance.

LeGreg

En général c'est plutôt en retard par rapport à un planning prévu à l'avance.

Et le rôle d'un chef de projet est très souvent également de servir de tampon entre le client et l'équipe de développement

[LeGreg]

En général c'est plutôt en retard par rapport à un planning prévu à l'avance.

Les retards font partie des aléas de la production. (que ce soit dans la construction de ponts, de lancements de fusée, ou de lancement de la version 2.0 de mon logiciel préféré). C'est au planificateur (et généralement chef de projet ou ses subordonnées sur de vastes projets) et non pas à l'ingénieur/contributeur individuel de faire en sorte de limiter ces retards à l'imprévu (pas par manque de planification !) et aussi de les prendre en compte lorsqu'il faut réaligner le projet (pour sortir à la date prévue ou pour sortir avec toutes les features prévues). Il faut aussi se plier à la législation du pays (tenir compte des congés nombreux ou pas), et de limiter le crunch time quand la compensation doit suivre ou le risque de turn-over est fort.

La planification est indispensable quand on a une équipe de centaines voire de milliers d'ingénieurs (oui !) qui ont des salaires plutot importants et qu'on ne peut pas payer à se tourner les pouces. En général les gens travaillent dans un milieu concurrentiel également et donc retard signifie perte de parts de marché potentielle sur la concurrence.

Bref sur la plupart des projets c'est un boulot à temps plein, et qui est parfois réparti sur plusieurs personnes : dans mon entreprise on a une dizaine voire vingtaine de composants logiciels dont il faut coordiner le développement, en général chaque composant établit son propre planning et le superviseur décide s'il faut réallouer plus de personnel en fonction des tâches planifiées, le superviseur du soft lui-même coordonne avec les autres composantes dans la compagnie pour s'assurer que la partie logicielle ne soit pas le "long pole" du planning.

LeGreg

[N_I_C_S]

Les retards font partie des aléas de la production. (que ce soit dans la construction de ponts, de lancements de fusée, ou de lancement de la version 2.0 de mon logiciel préféré).

Non, c'est trés différent. D'autres industries ont effectivement rationnalisées leurs processus de productions depuis longtemps. Un ingénieur en mécanique sait évaluer précisément la charge de travail pour la construction d'une pièce d'usine, ou d'une télé, ou d'un avion. Les retards sont dûs à des évènements extérieurs incontrôlables et ils sont donc beacoup plus rares.

Nous, on tâtonne encore, on a inventé une pléthore de modéles (cycles en cascade, en spirale, en V, XP, etc...) pour s'approcher de la "software factory", graal de la profession, mais aucun n'a répondu totalement au besoin d'encadrement de la production de ton logiciel préféré.

Le secteur informatique doit composer avec ça. En réalité, chaque équipe se dém**de avec son expérience, sa connaissance du secteur ou des structures pour lesquels elle travaille, etc... Et en effet le chef de projet doit constament "réaligner" les tâches selon la tournure des choses (dans le BTP, on ne "réaligne" rien du tout une fois le projet au point).

C'est comme ça : le génie logiciel ne sait pas estimer la charge de travail d'un projet, c'est une spécificité de l'industrie informatique.

[bafman]

et justement, qu'est-ce que tu entends par "fait tout" ?
Parce que je suppose qu'il va quand même pas aller faire le ménage chez les membres de son équipe pour que ceux-ci ne doivent pas y penser quand ils travaillent....

et pourquoi pas ? ce n'est pas forcement le gestionnaire de projet qui doit le faire, mais il peut très bien payer des entreprises de services pour le faire... certaines grosses boites poposent même de faire les courses pour leurs employés pendant le temps de travail.
Plus généralement, si la plus part des boites ne peuvent pas se permettre ce genre de choses (qui coutent quand même cher), c'est au gestionnaire de projet de gerer tous les problèmes d "intendance" du projet (changer une machine trop vielle, fournir des cahiers crayons et autre aux employés...) en gros, tous les petits soucis bêtes de la vie quotidienne ne doivent surtout pas être à la charge de l'employé. Si un employé a une souris déféctueuse et qu'il doit attendre une semaine qu'elle soit changée car il n'y en a plus en stock, c'est que le gestionnaire du projet a mal géré ce point la...

tout ca, c'est pour la partie intendance, qui est souvent prise en charge par le gestionnaire du projet dans les petites boites et par d'autres personnes dans les grosses boites mais restent intimement lié à la bonne gestion d'un projet et d'une entreprise en général (imaginez les effets desastreux d'une penurie de papier dans les toilettes... c'est tout bête, ca n'a rien à voire avec le projet, mais c'est génant ).
Pour la partie developpement logiciel, le role du gestionnaire est de bien prévoir que à si X doit commencer à developper tel composant logiciel à telle date, tous les composants sur lequel il doit reposé soient bien terminés et testés.
Contrairement à ce qu'on pense souvent, (et qui est trop souvent appliqué dans les entreprises) ce n'est pas au gestionnaire de projet de déterminer la durée d'un tache... C'est à la personne qui réalise cette tache de le faire. c'est la seule personne à même d'évaluer le temps effectif de travail. C'est déjà un exercice difficile à faire pour soit même, alors le faire pour les autres . Ensuite, le role du gestionnaire de projet, c'est de recuperer toutes ces taches, les contraintes qui pesent dessus, et d'en faire un planning (en y incluant des marges de manouvre, des eventuels retard sur les taches plus hasardeuses, les congés et autres).

Un gros probleme en developpement logiciel, c'est que souvent, les gens disent : on veut un logiciel qui fait ca ca et ca pour tel date. Il ne se rendent pas compte qu'ils fixent l'ensembles des variables sans laisser de degrés de liberté, et donc il y a forcement un endroit ou ca va coincer (logiciel à l'heure mais qui n'a pas toutes les features, ou alors ultra buggé, ou alors en retard...)
dans le jeu video, c'est la même chose, souvent, l'editeur demande le jeu pour tel date, et c'est à l'équipe de se debrouiller. parfois, il donnent plus de credit pour embaucher quand il voient que le jeu va être en retard, mais ca ne resoud pas le problème, car il faut former les personnes, ce qui, dans un premier temps fait perdre plus de temps qu'autre chose... C'est en partie pour ca que souvent, les jeux sont retardé (ou buggé, voir même les deux). Il n'y a que très peut de boites de jeu vidéo qui peuvent se permetttre le fameux "when it's done". mais la, je vais m'arreter car je commence à serieusement deriver du sujet d'origine

[Invité]

+1

J'ajouterais justement que c'est la capacité d'un chef de projet de prévoir les retard possible afin de plannifier correctement son projet.

Ca ne s'apprend pas en un jour et c'est d'autant plus valable sur des projets informatique.

Donc on peut utiliser des méthodes de plannif sans pb, après c'est uniquement le chef de projet qui va faire qu'un projet est bouclable dans les délais impartis ou non et c'est à lui de négocier au client en lui disant ca c'est faisable et ca ca ne l'est pas.

[SlashEne]

c'est peut être un peu tard mais je pense que le bon chef de projet
informatique connait un minimum la littérature de choix sur ce sujet (projet informatique) :
-Peopleware
-Mythical Man Month
Je ne les ai pas lu personnellement mais ils ont fait fureur aux US et les meilleurs développeurs aux US en parle et en reparle.
Je rajouterai un livre de Craig Larman nommé UML2 et Design pattern
Le titre est trompeur, en réalité c'est un livre sur les méthode agile de gestion de projet informatique (Unified Process )
Je l'ai lu, et faudra que je le relise car il est un peu compliqué pour moi, mais passionnant.

Bien sur je pense aussi que l'expérience est la meilleur des choses.

Je n'ai pas d'éxperience personnelle la dessus vu que je suis toujours à l'école :p mais j'ai deja cherché sur ce sujet et ce sont les réponses que j'en ai eu.

[Mat.M]

Tout le monde connait le poste de chef de projet, beaucoup de monde se propose pour l'être, mais que fait-il vraiment? Rester dans son bureau en train de regarder les autres travailler, avec une bonne tasse de café en main? Je pense pas...
.

Est-ce que tu as une démo fonctionnelle , des screenshots, un lien internet avant de parler de chef de projet ?

Tu me sembles être à coté du sujet je m'excuse d'être arrogant;
les philosophies et méthodes qui sont décrites ici c'est valable pour un projet dans une SSII pour le projet de gestion d'un client final gérer des contrats des ventes des taxes des montants HT etc..

Dans un jeu vidéo y'a un peu de ça mais ce qui compte c'est la direction artistique.

Si tu ne fais pas un bon jeu qui plaise tu perds ton temps cher luckyvae un jeu vidéo c'est un boulot trop titanesque pour que cela puisse vraiment déchainer les passions..
Imagine que tu bosses sur un FPS , un RTS ou un super RPG avec une équipe tu fais des beaux diagrammes de gestion de projet tu as recours à des belles méthodes tu veux vendre ton jeu et.... il se vend à 50 exemplaires.
Comment prendrais tu cela ?
Et ça reste valable même pour un projet Open Source car quel intérêt de faire un projet si cela attire 10 personnes sur terre ?

Donc on peut utiliser des méthodes de plannif sans pb, après c'est uniquement le chef de projet qui va faire qu'un projet est bouclable dans les délais impartis ou non et c'est à lui de négocier au client en lui disant ca c'est faisable et ca ca ne l'est pas.

Allons !
Pour un studio de développement qui doit boucler un jeu pour un éditeur c'est une nécessité mais pas pour un jeu amateur..
A quelques exceptions près y'a peu de projets conséquents sur ce forum alors vous perdez votre temps à faire des planfications..

[luckyvae]

Est-ce que tu as une démo fonctionnelle , des screenshots, un lien internet avant de parler de chef de projet ?

Non, pas de démo, screenshots, lien... ni même projet

J'avais créé ce post pour justement, avant qu'éventuellement je me lance (ou quelqu'un d'autre) dans ce poste, il sache de quoi il en retourne.

les philosophies et méthodes qui sont décrites ici c'est valable pour un projet dans une SSII pour le projet de gestion d'un client final gérer des contrats des ventes des taxes des montants HT etc..

Nous sommes bien d'accord.
Et donc, ce qu'il manque pour l'instant dans ce sujet, c'est de la précision quant au rôle de chef de projet d'un jeu vidéo. Comment susciter la créativité, ...

[Mat.M]

Et donc, ce qu'il manque pour l'instant dans ce sujet, c'est de la précision quant au rôle de chef de projet d'un jeu vidéo. Comment susciter la créativité, ...

Mais je dirais que tant que tu n'as pas d'idée de base et un objectif à tenir c'est difficile de dire quel role un gestionnaire de projet peut avoir..
C'est comme pour faire une analogie un architecte qui doit dessiner et assurer la maitrise d'ouvrage d'une maison; si tu ne sais pas quel type de maison et quel type de projet tu dois faire réaliser l'architecte tourne en rond..
Admettons que ton projet ce serait un jeu genre World of Warcraft;
bon eh bien toi ton role ce serait de dire aux graphistes de faire des graphismes attrayant avec des orcs des monstres des persos au look médieval de dessiner des fermes etc..
Les programmeurs eux feraient le moteur de jeu , les scripts d'IA et donner un comportement une IA aux persos joueurs et persos non joueurs.
Toi tu dois orchestrer tout cela pour qu'au final cela donne un projet attrayant même s'il doit être destiné au libre ( sourceforge)
Tu dois déterminer ce qui peut donner un plus pour le gameplay la représentation graphique..
Tu peux t'inspirer de gamekult.com par exemple et les critères avec lesquels on juge un jeu..
en général ce sont toujours les même , le gameplay, l'intérêt général du jeu les graphismes et sons.

Comment susciter la créativité, ...

Pour avoir de la créativité il faut être très ouvert et observer, avoir un regard sur le monde qui t'entoure..
Le moyen le plus simple c'est de s'inspirer largement sur ce qui se fait déjà les jeux libres ( comme sur sourceforge que j'ai cité) les jeux commerciaux , les jeux on-line comme Dofus par exemple..avoir des idées..

Si tu prends les grands éditeurs de jeu vidéo on recrute des profils littéraires pour les postes ou il faut faire élaborer une ligne artistique et scénaristique..