Je reprends cette semaine la suite de l'article "Gérer les bugs et retours sur un projet" en m'attachant cette fois ci sur des projets réalisés pour un client interne à l'entreprise. C'est à dire de la même entreprise que le chef de projet et de l'équipe de développements.

Il est difficile de dire non à une personne réclamant des modifications sur un projet délivré quand elle est dans la même entreprise. Pourquoi ? Si ces modifications sont justifiées, le projet en bénéficie et en fait bénéficier l'entreprise. Qui décide alors de savoir si oui ou non ces modifications sont justifiées ? Ou qui décide de la réalisation de ces modifications ? Là c'est plus une question de hiérarchie et de confiance...

Partons cependant du principe que ces modifications, bugs ou retours, doivent être réalisées, il faut alors organiser son travail et sa gestion des développements pour ne pas avoir à les réaliser de manière continue au fur et à mesure des demandes. Ci-dessous, un système que j'ai expérimenté et qui a fourni de bons résultats:

• demander aux différents project sponsors (clients internes) de collecter leurs demandes et de les faire parvenir avant le Vendredi
• le Vendredi était alors consacrer à l'examination de ces différents besoins et de leur priorisation selon leurs objectifs et le temps de développement nécessaire à leurs réalisations
• prévoir ensuite une case de une demie à une journée par semaine où ces développements sont intégrés dans le planning du développeur en charge de cette tâche pour la semaine correspondante

Bien sûr ici ce n'est qu'un exemple et libre à chacun de déterminer la date limite de collecte des demandes et leur allocation ensuite. Cette méthode a néanmoins plusieurs avantages :

• les projects sponsors ou demandeurs se savent écouter et peuvent comprendre pourquoi telle ou telle modification ne sera pas réalisée dans l'immédiat
• envoyer un mail aux project sponsors le Vendredi leur permet de savoir quelles sont les bugs et retours traités et de pouvoir s'organiser en adéquation
• l'équipe de développement a le temps de se consacrer aux développements et projets en cours en sachant au préalable qu'une journée par semaine, ils auront à traiter ces demandes

Toutefois en cas de bug majeur, bien sûr celui-ci passe en priorité haute et sa résolution doit être immédiate.

D'un point de vue personnel, comme chef de projet, cette solution a facilité mon travail. Je peux me concentrer sur mon travail en gardant dans ma boîte mail les différentes demandes pour m'y attacher une demie ou une journée par semaine. Mes développeurs en sont aussi reconnaissants et sont préparés implicitement à travailler à fréquence régulière sur ces bugs et retours.

Qu'en est-il de votre entreprise ? Comment gérez-vous ces demandes ?

Crédits Photos : Montagnes Russes / Isabella_68 sur Flickr