Sur un projet avec un groupe, le chanteur veut plus de voix, le guitariste plus de guitare, le manager trouve le morceau trop long, et chacun t'écrit de son côté. Tu te retrouves à arbitrer des désaccords qui ne te regardent pas, avec des demandes qui s'annulent entre elles.
La parade se met en place avant même de commencer : une seule personne collecte les avis, les filtre et te les transmet. Tout ce qui vient d'ailleurs est renvoyé vers elle.
Poser la règle en plein conflit ressemble à une manière de faire taire quelqu'un. La poser au départ, dans le contrat ou l'email d'accueil, en fait une simple question d'organisation que tout le monde accepte. C'est aussi le moment où tu sais qui paie et qui décide, avant que les avis ne se multiplient.
La règle oblige le groupe à trancher en interne. Les demandes qui t'arrivent sont déjà arbitrées, et les tensions entre membres restent entre eux au lieu de passer par ta boîte mail. C'est souvent ce qui évite qu'une révisionDemande d'ajustement du client sur une version déjà livrée, suivie d'une nouvelle version corrigée par le prestataire. On parle de cycle de révisions quand les retours sont regroupés en une seule liste : c'est l'unité qui sert à limiter et à chiffrer les révisions.Voir la fiche banale ne tourne à l'affrontement. Couplée à un seul endroit où rassembler tous les échanges du projet, elle te permet de savoir à tout moment qui a demandé quoi.
En général, c'est celle qui a lancé le projet et qui paie. Si un manager ou un A&R suit le projet, associe-le à la désignation.
Mets-la dans le contrat ou dans l'email d'accueil du projet. Un modèle d'email réutilisé à chaque projet évite de l'oublier.
Toute demande qui arrive d'un autre membre ou d'un autre canal est renvoyée, poliment, vers la personne désignée.
Même un membre sympathique qui t'écrit en privé passe par le contact désigné. Une seule exception suffit à faire tomber la règle.
