Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

14/09/2009

Granularité

Ce n’est pas tant une note qu’une petite remarque au sujet d’un mot qui a sans doute été un peu abusé.

 

 

Quand on essaye de gérer un planning, ou d’établir un plan de prods, on se pose souvent la question de la granularité, c'est-à-dire du niveau de détail auquel on va essayer de suivre les travaux.

 

 

C’est peut être une évidence, mais les manageurs et les « producteurs » (au sein de ceux qui font les choses, artistes designers et programmeurs) ne pensent pas la question de la même façon.

 

 

Un manager pense en terme de temps: Quand il pense à la granularité, il se demande comment décompter le temps de travail : heure, journée, demi-journée ou semaine.

 

 

Un « artiste », lui, pense en terme d’assets : ce qu’il a à produire, et dans quel ordre.

 

 

S'en suis souvent une discutions de sourd, où le manager va souhaiter imposer une granularité donnée (disons la demi-journée), forçant par la même l’artiste à découper sa tache en « sous taches » plus ou moins correctement définies pour coller à cette granularité.

 

 

A l’inverse, certains artistes soutiennent mordicus une approche « tour d’ivoire », demandant au manager de le laisser travailler en paix pendant des jours entiers (voir des semaines), laissant ce dernier libre de se ronger les ongles.

 

 

Evidemment, c’est un faux débat : ces deux granularités sont en pratique orthogonale l’une de l’autre. Comme elles ne sont pas homogènes, la plupart des outils (à commencer par MS Project) échoue à capturer efficacement ces dimensions.

 

 

A garder à l’esprit donc avant de laisser un « grain » de sable enrayée la machine (bon ok, je sors…)…

13:49 Publié dans Business | Lien permanent | Commentaires (6)

Commentaires

Et donc, la solution, dans ce cas la ? Quand on est pas soit-meme manager, s'entend ?

Écrit par : MMoi | 14/09/2009

Changer de façon de penser ? Ou ne plus établir de planning sur une ligne horizontal, mais essayer de penser sur un "plan" à deux axes (assets/features sur l'axe Y et le temps sur l'axe X) pour établir une carte de progression ?

Je n'ai pas encore vraiment expliciter de solutions, je suis juste en train d'y réfléchir (et il faut IMPERATIVEMENT que je reprenne des cours d'orthographe moi) ^_^

Écrit par : Daz | 14/09/2009

Je pense que le problème ne se pose pas en ces termes.

Je pense que l'ensemble des acteurs du jeu vidéo qui ont déjà un jeu derrière eux savent qu'il y a un côté imprévisible dans la création d'un jeu et qu'il est utopique de vouloir micro manager ça à coup de MS Project.

A la base c'est en partant de ce constat qu'on a inventé les méthodologies agiles afin de permettre au gens de construire un programme fonctionnalité par fonctionnalité tout en fournissant régulièrement des versions témoignant de l'avancée des travaux et permettant de régler le cap.

Le problème c'est d'avoir la relation de confiance avec le publisher (par exemple) pour mettre en place cette façon de travailler. Car à la base dans un contrat on veut pouvoir mettre des milestones afin d'être sur d'en avoir pour son argent. C'est d'ailleurs le différentiel de perception entre éditeur et développeur dans la rédaction de la liste de milestones qui est à l'origine de pas mal de conflits sur la fin d'un projet.

C'est pourquoi personne veut faire du one shot, parce que cette confiance qui est le ciment de la relation contractuelle est si difficile à obtenir.

Écrit par : whirly | 14/09/2009

Moi, j'utilise Excel depuis trois projet, et ca marche tres bien :)... je rentre dans les delais fluctuant comme les aleats de prod et mon producteurs et tres content (car quand ca rentre pas, je gueule, et il est content aussi car il sait qu'il y a un probleme a l'avance et non pas apres :)... enfin, rien n'ai jamais parfait et un jour, je suis sur que ca marcheras plus pour une ou plusieurs raison non encore rencontrer :).

Écrit par : Nico | 15/09/2009

@Whirly: Comme tu le rappelles, c'est un problème de confiance (confiance interne au studio/confiance externe vis à vis du client). Les deux seules raisons d'établir des métriques et une planification sont le contrôle du cout et le contrôle des délais.

L'un dans l'autre, on peut dire que c'est un mal nécessaire ^_^

En pratique, on sait bien que toutes les taches ne sont pas égales. Les sprints façon agiles sont par exemple un excellent outils pour gérer les phases de "recherches", en pré production par exemple.

Par contre, quand il s'agit de produire le jeu effectivement (et en admettant que l'on sache quoi produire, et comment), une planification moins organique est parfaitement acceptable, IMHO...

Bref, le tout en somme, c'est de savoir rester flexible et de garder la tête froide je suppose...

@Nico: Ahh, les joies des spreadsheets Excel, que de souvenirs joyeux... ou pas... ^_^

Écrit par : Daz | 15/09/2009

Tu retires excel, l'industrie s'effondre :)

Écrit par : Whirly | 15/09/2009

Les commentaires sont fermés.