Les meilleures équipes d'ingénierie n'ont pas besoin de QA dédiée.
On juge les tests de performance trop velus pour des devs, alors on leur confisque pour refiler ça à des spécialistes. C'est une erreur grossière.
Ça fabrique un goulet d'étranglement et ça coupe le fil entre devs et QA.
J'approche le problème sur deux fronts.
1. J'outille les devs pour une réponse at-scale : self-service, support technique, et support méthodologique. De la Developer Experience, du Productivity Engineering, appelle ça comme tu veux.
Les devs gardent l'ownership et font leur premier test en moins de 2 heures.
La perf est leur affaire autant que la mienne, tant que la feedback loop reste courte et que l’outillage est engageant.
2. Je sanctuarise mon temps pour les sujets retors, qui réclament une exigence qu'on ne tient pas à temps partiel : hardware dédié, environnement millimétré, campagnes lourdes en risques.
Là, un ou une spécialiste se justifie pleinement.
C'est pas une question de compétence, mais de rentabilité.
Un savoir-faire de niche étalé sur des personnes qui s'en servent une fois l'an, ça rapporte rien.
Mais concentré sur quelqu'un qui le décline partout où ça compte, ça paie.
🎯 Donner les clés du camion aux devs, ça n'interdit pas d'avoir des spécialistes à côté. Si tes spécialistes enchaînent les tests simples, qui va explorer les zones d'ombre ?
Un bon spécialiste perf ne prend la place de personne.
Son job, c'est de donner à une équipe le désir d'affûter la performance de son périmètre.
Je suis libre à partir du 1er octobre. Si c’est le genre de raisonnement qui te parle, fais-moi signe.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →