La gestion des développements postérieurs à la livraison d'un projet est assez problématique et source de conflits entre ses différents acteurs.
Je présente ici deux solutions que j'ai expérimenté et qui ont permis selon moi de solutionner et de faciliter les choses dans la gestion des développements et l'allocation des personnes.

Mais tout d'abord mettons-nous d'accord sur le vocabulaire qui sera utilisé tout au long de cette réflexion:

• Développement : sous entendu ici, développement informatique ou développement web. J'ai expérimenté ces solutions sur des projets de plus petites envergures dont le produit est standardisé et la durée de développement courte (exemple: production de formulaires, de bannières d'affiliation, ...)
• Spécifications : document décrivant le design, la technique et les fonctionnalités que doit apporter la réalisation du développement
• Retour : changement désiré par le client vis à vis des spécifications
• Bug : design, technique ou fonctionnalité non conforme aux spécifications
• Client interne : client au sein de l'entreprise et dont les intérêts vont dans le même sens que le chef de projet (le responsable du projet du côté de l'entreprise réalisatrice) puisque inhérents à la bonne marche de l'entreprise
• Client externe : client extérieur à l'entreprise qui a besoin du projet

Je sépare ces deux solutions selon le type de clients qui est pout moi une variable importante car elle implique différents niveaux hiréarchiques et relationnels.

Lorsque le client est externe

Définir un cadre strict est essentiel avec le client externe à la fois sur le contrat lui-même puis sur les spécifications. Le développement du projet peut ensuite avoir lieu dans les meilleurs conditions possibles.

Néanmoins une fois celui-ci livré et contrôlé par les deux parties (le client et le chef de projet), voici ce que je propose pour gérer les éventuels développements suppplémentaires.

"If project content is allowed to change freely, the rate of change will exceed the rate of progress", Inconnu

Le projet une fois livré est crédité de 2 retours et de 2 bugs possibles.

• 2 retours car nul n'est parfait et on peut vite s'apercevoir qu'un point a été oublié dans les spécifications.
• 2 bugs en revanche peut surprendre mais cela demande au client et au chef de projet de la rigeur. En effet le chef de projet ou son équipe de Quality Control ou Test doivent être capables de filtrer en amont l'ensemble des bugs possibles vis à vis des spécifications sinon il devient trop facile de livrer au plus vite et à la hâte un projet non conforme. Du côté du client cela implique de contrôler d'emblée ce qui lui a été livré et de s'assurer de la qualité et de la conformité du travail produit à sa demande initiale.

En travaillant ainsi, toute modification supplémentaire sur un projet peut faire l'objet d'une facturation et devient alors en elle-même un nouveau "projet" avec son propre cycle de production.

Du côté de l'entreprise. réalisatrice du projet, il devient possible d'allouer une case "retours et bugs" dans le planning des équipes à une fréquence quotidienne ou hebdomadaire. Le développeur ainsi en charge de la modification n'est pas forcément celui qui a au départ travaillé sur le projet mais cela assure un contrôle externe du code et un partage des connaissances entre les équipes de développement informatique.

Le responsable des développements peut ensuite analyser les retours et les bugs de la semaine et les communiquer à son équipe. Tout le monde peut apprendre du travail de chacun et avoir implicitement en tête d'amener le compteur à zéro dans son travail.

Cette solution n'est pas sans inconvénients toutefois. Elle implique de bien maîtriser son sujet à travers un contrat clair et des spécifications bien écrites pour construire un socle de base. Elle implique aussi d'être ferme face à son client bien qu'une certaine flexibilité reste possible (devant un nouveau client dont le traffic est dans le top 10 Français, allez-vous vraiment dire que comme dit dans cet article, "c'est 2 retours et puis c'est tout ?"). Du côté du planning des équipes, elle implique de pouvoir allouer une case à une fréquence régulière dans le planning des développeurs ce qui signifie de disposer de ressources suffisantes et disponibles.

Je décrirais prochainement ce que j'ai expérimenté comme solution lorsque le client est interne mais que pensez-vous de cette gestion ? En connaissez-vous d'autres ? Qu'est ce qui fonctionne bien ou moins bien dans votre propre environnement ?

En attendant continuez de proposer vos citations via le formulaire en ligne !
 

Crédits Photos : Gate / daniel.d.slee sur Flickr