Gestion de projet 101 : Ces documents qu’on aime.
La gestion de projet, qu’on aime tant, passe par un certain formalisme. Non sans mal, je me suis fait ma propre vision des documents les plus importants, les plus habituels, qu’on peut retrouver au sein d’une équipe. Avant que je ne vous donne une liste qui, j’en suis sûr, aidera certains, petite précision : aucun document n’est vital. Tous sont utiles, suivant votre situation, votre jeu, vos soucis, et vos besoins. Soyez souple, soyez agile.
Autre chose importante : n’hésitez pas à garder une game design doc à jour. Votre bible doit être la plus complête, la plus claire et la plus à jour possible. Si ce n’est pas de votre responsabilité (lead game designer, mon ami) c’est votre devoir de vérifier qu’il fait bien son boulot. Une game doc en retard ou mauvaise est une plaie dont peu de projets se relèvent aisément. Forcez le à faire des versions, datées, de sa game doc, avec un vrai suivi.
Addendum : Une game doc intelligente n’est pas forcément un gros document word immense et imbuvable. Un peu d’organisation sur le sujet peut vous faire gagner énormément de temps.
C’est où qu’on va ? Les objectifs.
1) Planning. J’ai déjà dit tout le bien que je pense de MS Project. Avoir un enchainement propre et lisible des tâches sous MS Project est très utile.
Format : MS Project / Public : Vous.
2) Project review. Ce que j’appelle un project review, c’est une page présentant :
- Le résumé rapide du projet en 3 lignes
- Les Unique Selling Points
- Les milestones.
Bref c’est le document de base que vous, développeurs, devriez tous avoir avant de vous lancer dans un projet. L’idée, les points clefs, les dates clefs. Donnez le à chaque nouvel arrivant sur le projet. Vous pouvez mettre dans cette micro review plus d’infos, mais essayez d’avoir un brief en une page qui présente les infos les plus cruciales.
Format : Word ou équivalent / Public : Equipe
3) Feature & Asset Planning (2 documents proches dans la forme)
Il est important pour l’équipe comme pour vous, de savoir ce qui est attendu à chaque milestone. On essaye donc d’avoir pour chaque élément du jeu, et chaque asset, la milestone à laquelle il est attendu. C’est généralement un document qui présente, en colonne, les différentes features, les différents assets (de façon ordonnée, genre par catégorie) et en ligne, les milestones. On utilise ensuite un code couleur pour déterminer quel asset est attendu à quelle version.
En effet on peut définir quelle version est attendue (not done, placeholder, early version, finished version, polished version… Les termes doivent rester peu nombreux et tranchés, afin d’être clairs pour tout le monde).
Il s’agit de quelque chose de négocié au lancement de la production, mais c’est sur ces points que votre boîte s’est engagé. Gardez donc ce document à jour dans ce sens : les dates sur lesquelles votre équipe est engagée à produire tel ou tel élement.
Format : Excel ou équivalent / Public : Editeur, Vous, Direction, Equipe
3) Key Success Factors
Il est important pour vous de savoir quels sont les critères clef de qualité voulus par la direction. Ce qu’on appèle les facteurs clefs de succès. Ca peut être un visuel (« ça doit être pour enfant »), des objectifs chiffrés (« 10 personnages jouables ») etc… L’important est de savoir quels sont ces critères important pour la direction et l’éditeur, et comment vous allez pouvoir les évaluer ou les faire valider.
Format : Excel ou équivalent / Public : Vous, Direction, Editeur
Comment on y va ? Gérer la vitesse et les aléas
4) Feature & Assets tracking (2 documents proches dans la forme)
C’est un peu vos document navette sur l’état des features / assets. Chaque feature (ou asset) va être listée en colonne (organisée) et chaque milestone placée en ligne. Le but est d’avoir pour chaque milestone l’état prévu et l’état délivré à la version de milestone par votre équipe, ainsi que les commentaires.
On peut dire « ça ressemble au feature/asset planning ». Et c’est vrai. Néanmoins le but n’est pas le même. Le Feature Planning va lister vos engagements contractuels (et donc si commentaire il y a, c’est la copie du mail qui change l’état attendu d’une feature). Le Feature Tracking va lister la comparaison entre engagement / réalité. Voir si votre équipe est capable d’aller assez vite pour faire ce qui est attendu ou pas. Et expliquer là où vous avez été plus vite (tant mieux) ou plus lentement.
On ne va pas renvoyer le Feature Planning (les engagements) à chaque milestone. L’éditeur est sensé les connaitre. En revanche on va renvoyer le tracking, le suivi de l’état réel à chaque milestone.
Format : Excel ou équivalent / Public : Editeur, Vous, Direction
5) Risk tracking
Ce document est assez simple. En fait, comme je l’ai déjà expliqué dans d’autres articles, il faut suivre les risques, pas vrai ? L’idée est d’avoir là une liste des risques, avec à chaque fois leur criticité, leur risque d’occurence, les actions préventives prévues / entreprises, les actions correctrices prévues / entreprises. L’idée est de pouvoir filer un résumé clair à la direction (et en avoir un pour vous). Théoriquement vous ne devriez avoir qu’une version de ce document (ce que doit savoir la direction, c’est ce que vous savez).
Si vous êtes obligé de cacher des risques, c’est qu’il y a un vrai problème.
Format : Excel ou équivalent / Public : Vous, Direction
Avec qui ? Gérer la communication interne
6) Fiches de poste ou de mission.
Beaucoup me diront « c’est le rôle des Ressources Humaines les fiches de poste ». J’ai tendance à dire que non. Chaque personne a un role et des tâches attitrées dans l’équipe, en fonction du projet . Valorisez l’équipe en reconnaissant à chacun son rôle, ses tâches, sa fonction. En faisant ça tôt, vous éviterez des soucis d’égo. Qui doit définir tel élement ? Le lead prog ou le lead GD ? Et qui choisit telle partie ? … Bref, chacun a un role et des choix a assumer. Répartissez les rôles. Si les rôles changent, changez les fiches de poste.
Attention ! Il existe parfois dans vos boites des fiches de poste qui sont plus générales, non liées à un projet, et bien ficelées. N’allez pas marcher sur le pré carré des RH pour ça. Faites donc une fiche de mission. Une sorte d’addendum de la fiche de poste qui intègrera les élements importants pour ce projet.
Format : Word ou équivalent / Public : Personnes ayant le poste listé
6) Fiches de communication
Certaines choses (notamment dans les grandes équipes) nécessitent de la communication écrite, parce que socialement (heures supplémentaires, congés) ou stratégiquement (risques, décisions clefs) critiques.
Demandez à ce que pour ces choses clefs, votre équipe passe par un formulaire écrit, que vous pourrez garder. Et répondez aussi par écrit. Vous y gagnerez en sérieux et limiterez les risques de double language. Je pense aux congés, parce que si vous promettez un congé par écrit, avec l’aval de la direction, la direction aura plus de mal à vous faire revenir dessus. (J’ai déjà entendu et vu le cas, d’où cette remarque).
Je pense aussi aux risques parce que certains risques ne remonteront pas par oral lors d’éventuelles réunions. Pour les timides, avoir une feuille où ils expliquent le risque (et qui court-cuite le lead) peut parfois être salutaire.
Un chef de projet assez malin que je connait utilisait une sorte de petite boite aux lettres, dont il avait annoncé qu’il lirait son courrier écrit régulièrement, et que ça resterai anonyme. Ca lui permis de déminer et débusquer pas mal de lièvres, dans une entreprise au contexte social très chargé.
Avec la confiance de l’équipe, ça marche.
Format : Word ou équivalent / Public : Equipe
7) Feature resume
Avoir un résumé en une page des features. C’est pas forcément vous qui l’écrirez ( un game designer doit bien bosser de temps à autres) mais cela servira à ce que chacun comprenne le rôle et la criticité de chaque feature. Utile pour les nouveaux arrivants
Format : Word ou équivalent / Public : Equipe
Un pack « bitos du donjon »
Oui, le terme n’est pas reluisant mais marrant, il me vient du Donjon de Naheulbeuk. L’idée est d’avoir un petit guide (le plus court possible) pour les nouveaux. Il doit présenter:
- Le project review fait plus haut
- La hiérarchie de l’équipe, ses usages
- Les trucs à installer pour pouvoir bosser (par rôle).
Format : Word ou équivalent / Public : Equipe
9) Résumé des réunions
Gardez toujours une trace des décisions prises, pour qu’on ne revienne pas dessus involontairement (ou pire, volontairement) sans raison et communication.
Format : Word ou équivalent / Public : Equipe, Direction
Avec qui ? Gérer la communication externe
10) Retours de version
A chaque milestone, vous allez avoir les retours de l’éditeur. Du bien, du moins bien… Sachez lister l’ensemble de ces retour, les trier, et les résumer, les organiser.
Le but est :
- Répondre à l’éditeur
- Pouvoir voir avec la direction si des changements d’équipe s’imposent
- Lister les corrections à apporter pour l’équipe
N’hésitez jamais à envoyer ce document à l’éditeur, si par bonheur il adopte votre formalisme pour ces retours, vous y gagnerez.
Format : Word ou Excel ou équivalent / Public : Editeur, Direction, Vous
11) Version notes
A chaque milestone, vous allez donner à l’éditeur votre Feature Planning, votre Asset Planning. N’hésitez pas à mettre aussi un autre document, une version notes, qui intègre ce qu’on peut faire dans la version, ce qu’il y a de nouveau, les critiques que vous pouvez déjà anticiper, ce qui n’y est pas… Bref n’hésitez pas à envoyer un document global de suivi.
Format : Word ou équivalent / Public : Editeur
Articles connexes
- Game design 101 : Achievements
- Game Design 101 : Ces trucs trop utilisés en matière de narration
- Management 101 : Un planning pour les gouverner tous
- Ergonomics 101: Quelques clefs
- Production 101: BlitzDev, ou Développement éclair
- Management 101 : Jouez au Risk
- Game Design 101 : Understanding Games, comprendre le jeu par le jeu.
- Game Design 101 : Fun ex Machinam
- Game design 101 : Devenir game designer ?
- SCRUM ? SCRUM ! SCRUM...
Merci pour ce petit post bien utile ! Je vais essayer de mettre en place le Project Review, ça peut bien aider je pense.
[...] Ce billet était mentionné sur Twitter par Caroline. Caroline a dit: Un super article pour mes amis les chefs de projet… http://bit.ly/cfASuY [...]