Vous connaissez cette situation ? Un chef de projet vous contacte en panique un vendredi après-midi pour un problème soi-disant urgent. Mais quand vous creusez un peu, vous découvrez que ce même bug avait été résolu il y a plusieurs années par un stagiaire en test. Et bien sûr, l’équipe infrastructure nous regarde bizarrement quand on demande des permissions supplémentaires. C’est le quotidien du développement où on jongle entre les fausses urgences et les vraies priorités. Comment vous gérez ce genre de situation dans vos équipes ?
J’ai appris à documenter systématiquement ce genre de trucs. Quand un ticket revient en “urgent” après avoir été traité, je crée une base de connaissances avec les résolutions précédentes. Ça évite de refaire le boulot et ça donne des arguments solides face aux chefs de projet qui paniquent. Pour les permissions infrastructure, j’établis des protocoles clairs en amont plutôt que de négocier chaque fois dans l’urgence. Maintenant je demande toujours l’impact métier réel et la vraie date limite business avant de prioriser.
J’ai mis en place un système de traçabilité qui m’a sauvé plusieurs fois. Ticket urgent qui arrive ? Je vérifie d’abord si on l’a déjà eu avec une recherche rapide par mots-clés. Si oui, je renvoie directement la solution précédente avec le lien vers la résolution originale. Ça responsabilise les demandeurs et évite de perdre du temps. Pour les permissions infrastructure, j’ai négocié un accès en lecture seule sur les environnements de test - je peux diagnostiquer rapidement sans attendre. Le truc c’est aussi de faire un suivi post-résolution pour comprendre pourquoi le même problème revient.
ah ça me rappelle des souvenirs ! perso j’ai commencé à demander systématiquement “c’est urgent depuis quand exactement ?” quand quelqu’un débarque avec un ticket prioritaire. souvent ça calme direct et on peut discuter sérieusement des vraies deadlines après