Project Management 101: Back to basics
Ce petit article est là pour donner quelques notions de base en management. Les pros du sujet n’y trouveront certainement pas leur compte, mais ceux qui n’y connaissent rien, et aimeraient se documenter (futurs chefs de projet ou futurs collaborateurs de chefs de projets par exemple, vont y trouver quelques explications).
Un projet c’est quoi ? Quelques termes…
Il s’agit généralement du développement d’une mission (dans notre cas, un jeu). On dispose pour cela de ressources : une enveloppe de temps, un budget financier, une équipe. On dispose également d’objectifs (« le jeu doit être comme ça, avec cette fonction là, plaire à tel type de gens »).
Généralement, un projet de plus de 3 personne a besoin d’un chef de projet. Ça va être la personne qui va s’assurer qu’on arrive bien de l’idée au produit réalisé, en utilisant intelligemment les ressources.
Dans le jeu vidéo, on fait des choses dans un temps donné (on dit « on time ») avec une qualité donnée (« on quality »), et un budget donné (« on budget »). La logique « On Time, On Quality, On Budget » va donc marquer l’ensemble du projet.
Comment peut agir le chef de projet ?
Le rôle du chef de projet est essentiellement d’organiser et décider. En jonglant avec la qualité, le temps et le budget. On Time, On Quality, On Budget.
Souvent, toute décision se résume par un impact sur le coût, la qualité ou le temps. Il lui faudra donc décider s’il faut ou non faire telle feature du jeu, si tel mode de jeu est plus important à réaliser que tel autre, s’il faut arrêter ou poursuivre une recherche technique couteuse sur tel sujet, ou utiliser une solution subalterne.
Son but va être d’utiliser au mieux les ressources du projet, la qualité et le temps, dans le but de réussir la mission avec la qualité donnée.Sans mordre sur le temps.
Il devra donc prendre la bonne décision, ou la moins pire. Il devra organiser la chaîne de production (l’ordre dans lequel on fait les tâches, et qui les fait).
Si on ne doit retenir qu’une chose On Time, On Quality, On Budget.
Et évidemment il devra organiser les choses pour que toutes les décisions soient suivies d’effet, que la mécanique tourne bien.
Connaissez votre projet !
Avant de vous lancer dans un projet, vous devriez absolument savoir toutes ces informations :
- Les dates importantes (ou milestones)
- Le budget financier
- L’équipe allouée
- Les contraintes imposées
- Les objectifs
- La qualité attendue sur les objectifs
- Les risques connus de la direction ou de l’éditeur
- Les features et fonctions à réaliser
- Le public du jeu à atteindre
Aucun chef de projet n’est devin. Aucun chef de projet ne devrait se lancer à l’aveuglette. Piloter (car on parle de pilotage de projet) nécessite d’être au courant du contexte de projet. Ne pas le connaître, c’est se pousser à la faute.
Un chef de projet est un pilote
Le chef de projet est là pour faire aller son équipe dans la bonne direction. Il dispose d’un temps de parcours, d’un budget (son carburant), d’une destination, et de limitations de vitesses (là c’est la métaphore de la qualité, si vous suivez un peu).
Mais surtout il doit anticiper les risques, les trous qui vont ponctuer le voyage, la route.
Anticiper un risque, c’est réduire la chance qu’il advienne. C’est minimiser ses effets sur le projet. Il faut donc lister les risques, savoir la probabilité qu’ils apparaissent, comprendre leur criticité. Et le mieux quand un risque est connu c’est de savoir comment l’éviter, et comment le minimiser s’il arrive.
Bref connaitre les risques c’est garder un oeil sur la route.
Il existe des tas de méthode de prévention des risques, en voici une par exemple : http://fr.wikipedia.org/wiki/Analyse_des_dangers_et_Points_critiques_pour_leur_ma%C3%AEtrise
Vous êtes maître du compteur de vitesse.
Gardez un oeil sur le compteur aussi, savoir à quelle vitesse travaille votre équipe, si elle est en pleine forme, surrégime, fatiguée, sur la réserve.La motivation est comparable à un élastique. Trop tendu il explose. Pas assez, il est mou, interne.
Faites travailler votre équipe en sous régime et elle va se démoraliser, se démoraliser. Faites la travailler en surégime et ça va exploser.
Connaissez et gérez donc la motivation individuelle (de chaque membre) et collective. Faites en sorte de regonfler les voiles de l’équipe à votre mesure.
Comment être un bon chef de projet ?
Règle numéro 1 : Le travail se compresse mal.
C’est l’erreur la plus fréquente, et la plus grave pour un chef de projet.
Ce n’est pas parce que vous avez décidé que l’objectif X devra être fait en 3 jours (alors que tout le monde le décrit faisable en 8 jours) , que ça sera fait.
Réduire le temps, ça a forcément un impact sur les coûts (faut embaucher, acheter du matériel, une licence) ou la qualité (faut sabrer). Penser qu’on peut diminuer le temps d’une tâche bien estimée, sans toucher au reste, est au mieux risqué, voire carrément naïf.
( Evidemment cela suppose que l’évaluation première du temps soit bonne et non gonflée ).
Règle numéro 2 : Le travail se compresse décidément mal.
On ne peut pas empiler les développeurs. Ce ne sont pas des poules pondeuses. Ce n »est pas parce qu’une tâche est faisable en 10 jours par 1 homme, qu’elle est faisable en 1 jour par 10 hommes.
Corrolaire : Tout adjonction d’hommes dans l’équipe de projet apporte un surplus de méta-projet (encadrement, formation, soutien). Si une tache met X jours pour 1 développer, elle mettra peut être X/3 pour 4 développeurs. Le gain est réel, mais souvent moindre que la simple addition. Parce qu’il y a des surplus d’organisation et de formation à faire.
Réservez une partie de votre temps à ce méta-projet, et forcez vos encadrants à faire de même. Un lead (par exemple, un lead programmeur) devrait passer au moins 1/5eme de son temps hors du code, à remplir son rôle de lead.
Règle numéro 3 : 1 pour 7 ! Dans l’armée américaine, depuis sa fondation, on estime qu’un homme qui veut encadrer efficacement ne peut avoir que 7 subalternes. Si vous avez plus de 7 personnes sous vos ordres (ou 7 projets, ou 7 groupes) faites des équipes, des sous-groupes, nommez des délégations, organisez vous, mais revenez à 1 pour 7. Votre mémoire vous jouera moins de tour.
Corrolaire : Plus d’hommmes, encore une fois, c’est plus d’encadrants.
Règle numéro 4 : Refaire n’est pas forcément mal
Telle fonction est vraiment mauvaise? Il vaut mieux souvent la refaire ou la désactiver, que de la trainer jusqu’au bout comme un boulet. Regardez l’ensemble des conséquences sur le projet d’une décision. Si vous refaites maintenant, n’économisez vous pas du temps plus tard ?
L’esprit humain a une tendance naturelle irrationnelle à conserver l’existant. Sachez quand refaire, et sachez que vos collaborateurs n’apprécieront que rarement de refaire.
Règle numéro 5 : Soyez économes. Pensez développement durable.
Ne réinventez pas la roue, ne développez pas des fonctions ou features par pur plaisir. Est ce que ça va servir le gameplay? Est ce que le joueur va le voir? Si ca n’est pas visible ou pas intéressant, pourquoi est ce encore dans le pipeline ?
La perfection ce n’est pas quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à enlever.
Règle numéro 5 : La délégation c’est bien.
On a la chance d’avoir un milieu ou les gens sont éduqués. Dans une équipe de plus de 7 personnes, il existe forcément une ou deux personnes qui peuvent recevoir une partie de vos responsabilités sans trembler. Qu’ils soient Lead ou qu’ils en aient la carrure, sans le titre, prennez le temps de bien choisir et déléguez.
Bien choisir est important, donner du pouvoir à la mauvaise personne, c’est évidemment se causer bien des soucis inutiles.
Règle numéro 6: Anticipez les risques
Vous savez que machin est souvent malade? Que truc est pas là en mars? Que le chef YZ va vous saquer? Anticipez. Si vous savez à quoi vous attendre, et faites en sorte d’en minimiser les risques, vous aurez une vie plus tranquille (et moins d’ulcères).
Règle numéro 7: Chaque acteur a son langage
Chaque personne a sa façon de comprendre et d’expliquer les choses. Vous êtes celui qui doit s’adapter. Un graphiste ne comprend pas les mêmes choses qu’un éditeur, qui lui même parle différement d’un programmeur ou d’un PDG. Essayez d’intégrer sur quoi se base la personne pour parler, ce qu’on appèle les élements de langage.
Et ainsi vous saurez comment lui expliquer votre point de vue au mieux, sans perte d’information.
Règle numéro 8: Vous jouez dans le même camp que votre équipe.
J’ai vu quelques chefs de projets dénigrer ou briser leur équipe. D’autres considérer l’information comme une arme qu’ils devaient utiliser dans une guerre contre l’équipe ou la direction…
Si ça peut être utile pour des cas très précis, ces comportement sont souvent un manque de confiance du chef de projet, voire pire, un manque de talent.
Vous voulez êtes respecté dans votre équipe ? Vous devez jouer dans le même camp qu’elle, et non contre elle. Les gens se battent pour les chefs qu’ils respectent, mais lâchent les chefs lâches, stupides, prétentieux ou arrogants à la moindre occasion. C’est humain.
Vous devriez être le bouclier de votre équipe. Protegez la. Les soucis extérieur, c’est votre affaire, pas la leur. Faites en sorte qu’ils puissent se concentrer sur leur part du projet. Ménagez les, soyez comme un papa poule pour eux. Plus l’équipe est tendue ou fatiguée, plus elle est attentive à des petites attentions (le café, les croissants…).
Vous devriez être l’agenda de votre équipe. Faites en sorte qu’ils connaissent et comprennent les objectifs, faites leur partager un minimum votre boulot, qu’ils comprennent que votre objectif c’est pas de les torturer, mais de réussir ensemble projet. Bref, traitez les en adultes.
Ne les trahissez pas. Nous avons tous nos objectifs de carrière, certes, mais de ma propre expérience, l’honnêteté marche toujours mieux, tant pour se faire un plan de carrière que pour réussir un projet. Votre subalterne d’hier peut être votre chef demain, dans la prochaine boîte. Le chef honnête sait quoi partager. Le succès est dû à l’équipe, l’échec au chef de projet.
Soyez juste : parole donnée, on ne revient pas dessus. Bonne action, récompense (même petite). Mauvaise action, punition (même petite).
Vous êtes un relai de transmission. L’information doit circuler, du haut (éditeur et PDG) vers l’équipe, et réciproquement. Faites le tri, résumez, clarifiez mais ne gardez pas les choses pour vous (quoi que concernant l’éditeur, ayez une stratégie).
Une fois ces données encadrées, vous pouvez vous « interfacer » avec la direction et l’éditeur. Mais n’oubliez pas que votre coeur doit rester à l’équipe. C’est avec eux que vous bossez tous les jours. C’est à eux que vous devrez la réussite du jeu.
Règle numéro 9: Le juste niveau d’organisation.
Trop peu d’organisation, c’est l’anarchie. Personne n’aime l’anarchie.
Trop d’organisation, c’est du temps perdu. Personne n’aime perdre du temps.
Sachez où poser le curseur. Seul l’expérience vous permettra de savoir ce que vous devez faire ou pouvez laisser tomber.
Règle numéro 10: Rigoureux !
Si vous devez faire des réunions régulières, faites les. Si vous avez un rapport à faire à intervalles régulières, faites le. Un rythme régulier est sécurisant.
Corrolaire : l’image c’est important. En plus d’être méthodique, il faut le montrer, donner l’image d’une personne cadrée, qui sait où elle va, comment elle y va. Soyez sûr de vous quand il le faut. C’est rassurant pour le PDG, l’équipe et l’éditeur, quelqu’un de décidé. Il y a le faire et le faire savoir. L’un est inutile sans l’autre.
Stratégie, Tactique, Micro-management
Vous agissez à trois niveau, ne l’oubliez pas:
Le micro, le quotidien.
La tactique, la bataille actuelle (la milestone, la prochaine grande étape du projet).
La stratégie, l’ensemble de la guerre (le projet dans son ensemble).
Ayez des objectifs stratégiques, des objectifs tactiques, et des objectifs micro. Vos objectifs micro (sur 1 à 2 jours) doivent avoir pour but de réussir vos objectifs tactiques. Et vos objectifs tactiques s’inscrivent dans une stratégie. Soyez capable de descendre dans le détail du code si besoin et de remonter ensuite vers un niveau global pour surveiller l’ensemble.
Un très bon chef de projet que je connais appelle ça faire l’hélicoptère. On monte, on descend régulièrement.
Vous n’êtes plus vraiment un développeur
Même si vous adorez programmer, faire du game design ou être artiste, n’oubliez pas une chose: vous êtes un chef de projet. Vous dirigez une équipe pluridisciplinaire. Vous avez forcément un ou des corps de métier que vous comprenez mieux que les autres. Si vous connaissez mal un corps de métier, faites en sorte de trouver vos marques et vos curseurs.
Et ne passez pas tout votre temps dans le code / le game design / l’art. Vous risqueriez de négliger le reste.
L’alchimie d’un jeu est complexe. Un bon game design, un code sans bug, un style graphique inspiré et un game design clair et novateur, c’est génial, mais ça ne doit pas vous empêcher de savoir ce qui se passe à coté. Ayez des yeux et des oreilles sur chaque spécialité.
Le mot de la fin.
L’expérience.
Apprendre de ses échecs, capitaliser ses succès. C’est la principale voie pour devenir un bon chef de projet. Bon courage
Articles connexes
- Game Design 101 : Fun ex Machinam
- Game Design 101 : Understanding Games, comprendre le jeu par le jeu.
- Production 101: BlitzDev, ou Développement éclair
- Game Design 101 : Boucle & Flux
- Ergonomics 101: Quelques clefs
- Management 101 : Un planning pour les gouverner tous
- Management 101 : Jouez au Risk
- Game Design 301 : Ce que nous devons au pen & paper...
- Game design 101 : Achievements
- Distraction Massive ?
« Bon courage »
Thanks! ^^ »